iOS 10 適配 ATS

iOS 10 適配 ATS

一. HTTPS

其實HTTPS從最終的數據解析的角度,與HTTP沒有任何的區(qū)別体啰,HTTPS就是將HTTP協議數據包放到SSL/TSL層加密后否灾,在TCP/IP層組成IP數據報去傳輸窃蹋,以此保證傳輸數據的安全准潭;而對于接收端,在SSL/TSL將接收的數據包解密之后腔丧,將數據傳給HTTP協議層放椰,就是普通的HTTP數據。HTTP和SSL/TSL都處于OSI模型的應用層愉粤。從HTTP切換到HTTPS是一個非常簡單的過程砾医,在做具體的切換操作之前,我們需要了解幾個概念:

SSL/TLS

為了保證這些隱私數據能加密傳輸科汗,于是網景公司設計了SSL(Secure Sockets Layer)協議用于對HTTP協議傳輸的數據進行加密藻烤,從而就誕生了HTTPS。SSL目前的版本是3.0头滔,被IETF(Internet Engineering Task Force)定義在RFC 6101中怖亭,之后IETF對SSL 3.0進行了升級,于是出現了TLS(Transport Layer Security) 1.0坤检,定義在RFC 2246兴猩。實際上我們現在的HTTPS都是用的TLS協議,但是由于SSL出現的時間比較早早歇,并且依舊被現在瀏覽器所支持倾芝,因此SSL依然是HTTPS的代名詞,但無論是TLS還是SSL都是上個世紀的事情箭跳,SSL最后一個版本是3.0晨另,今后TLS將會繼承SSL優(yōu)良血統繼續(xù)為我們進行加密服務。

SSL/TLS協議運行機制的概述

圖解SSL/TLS協議

簡單的來說谱姓,SSL/TSL通過四次握手借尿。SSL協議的工作流程:

服務器認證階段:

客戶端向服務器發(fā)送一個開始信息“Hello”以便開始一個新的會話連接;

服務器根據客戶的信息確定是否需要生成新的主密鑰屉来,如需要則服務器在響應客戶的“Hello”信息時將包含生成主密鑰所需的信息路翻;

客戶根據收到的服務器響應信息,產生一個主密鑰茄靠,并用服務器的公開密鑰加密后傳給服務器茂契;

服務器恢復該主密鑰,并返回給客戶一個用主密鑰認證的信息慨绳,以此讓客戶認證服務器掉冶。

用戶認證階段:

在此之前,服務器已經通過了客戶認證脐雪,這一階段主要完成對客戶的認證郭蕉。

經認證的服務器發(fā)送一個提問給客戶,客戶則返回(數字)簽名后的提問和其公開密鑰喂江,從而向服務器提供認證召锈。

二. App Transport Security

iOS9中新增App Transport Security(簡稱ATS)特性, 主要使到原來請求的時候用到的HTTP,都轉向TLS1.2協議進行傳輸获询。這也意味著所有的HTTP協議都強制使用了HTTPS協議進行傳輸涨岁。在 iOS 9 和 OS X 10.11 中,默認情況下非 HTTPS 的網絡訪問是被禁止的吉嚣。當然梢薪,因為這樣的推進影響面非常廣,作為緩沖尝哆,我們可以在 Info.plist 中添加NSAppTransportSecurity字典并且將NSAllowsArbitraryLoads設置為YES來禁用 ATS秉撇。

不過,WWDC 16 中,Apple 表示將繼續(xù)在 iOS 10 和 macOS 10.12 里收緊對普通 HTTP 的訪問限制琐馆。從 2017 年 1 月 1 日起规阀,所有的新提交 app 默認是不允許使用NSAllowsArbitraryLoads來繞過 ATS 限制的,也就是說瘦麸,我們最好保證 app 的所有網絡請求都是 HTTPS 加密的谁撼,否則可能會在應用審核時遇到麻煩。

三. iOS10 NSAppTransportSecurity

