鏈接:http://www.lxweimin.com/p/31bcddf44b8d
這篇文章是我一邊學習證書驗證一邊記錄的內容,
稍微整理了下,共扯了三部分內容:
HTTPS 簡要原理;
數字證書的內容、生成及驗證;
iOS 上對證書鏈的驗證。
HTTPS 概要
HTTPS 是運行在 TLS/SSL 之上的 HTTP,與普通的 HTTP 相比,在數據傳輸的安全性上有很大的提升。
要了解它安全性的巧妙之處,需要先簡單地了解對稱加密和非對稱加密的區別:
對稱加密只有一個密鑰,加密和解密都用這個密鑰;
非對稱加密有公鑰和私鑰,私鑰加密后的內容只有公鑰才能解密,公鑰加密的內容只有私鑰才能解密。
為了提高安全性,我們常用的做法是使用對稱加密的手段加密數據。可是只使用對稱加密的話,雙方通信的開始總會以明文的方式傳輸密鑰。那么從一開始這個密鑰就泄露了,談不上什么安全。所以 TLS/SSL 在握手的階段,結合非對稱加密的手段,保證只有通信雙方才知道對稱加密的密鑰。大概的流程如下:
TSL:SSL_handshake.png
所以,HTTPS 實現傳輸安全的關鍵是:在 TLS/SSL 握手階段保證僅有通信雙方得到 Session Key!
數字證書的內容
X.509 應該是比較流行的 SSL 數字證書標準,包含(但不限于)以下的字段:
字段值說明
對象名稱(Subject Name)用于識別該數字證書的信息
共有名稱(Common Name)對于客戶證書,通常是相應的域名
證書頒發者(Issuer Name)發布并簽署該證書的實體的信息
簽名算法(Signature Algorithm)簽名所使用的算法
序列號(Serial Number)數字證書機構(Certificate Authority, CA)給證書的唯一整數,一個數字證書一個序列號
生效期(Not Valid Before)(`?ω?′)
失效期(Not Valid After)(╯°口°)╯(┴—┴
公鑰(Public Key)可公開的密鑰
簽名(Signature)通過簽名算法計算證書內容后得到的數據,用于驗證證書是否被篡改
除了上述所列的字段,還有很多拓展字段,在此不一一詳述。
下圖為 Wikipedia 的公鑰證書:
wikipedia_cer.png
數字證書的生成及驗證
數字證書的生成是分層級的,下一級的證書需要其上一級證書的私鑰簽名。
所以后者是前者的證書頒發者,也就是說上一級證書的 Subject Name 是其下一級證書的 Issuer Name。
在得到證書申請者的一些必要信息(對象名稱,公鑰私鑰)之后,證書頒發者通過 SHA-256 哈希得到證書內容的摘要,再用自己的私鑰給這份摘要加密,得到數字簽名。綜合已有的信息,生成分別包含公鑰和私鑰的兩個證書。
扯到這里,就有幾個問題:
問:如果說發布一個數字證書必須要有上一級證書的私鑰加密,那么最頂端的證書——根證書怎么來的?
根證書是自簽名的,即用自己的私鑰簽名,不需要其他證書的私鑰來生成簽名。
問:怎么驗證證書是有沒被篡改?
當客戶端走 HTTPS 訪問站點時,服務器會返回整個證書鏈。以下圖的證書鏈為例:
chain_hierarchy.png
要驗證*.wikipedia.org這個證書有沒被篡改,就要用到GlobalSign Organization Validation CA - SHA256 - G2提供的公鑰解密前者的簽名得到摘要 Digest1,我們的客戶端也計算前者證書的內容得到摘要 Digest2。對比這兩個摘要就能知道前者是否被篡改。后者同理,使用GlobalSign Root CA提供的公鑰驗證。當驗證到到受信任的根證書時,就能確定*.wikipedia.org這個證書是可信的。
問:為什么上面那個根證書GlobalSign Root CA是受信任的?
數字證書認證機構(Certificate Authority, CA)簽署和管理的CA 根證書,會被納入到你的瀏覽器和操作系統的可信證書列表中,并由這個列表判斷根證書是否可信。所以不要隨便導入奇奇怪怪的根證書到你的操作系統中。
問:生成的數字證書(如*.wikipedia.org)都可用來簽署新的證書嗎?
不一定。如下圖,拓展字段里面有個叫 Basic Constraints 的數據結構,里面有個字段叫路徑長度約束(Path Length Constraint),表明了該證書能繼續簽署 CA 子證書的深度,這里為0,說明這個GlobalSign Organization Validation CA - SHA256 - G2只能簽署客戶端證書,而客戶端證書不能用于簽署新的證書,CA 子證書才能這么做。
path_length_constraint.png
iOS 上對證書鏈的驗證
在Overriding TLS Chain Validation Correctly中提到:
When a TLS certificate is verified, the operating system verifies its chain of trust. If that chain of trust contains only valid certificates and ends at a known (trusted) anchor certificate, then the certificate is considered valid.
所以在 iOS 中,證書是否有效的標準是:
信任鏈中如果只含有有效證書并且以可信錨點(trusted anchor)結尾,那么這個證書就被認為是有效的。
其中可信錨點指的是系統隱式信任的證書,通常是包括在系統中的 CA 根證書。不過你也可以在驗證證書鏈時,設置自定義的證書作為可信的錨點。
NSURLSession 實現 HTTPS
具體到使用 NSURLSession 走 HTTPS 訪問網站,-URLSession:didReceiveChallenge:completionHandler:回調中會收到一個 challenge,也就是質詢,需要你提供認證信息才能完成連接。這時候可以通過challenge.protectionSpace.authenticationMethod取得保護空間要求我們認證的方式,如果這個值是NSURLAuthenticationMethodServerTrust的話,我們就可以插手 TLS 握手中“驗證數字證書有效性”這一步。
默認的實現
系統的默認實現(也即代理不實現這個方法)是驗證這個信任鏈,結果是有效的話則根據 serverTrust 創建 credential 用于同服務端確立 SSL 連接。否則會得到 “The certificate for this server is invalid...” 這樣的錯誤而無法訪問。
比如在訪問https://www.google.com的時候咧,我們不實現這個方法也能訪問成功的。系統對 Google 服務器返回來的證書鏈,從葉節點證書往根證書層層驗證(有效期、簽名等等),遇到根證書時,發現作為可信錨點的它存在與可信證書列表中,那么驗證就通過,允許與服務端建立連接。
google.png
而當我們訪問https://www.12306.cn時,就會出現 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “www.12306.cn” which could put your confidential information at risk." 的錯誤。原因就是系統在驗證到根證書時,發現它是自簽名、不可信的。
12306.png
自定義實現
如果我們要實現這個代理方法的話,需要提供 NSURLSessionAuthChallengeDisposition(處置方式)和 NSURLCredential(資格認證)這兩個參數給 completionHandler 這個 block:
-(void)URLSession:(NSURLSession*)session? ? ? ? didReceiveChallenge:(NSURLAuthenticationChallenge*)challenge? ? ? ? completionHandler:(void(^)(NSURLSessionAuthChallengeDisposition,NSURLCredential* _Nullable))completionHandler {// 如果使用默認的處置方式,那么 credential 就會被忽略NSURLSessionAuthChallengeDispositiondisposition =NSURLSessionAuthChallengePerformDefaultHandling;NSURLCredential*credential =nil;if([challenge.protectionSpace.authenticationMethod? ? ? ? ? ? isEqualToString:NSURLAuthenticationMethodServerTrust]) {/* 調用自定義的驗證過程 */if([selfmyCustomValidation:challenge]) {? ? ? ? ? ? ? credential = [NSURLCredentialcredentialForTrust:challenge.protectionSpace.serverTrust];if(credential) {? ? ? ? ? ? ? ? disposition =NSURLSessionAuthChallengeUseCredential;? ? ? ? ? ? }? ? ? ? ? }else{/* 無效的話,取消 */disposition =NSURLSessionAuthChallengeCancelAuthenticationChallenge}? ? }if(completionHandler) {? ? ? ? completionHandler(disposition, credential);? ? } }
在[self myCustomValidation:challenge]調用自定義驗證過程,結果是有效的話才創建 credential 確立連接。
自定義的驗證過程,需要先拿出一個 SecTrustRef 對象,它是一種執行信任鏈驗證的抽象實體,包含著驗證策略(SecPolicyRef)以及一系列受信任的錨點證書,而我們能做的也是修改這兩樣東西而已。
SecTrustRef trust = challenge.protectionSpace.serverTrust;
拿到 trust 對象之后,可以用下面這個函數對它進行驗證。
staticBOOLserverTrustIsVaild(SecTrustRef trust) {BOOLallowConnection =NO;// 假設驗證結果是無效的SecTrustResultType trustResult = kSecTrustResultInvalid;// 函數的內部遞歸地從葉節點證書到根證書的驗證OSStatus statue = SecTrustEvaluate(trust, &trustResult);if(statue == noErr) {// kSecTrustResultUnspecified: 系統隱式地信任這個證書// kSecTrustResultProceed: 用戶加入自己的信任錨點,顯式地告訴系統這個證書是值得信任的allowConnection = (trustResult == kSecTrustResultProceed? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || trustResult == kSecTrustResultUnspecified);? ? }returnallowConnection;}
這個函數什么時候調用完全取決于你的需求,如果你不想對驗證策略做修改而直接調用的話,那你居然還看到這里!?(╯‵□′)╯︵┻━┻
域名驗證
可以通過以下的代碼獲得當前的驗證策略:
CFArrayRefpoliciesRef;SecTrustCopyPolicies(trust, &policiesRef);
打印 policiesRef 后,你會發現默認的驗證策略就包含了域名驗證,即“服務器證書上的域名和請求域名是否匹配”。如果你的一個證書需要用來連接不同域名的主機,或者你直接用 IP 地址去連接,那么你可以重設驗證策略以忽略域名驗證:
NSMutableArray*policies = [NSMutableArrayarray];// BasicX509 不驗證域名是否相同SecPolicyRef policy = SecPolicyCreateBasicX509();[policies addObject:(__bridge_transferid)policy];SecTrustSetPolicies(trust, (__bridgeCFArrayRef)policies);
然后再調用serverTrustIsVaild()驗證。
但是如果不驗證域名的話,安全性就會大打折扣。拿瀏覽器舉??:
試想你要傳輸報文到https://www.real-website.com,然而由于域名劫持,把你帶到了https://www.real-website.cn這個??網站,大概有以下兩種結果:
這個偽造網站的證書是非 CA 頒布的偽造證書的話,那么瀏覽器會提醒你這個證書不可信;
這個偽造網站也使用了 CA 頒布的證書,由于我們不做域名驗證,你的瀏覽器不會有任何的警告。
你可能會問:公鑰證書是每個人都能得到的,釣魚網站能不能返回真正的公鑰證書給我們呢?
我覺得是可以的,然而這并沒有什么卵用。沒有私鑰的釣魚服務器無法獲得第三個隨機數,無法生成 Session Key,也就不能對我們傳給它的數據進行解密了。
自簽名的證書鏈驗證
在 App 中想要防止上面提到的中間人公雞攻擊,比較好的做法是將公鑰證書打包進 App 中,然后在收到服務端證書鏈的時候,能夠有效地驗證服務端是否可信,這也是驗證自簽名的證書鏈所必須做的。
假設你的服務器返回:[你的自簽名的根證書]--[你的二級證書]--[你的客戶端證書],系統是不信任這個三個證書的。
所以你在驗證的時候需要將這三個的其中一個設置為錨點證書,當然,多個也行。
比如將[你的二級證書]作為錨點后,SecTrustEvaluate()函數只要驗證到[你的客戶端證書]確實是由[你的二級證書]簽署的,那么驗證結果為kSecTrustResultUnspecified,表明了[你的客戶端證書]是可信的。下面是設置錨點證書的做法:
NSMutableArray*certificates = [NSMutableArrayarray];NSDate*cerData =/* 在 App Bundle 中你用來做錨點的證書數據,證書是 CER 編碼的,常見擴展名有:cer, crt...*/SecCertificateRef cerRef = SecCertificateCreateWithData(NULL, (__bridgeCFDataRef)cerData);[certificates addObject:(__bridge_transferid)cerRef];// 設置錨點證書。SecTrustSetAnchorCertificates(trust, (__bridgeCFArrayRef)certificates);
只調用SecTrustSetAnchorCertificates ()這個函數的話,那么就只有作為參數被傳入的證書作為錨點證書,連系統本身信任的 CA 證書不能作為錨點驗證證書鏈。要想恢復系統中 CA 證書作為錨點的功能,還要再調用下面這個函數:
//true代表僅被傳入的證書作為錨點,false允許系統 CA 證書也作為錨點SecTrustSetAnchorCertificatesOnly(trust,false);
這樣,再調用serverTrustIsVaild()驗證證書有效性就能成功了。
CA 證書鏈的驗證
上面說的是沒經過 CA 認證的自簽證書的驗證,而 CA 的證書鏈的驗證方式也是一樣,不同點在不可信錨點的證書類型不一樣而已:前者的錨點是自簽的需要被打包進 App 用于驗證,后者的錨點可能本來就存在系統之中了。不過我腦補了這么的一個坑:
假如我們使用的是 CA 根證書簽署的數字證書,而且只用這個 CA 根證書作為錨點,在不驗證域名的情況下,是不是就會在握手階段信任被同一個 CA 根證書簽名的偽造證書呢?
參考閱讀
Overriding TLS Chain Validation Correctly
上文有什么我理解得不正確、或表達不準確的地方,煩請指教。??
作者:StanOz
鏈接:http://www.lxweimin.com/p/31bcddf44b8d
來源:簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。