通過在info.plist中配置這個鍵滋饲,開發(fā)者可以自定義網絡安全策略厉碟。例如:

允許針對個別服務器的不安全訪問。

允許不安全的 web 或媒體內容訪問屠缭,但不影響整個app的ATS策略箍鼓。

啟用新的安全特性,例如Certificate Transparency呵曹。

對NSAppTransportSecurity的支持自 iOS9.0款咖,OS X v10.11 開始,適用于 app 和 app extension逢并。

自 iOS10.0之剧,macOS 10.12 開始,增加了對下列子鍵的支持:

NSAllowsArbitraryLoadsInMedia

NSAllowsArbitraryLoadsInWebContent

NSRequiresCertificateTransparency

NSAllowsLocalNetworking

ATS Configuration Basics / ATS 配置基礎知識

對于使用 iOS9.0砍聊, OS X v10.11 SDK 及以上的 app 來說背稼,ATS(App Transport Security)默認開啟,NSAllowsArbitraryLoads是字典NSAppTransportSecurity的根鍵玻蝌,默認值NO蟹肘。

在啟用 ATS 的情況下,所有的 HTTP 請求必須為 HTTPS(RFC 2818) 連接俯树。任何不安全的 HTTP 請求都將失敗帘腹。ATS 使用 TLS(Transport Layer Security)v1.2(RFC 5246)。

下面是字典NSAppTransportSecurity的總體結構许饿,所有鍵都是非必填項:

NSAppTransportSecurity: Dictionary {NSAllowsArbitraryLoads: BooleanNSAllowsArbitraryLoadsInMedia: BooleanNSAllowsArbitraryLoadsInWebContent: BooleanNSAllowsLocalNetworking: BooleanNSExceptionDomains: Dictionary {? ? ? ? : Dictionary {NSIncludesSubdomains: BooleanNSExceptionAllowsInsecureHTTPLoads: BooleanNSExceptionMinimumTLSVersion: StringNSExceptionRequiresForwardSecrecy: Boolean// Default value is YESNSRequiresCertificateTransparency: Boolean? ? ? ? }? ? }}

可以看出阳欲,所有鍵可以分為兩類:主鍵,這些鍵用來定義 app 的總體 ATS 策略陋率;子鍵球化,即NSExceptionDomains下面的鍵,使用這些鍵針對某個域名單獨配置瓦糟。

主鍵包括:

NSAllowsArbitraryLoads

設置為 YES筒愚,解除整個 app 的 ATS 限制;但是菩浙,通過NSExceptionDomains進? ? 行的配置依然有效巢掺。默認值為 NO句伶。

注意:設置為 YES,會引發(fā) App Stroe 的審查陆淀,開發(fā)者必須說明原因考余。

NSAllowsArbitraryLoadsInMedia

設置為 YES,解除通過 AV Foundation 框架訪問媒體內容時的 ATS 限制倔约;啟用這個? ? 鍵秃殉,務必確保載入的媒體內容已經被加密坝初,例如受FairPlay保護的文件浸剩,或者是安全的? ? HLS流媒,其中不包含敏感的個人信息鳄袍。默認為 NO绢要。

NSAllowsArbitraryLoadsInWebContent

設置為 YES,解除通過 web view 發(fā)出的網絡請求的 ATS 限制拗小。啟用這個鍵重罪,可以使? ? app 訪問任意網頁內容,但不影響 app 的總體 ATS 策略哀九。此鍵值默認為 NO剿配。

NSAllowsLocalNetworking

設置為 YES,使得 app 可以載入任意本地資源阅束,但不影響 app 的總體 ATS 策略呼胚。默? ? 認為 NO。

NSExceptionDomains

為一個或多個域名單獨配置 ATS息裸。

被單獨配置的域名蝇更,默認受到完全的 ATS 限制,不管NSAllowsArbitraryLoads的值? ? 如何呼盆;需要通過子鍵年扩,進一步配置

所有的子鍵都屬于NSExceptionDomain。向Info.plist中添加這一主鍵:

創(chuàng)建字典访圃,針對一個或多個域名厨幻,以便進行 ATS 配置。

這意味著之前使用主鍵所做的設置腿时,對于這個域名來說况脆,已經無效。

例如圈匆,及時之前設置NSAllowsArbitraryLoadsInMedia為 YES漠另,然而NSExceptionDomain所代表的域名依然不能訪問不安全的媒體內容。

基于這樣的設定跃赚,可以針對域名進行 ATS 配置笆搓,增加或減少安全措施性湿。例如:

將NSExceptionAllowsInsecureHTTPLoads設置為 YES,就 满败;這樣做會引發(fā) App Store 的審查肤频,詳情見App Store Review for ATS。

通過配置NSExceptionRequiresForwardSecrecy為 NO算墨,取消正向保密宵荒。

通過配置NSExceptionMinimumTLSVersion,更改 TLS 最低版本净嘀。

NSExceptionDomains字典構成:

<域名字符串>

代表想要配置的特定域名报咳。可以添加多個域名(即添加多個這樣的鍵)挖藏,為它們統一配置 ATS 策略暑刃。這個鍵對應一個字典,包含以下子鍵:

NSIncludesSubdomains

* 設置為YES膜眠,當前域名的 ATS 策略適用于其所有子域名岩臣。默認為NO。

NSExceptionAllowsInsecureHTTPLoads

* 設置為YES宵膨,可以同時通過 HTTP 和 HTTPS 訪問當前域名架谎。默認為NO。注意辟躏,配置這個鍵值谷扣,將引發(fā) App Store 的審查,開發(fā)者必須說明原因鸿脓。

NSExceptionMinimumTLSVersion

*指定 TLS 的最低版本抑钟,因此可以使用版本較低,有安全漏洞的 TLS 協議野哭。注意在塔,配置這個鍵值,將引發(fā) App Store 的審查拨黔,開發(fā)者必須說明原因蛔溃。

NSExceptionRequiresForwardSecrecy

* 設置為NO,允許針對當前域名使用不支持正向保密的 TLS 加密算法篱蝇。默認為YES贺待。

NSRequiresCertificateTransparency

* 設置為YES,將驗證域名服務器證書的Certificate Transparency時間戳 零截。默認為NO麸塞。

Requirements for Connecting Using ATS / 使用 ATS 的前提條件

在 ATS 完全開啟的情況下,系統要求 app 的 HTTPS 連接必須滿足以下要求:

X.509 數字證書必須滿足下列標準中的一項:

由操作系統內嵌的根證書頒發(fā)機構簽發(fā)

由通過操作系統管理員或用戶主動安裝的根證書頒發(fā)機構簽發(fā)

TLS 版本必須為1.2涧衙,任何不使用或使用較低版本 TLS / SSL 的連接哪工,都將失敗奥此。

連接必須使用 AES-128 或 AES-256 對稱加密算法。 TLS 算法套裝必須以 ECDSA 密鑰交換的形式支持正向保密雁比,加密算法必須為下面之一:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

服務端的葉證書簽名密鑰必須為下面之一:

至少2048位的 RSA 密鑰

至少256位的 ECC 密鑰

此外稚虎,服務器證書的哈希算法必須為 SHA-2士修,其摘要長度至少位256位(即 SHA-256 及以上)枕屉。

上面的標準,未來可能會發(fā)生變化穿稳。但不會影響到 app 二進制包的兼容性茴她。

App Store Review for ATS / App Store 對于 ATS 相關項的審核

某些對 ATS 的配置會引發(fā) App Store 的審核寻拂,開發(fā)者必須說明原因。這些鍵有:

NSAllowsArbitraryLoads

NSExceptionAllowsInsecureHTTPLoads

NSExceptionMinimumTLSVersion

以下是一些原因說明例子败京,供參考:

必須連接由其他機構控制的服務器兜喻,其還不支持安全連接梦染。

必須支持那些還未升級至可使用安全連接赡麦,不得不通過公共域名訪問網絡的設備。

必須通過 web 展示來源不一的各種網絡內容帕识,但又不能完全使用NSAllowsArbitraryLoadsInWebContent所管理的類泛粹。

向 App Store 提交審核時,開發(fā)者應主動提供足夠的信息肮疗,以便解釋 app 無法使用安全連接的原因晶姊。

四. 實現支持安全ATS策略

ATS相關設置對iOS8及以下系統無效

需要解決的問題(iOS 9、iOS10及以上)

1伪货、app內服務器網絡請求訪問支持https(即一般的請求)

2们衙、webview內支持任意http訪問

3、第三方sdk接入與支持http訪問

主要是圍繞info.pilst配置文件作相關的安全ATS策略

Info.plist文件是向操作系統描述應用程序的XML屬性列表,是iPhone應用程序文件夾包含所有重要的Info.plist文件

你可能注意到一些關鍵字像是使用了一些其他關鍵字中的詞但是在前面加上了"ThirdParty"字樣碱呼,在功能上蒙挑,這些關鍵字與不含有"ThirdParty"的關鍵字有同樣的效果。而且實際運行中所調用的代碼將會完全忽略是否使用"ThirdParty"關鍵字愚臀。

簡單粗暴的方案:

--------------------------------------------

NSExceptionDomains 的設置方法如下, 比如我們要將 weibo.com 這個域名排除在 ATS 驗證之外忆蚀,就可以這樣:

key>NSAppTransportSecurityNSExceptionDomainsweibo.comNSIncludesSubdomainsNSExceptionRequiresForwardSecrecyNSExceptionAllowsInsecureHTTPLoadsNSAllowsArbitraryLoads

注意:每個需添加的域都需要設置此三個屬性。如果請求的網絡圖片是HTTP姑裂,也是需要設置的圖片的域馋袜。

注意??這個方案風險較大,有可能被拒絕舶斧⌒辣睿“需要訪問的域名是第三方服務器,他們沒有進行 HTTPS 對應”會是審核時的一個可選理由茴厉,但是這應該只需要針對特定域名泽台,而非全面開放让网。如果訪問的是自己的服務器的話,可能這個理由會無法通過师痕。

------------------------------------------------

實現方案

1溃睹、app內服務器網絡請求訪問支持https

解決方案:

搭建https服務器

搭建https服務器需要ssl證書

ssl自制證書:稱自簽名ssl證書,容易被假冒偽造胰坟,瀏覽器不信任因篇。(審核不通過)

免費CA證書:部分CA機構提供免費的SSL證書,如wosign笔横,starts等(App Store pass掉不通過)

付費CA證書:多指企業(yè)級及以上的數字證書竞滓。

HTTPS服務器滿足ATS默認的條件,而且SSL證書是通過權威的CA機構認證過的吹缔,那么我們在使用Xcode開發(fā)的時候商佑,對網絡的適配什么都不用做,我們也能正常與服務器通信厢塘。但是茶没,當我們對安全性有更高的要求時或者我們自建證書時,我們需要本地導入證書來進行驗證晚碾。

使用AFNetworking來支持https

AFNetworking是iOS/OSX開發(fā)最流行的第三方開源庫之一,現在iOS oc 代碼90%以上都是用這個框架網絡請求抓半。AFNetworking已經將上面的邏輯代碼封裝好,甚至更完善格嘁,在AFSecurityPolicy文件中笛求,有興趣可以閱讀這個模塊的代碼;以下就是在AFNetworking 2.6.0以前版本和3.0.0版本基于支持https的驗證方式

步驟:

新建一個manager

在mainBundle中尋找我們剛才拖進項目中的https.cer, 并且將相關的數據讀取出來

新建一個AFSecurityPolicy糕簿,并進行相應的配置

將這個AFSecurityPolicy 實例賦值給manager

代碼實現:

NSURL* url = [NSURLURLWithString:@"https://www.google.com"];AFHTTPRequestOperationManager * requestOperationManager = [[AFHTTPRequestOperationManager alloc] initWithBaseURL:url];dispatch_queue_trequestQueue = dispatch_create_serial_queue_for_name("kRequestCompletionQueue");requestOperationManager.completionQueue= requestQueue;AFSecurityPolicy * securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];//allowInvalidCertificates 是否允許無效證書(也就是自建的證書)探入,默認為NO//如果是需要驗證自建證書,需要設置為YESsecurityPolicy.allowInvalidCertificates=YES;//validatesDomainName 是否需要驗證域名懂诗,默認為YES蜂嗽;//假如證書的域名與你請求的域名不一致,需把該項設置為NO响禽;如設成NO的話徒爹,即服務器使用其他可信任機構頒發(fā)的證書,也可以建立連接芋类,這個非常危險隆嗅,建議打開。//置為NO侯繁,主要用于這種情況:客戶端請求的是子域名胖喳,而證書上的是另外一個域名。因為SSL證書上的域名是獨立的贮竟,假如證書上注冊的域名是www.google.com丽焊,那么mail.google.com是無法驗證通過的较剃;當然,有錢可以注冊通配符的域名*.google.com技健,但這個還是比較貴的写穴。//如置為NO,建議自己添加對應域名的校驗邏輯雌贱。securityPolicy.validatesDomainName=YES;//validatesCertificateChain 是否驗證整個證書鏈啊送,默認為YES//設置為YES,會將服務器返回的Trust Object上的證書鏈與本地導入的證書進行對比欣孤,這就意味著馋没,假如你的證書鏈是這樣的://GeoTrust Global CA//? ? Google Internet Authority G2//? ? ? ? *.google.com//那么,除了導入*.google.com之外降传,還需要導入證書鏈上所有的CA證書(GeoTrust Global CA, Google Internet Authority G2)篷朵;//如是自建證書的時候,可以設置為YES婆排,增強安全性声旺;假如是信任的CA所簽發(fā)的證書,則建議關閉該驗證泽论,因為整個證書鏈一一比對是完全沒有必要(請查看源代碼)艾少;securityPolicy.validatesCertificateChain=NO;requestOperationManager.securityPolicy= securityPolicy;

另afnetworking 3.0.0以上版本用的是AFHTTPSessionManager

AFHTTPSessionManager * manager = [AFHTTPSessionManager manager];NSString* cerPath = [[NSBundlemainBundle] pathForResource:@"server"ofType:@"cer"];NSData* cerData = [NSDatadataWithContentsOfFile:cerPath];NSLog(@"%@", cerData);? ? manager.securityPolicy= [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate withPinnedCertificates:[[NSArrayalloc] initWithObjects:cerData,nil]];? ? manager.securityPolicy.allowInvalidCertificates=YES;? ? [manager.securityPolicysetValidatesDomainName:NO];? ? manager.requestSerializer= [AFJSONRequestSerializer serializer];? ? manager.responseSerializer= [AFJSONResponseSerializer serializer];NSDictionary* parameter = @{@"username":self.username,@"password":self.password};? ? [manager POST:@"https://192.168.1.4:9777"parameters:parameter success:^(NSURLSessionDataTask* task,idresponseObject) {NSLog(@"success %@", responseObject);? ? ? ? }? ? ? ? failure:^(NSURLSessionDataTask* task,NSError* error) {NSLog(@"failure %@", error);? ? ? ? }]

NSAppTransportSecurityNSAllowsArbitraryLoads//設置為 YES,解除整個app的ATS限制翼悴;但是通過NSExceptionDomains進行的配置依然有效NSAllowsArbitraryLoadsInMedia//設置為 YES,解除通過AVFoundation框架訪問媒體內容時的 ATS 限制NSAllowsArbitraryLoadsInWebContent//設置為 YES幔妨,解除通過webview發(fā)出的網絡請求的ATS限制NSAllowsLocalNetworking//設置為 YES鹦赎,使得app可以載入任意本地資源,但不影響app的總體 ATS 策略

2误堡、webview內支持任意http訪問

對于網頁瀏覽和視頻播放的行為古话,iOS 10 中新加入了 NSAllowsArbitraryLoadsInWebContent 鍵。通過將它設置為 YES锁施,可以讓 app 中的 WKWebView 和使用 AVFoundation 播放的在線視頻不受 ATS 的限制陪踩。這也應該是絕大多數使用了相關特性的 app 的選擇。但是壞消息是這個鍵在 iOS 9 中并不會起作用悉抵。

如果app只支持 iOS 10肩狂,并且有用戶可以自由輸入網址進行瀏覽的功能,或者是在線視頻音頻播放功能的話姥饰,簡單地加入 NSAllowsArbitraryLoadsInWebContent傻谁,并且將組件換成 WKWebKit 或者 AVFoundation 就可以了。如果你還需要支持 iOS 9列粪,并且需要訪問網頁和視頻的話审磁,可能只能去開啟 NSAllowsArbitraryLoads 然后提交時進行說明谈飒,并且看 Apple 審核員決定讓不讓通過了。

另外态蒂,當 NSAllowsArbitraryLoads 和 NSAllowsArbitraryLoadsInWebContent 同時存在時杭措,根據系統不同,表現的行為也會不一樣钾恢。簡單說瓤介,iOS 9 只看 NSAllowsArbitraryLoads赘那,而 iOS 10 會先看 NSAllowsArbitraryLoadsInWebContent。在 iOS 10 中募舟,要是 NSAllowsArbitraryLoadsInWebContent 存在的話,就忽略掉 NSAllowsArbitraryLoads拱礁,如果它不存在,則遵循 NSAllowsArbitraryLoads 的設定

UIWebView 在 NSAllowsArbitraryLoadsInWebContent 為 YES 時訪問 HTTP呢灶,無效。WKWebView 在 NSAllowsArbitraryLoadsInWebContent 為 YES 時在iOS 10 中訪問 HTTP鸯乃,有效,iOS 9無效缨睡。如果用WkWebView替換UIWebView,iOS 7 將無法使用WkWebView奖年,可做適配加載,沒有特殊的什么需求的話陋守,盡早將 UIWebView 全部換為 WkWebView 會比較好震贵。所以為了能讓WebView在所有版本都能訪問非https內容,只能把NSAllowsArbitraryLoads設置為YES水评。

解決方案一:

開啟 NSAllowsArbitraryLoads 為 YES猩系,然后提交時進行說明

解決方案二:

設置 NSExceptionDomains 屬性來訪問指定域名,然后提交時進行說明

3之碗、第三方sdk接入與支持http訪問

但是按照國內的現狀蝙眶,關閉這個限制也許是更實際的做法。至于原因就太多了,第三方SDK(幾乎都是訪問http)幽纷,合作伙伴接入(不能要求它們一定要支持https)

第三方sdk式塌,同樣需要遵守ATS規(guī)則,即第三方sdk也有被ATS過濾的風險友浸,微信峰尝,qq,分享收恢,登陸功能都能正常武学,微博登陸不能正常通過。另在網上找到了一些可能存在有問題的sdk伦意,目前已知的有:

友盟 (已經有最新的v1.4.0版本sdk火窒,支持https,待驗證)

百度地圖

解決方案一:

更新最新sdk驮肉,接入并測試

解決方案二:

可以設置 NSExceptionDomains屬性來將需要排除強制驗證的域名寫進來:

五. 總結

開啟 NSAllowsArbitraryLoads 為 YES

對第三方訪問的服務器設置NSExceptionDomains方式添加白名單

提交審核說明:

必須連接由其他機構控制的服務器熏矿,其還不支持安全連接。

必須通過 web 展示來源不一的各種網絡內容离钝,但又不能完全使用NSAllowsArbitraryLoadsInWebContent所管理的類票编。

轉載:http://www.reibang.com/p/36ddc5b009a7 ?文/SN_Simon(簡書作者) ?

原文鏈接:http://www.reibang.com/p/36ddc5b009a7

著作權歸作者所有,轉載請聯系作者獲得授權卵渴,并標注“簡書作者”慧域。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市浪读,隨后出現的幾起案子昔榴,更是在濱河造成了極大的恐慌,老刑警劉巖瑟啃,帶你破解...
    沈念sama閱讀 221,635評論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件论泛,死亡現場離奇詭異,居然都是意外死亡蛹屿,警方通過查閱死者的電腦和手機,發(fā)現死者居然都...
    沈念sama閱讀 94,543評論 3 399
  • 文/潘曉璐 我一進店門岩榆,熙熙樓的掌柜王于貴愁眉苦臉地迎上來错负,“玉大人犹撒,你說我怎么就攤上這事粒褒。” “怎么了清笨?”我有些...
    開封第一講書人閱讀 168,083評論 0 360
  • 文/不壞的土叔 我叫張陵抠艾,是天一觀的道長检号。 經常有香客問我齐苛,道長桂塞,這世上最難降的妖魔是什么藐俺? 我笑而不...
    開封第一講書人閱讀 59,640評論 1 296
  • 正文 為了忘掉前任欲芹,我火速辦了婚禮菱父,結果婚禮上,老公的妹妹穿的比我還像新娘官辽。我一直安慰自己粟瞬,他們只是感情好裙品,可當我...
    茶點故事閱讀 68,640評論 6 397
  • 文/花漫 我一把揭開白布市怎。 她就那樣靜靜地躺著,像睡著了一般干像。 火紅的嫁衣襯著肌膚如雪麻汰。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,262評論 1 308
  • 那天挽封,我揣著相機與錄音辅愿,去河邊找鬼点待。 笑死,一個胖子當著我的面吹牛癞埠,可吹牛的內容都是我干的苗踪。 我是一名探鬼主播通铲,決...
    沈念sama閱讀 40,833評論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼器贩,長吁一口氣:“原來是場噩夢啊……” “哼蛹稍!你這毒婦竟也來了唆姐?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 39,736評論 0 276
  • 序言:老撾萬榮一對情侶失蹤胆描,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后国夜,有當地人在樹林里發(fā)現了一具尸體,經...
    沈念sama閱讀 46,280評論 1 319
  • 正文 獨居荒郊野嶺守林人離奇死亡醋闭,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,369評論 3 340
  • 正文 我和宋清朗相戀三年证逻,在試婚紗的時候發(fā)現自己被綠了囚企。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片龙宏。...
    茶點故事閱讀 40,503評論 1 352
  • 序言:一個原本活蹦亂跳的男人離奇死亡银酗,死狀恐怖黍特,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情灭衷,我是刑警寧澤今布,帶...
    沈念sama閱讀 36,185評論 5 350
  • 正文 年R本政府宣布部默,位于F島的核電站,受9級特大地震影響傅蹂,放射性物質發(fā)生泄漏份蝴。R本人自食惡果不足惜氓轰,卻給世界環(huán)境...
    茶點故事閱讀 41,870評論 3 333
  • 文/蒙蒙 一案糙、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧时捌,春花似錦奢讨、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,340評論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至蚀同,卻和暖如春蠢络,著一層夾襖步出監(jiān)牢的瞬間迟蜜,已是汗流浹背娜睛。 一陣腳步聲響...
    開封第一講書人閱讀 33,460評論 1 272
  • 我被黑心中介騙來泰國打工方库, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留纵潦,地道東北人。 一個月前我還...
    沈念sama閱讀 48,909評論 3 376
  • 正文 我出身青樓,卻偏偏與公主長得像寥院,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子只磷,可洞房花燭夜當晚...
    茶點故事閱讀 45,512評論 2 359

推薦閱讀更多精彩內容