iOS 中對(duì) HTTPS 證書鏈的驗(yàn)證

這篇文章是我一邊學(xué)習(xí)證書驗(yàn)證一邊記錄的內(nèi)容，
稍微整理了下，共扯了三部分內(nèi)容：

  1. HTTPS 簡要原理；
  2. 數(shù)字證書的內(nèi)容、生成及驗(yàn)證；
  3. iOS 上對(duì)證書鏈的驗(yàn)證。

HTTPS 概要

HTTPS 是運(yùn)行在 TLS/SSL 之上的 HTTP，與普通的 HTTP 相比，在數(shù)據(jù)傳輸?shù)陌踩陨嫌泻艽蟮奶嵘?br> 要了解它安全性的巧妙之處，需要先簡單地了解對(duì)稱加密和非對(duì)稱加密的區(qū)別：

  • 對(duì)稱加密只有一個(gè)密鑰，加密和解密都用這個(gè)密鑰；
  • 非對(duì)稱加密有公鑰和私鑰，私鑰加密后的內(nèi)容只有公鑰才能解密，公鑰加密的內(nèi)容只有私鑰才能解密。

為了提高安全性，我們常用的做法是使用對(duì)稱加密的手段加密數(shù)據(jù)?？墒侵皇褂脤?duì)稱加密的話，雙方通信的開始總會(huì)以明文的方式傳輸密鑰。那么從一開始這個(gè)密鑰就泄露了，談不上什么安全。所以 TLS/SSL 在握手的階段，結(jié)合非對(duì)稱加密的手段，保證只有通信雙方才知道對(duì)稱加密的密鑰。大概的流程如下：

TSL:SSL_handshake.png

所以，HTTPS 實(shí)現(xiàn)傳輸安全的關(guān)鍵是：在 TLS/SSL 握手階段保證僅有通信雙方得到 Session Key！

數(shù)字證書的內(nèi)容

X.509 應(yīng)該是比較流行的 SSL 數(shù)字證書標(biāo)準(zhǔn)，包含（但不限于）以下的字段：

字段 值說明
對(duì)象名稱（Subject Name） 用于識(shí)別該數(shù)字證書的信息
共有名稱（Common Name） 對(duì)于客戶證書，通常是相應(yīng)的域名
證書頒發(fā)者（Issuer Name） 發(fā)布并簽署該證書的實(shí)體的信息
簽名算法（Signature Algorithm） 簽名所使用的算法
序列號(hào)（Serial Number） 數(shù)字證書機(jī)構(gòu)（Certificate Authority， CA）給證書的唯一整數(shù)，一個(gè)數(shù)字證書一個(gè)序列號(hào)
生效期（Not Valid Before） (｀?ω?′)
失效期（Not Valid After） (╯°口°)╯(┴—┴
公鑰（Public Key） 可公開的密鑰
簽名（Signature） 通過簽名算法計(jì)算證書內(nèi)容后得到的數(shù)據(jù)，用于驗(yàn)證證書是否被篡改

除了上述所列的字段，還有很多拓展字段，在此不一一詳述。

下圖為 Wikipedia 的公鑰證書：

wikipedia_cer.png

數(shù)字證書的生成及驗(yàn)證

數(shù)字證書的生成是分層級(jí)的，下一級(jí)的證書需要其上一級(jí)證書的私鑰簽名。
所以后者是前者的證書頒發(fā)者，也就是說上一級(jí)證書的 Subject Name 是其下一級(jí)證書的 Issuer Name。

在得到證書申請(qǐng)者的一些必要信息（對(duì)象名稱，公鑰私鑰）之后，證書頒發(fā)者通過 SHA-256 哈希得到證書內(nèi)容的摘要，再用自己的私鑰給這份摘要加密，得到數(shù)字簽名。綜合已有的信息，生成分別包含公鑰和私鑰的兩個(gè)證書。

扯到這里，就有幾個(gè)問題：

問：如果說發(fā)布一個(gè)數(shù)字證書必須要有上一級(jí)證書的私鑰加密，那么最頂端的證書——根證書怎么來的？

根證書是自簽名的，即用自己的私鑰簽名，不需要其他證書的私鑰來生成簽名。

問：怎么驗(yàn)證證書是有沒被篡改？

當(dāng)客戶端走 HTTPS 訪問站點(diǎn)時(shí)，服務(wù)器會(huì)返回整個(gè)證書鏈。以下圖的證書鏈為例：

chain_hierarchy.png

要驗(yàn)證 *.wikipedia.org 這個(gè)證書有沒被篡改，就要用到 GlobalSign Organization Validation CA - SHA256 - G2 提供的公鑰解密前者的簽名得到摘要 Digest1，我們的客戶端也計(jì)算前者證書的內(nèi)容得到摘要 Digest2。對(duì)比這兩個(gè)摘要就能知道前者是否被篡改。后者同理，使用 GlobalSign Root CA 提供的公鑰驗(yàn)證。當(dāng)驗(yàn)證到到受信任的根證書時(shí)，就能確定 *.wikipedia.org 這個(gè)證書是可信的。

問：為什么上面那個(gè)根證書 GlobalSign Root CA 是受信任的？

數(shù)字證書認(rèn)證機(jī)構(gòu)（Certificate Authority, CA）簽署和管理的 CA 根證書，會(huì)被納入到你的瀏覽器和操作系統(tǒng)的可信證書列表中，并由這個(gè)列表判斷根證書是否可信。所以不要隨便導(dǎo)入奇奇怪怪的根證書到你的操作系統(tǒng)中。

問：生成的數(shù)字證書（如 *.wikipedia.org）都可用來簽署新的證書嗎？

不一定。如下圖，拓展字段里面有個(gè)叫 Basic Constraints 的數(shù)據(jù)結(jié)構(gòu)，里面有個(gè)字段叫路徑長度約束（Path Length Constraint），表明了該證書能繼續(xù)簽署 CA 子證書的深度，這里為0，說明這個(gè) GlobalSign Organization Validation CA - SHA256 - G2 只能簽署客戶端證書，而客戶端證書不能用于簽署新的證書，CA 子證書才能這么做。

path_length_constraint.png

iOS 上對(duì)證書鏈的驗(yàn)證

在 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 中，證書是否有效的標(biāo)準(zhǔn)是：

信任鏈中如果只含有有效證書并且以可信錨點(diǎn)（trusted anchor）結(jié)尾，那么這個(gè)證書就被認(rèn)為是有效的。

其中可信錨點(diǎn)指的是系統(tǒng)隱式信任的證書，通常是包括在系統(tǒng)中的 CA 根證書。不過你也可以在驗(yàn)證證書鏈時(shí)，設(shè)置自定義的證書作為可信的錨點(diǎn)。

NSURLSession 實(shí)現(xiàn) HTTPS

具體到使用 NSURLSession 走 HTTPS 訪問網(wǎng)站，-URLSession:didReceiveChallenge:completionHandler: 回調(diào)中會(huì)收到一個(gè) challenge，也就是質(zhì)詢，需要你提供認(rèn)證信息才能完成連接。這時(shí)候可以通過 challenge.protectionSpace.authenticationMethod 取得保護(hù)空間要求我們認(rèn)證的方式，如果這個(gè)值是 NSURLAuthenticationMethodServerTrust 的話，我們就可以插手 TLS 握手中“驗(yàn)證數(shù)字證書有效性”這一步。

默認(rèn)的實(shí)現(xiàn)

系統(tǒng)的默認(rèn)實(shí)現(xiàn)（也即代理不實(shí)現(xiàn)這個(gè)方法）是驗(yàn)證這個(gè)信任鏈，結(jié)果是有效的話則根據(jù) serverTrust 創(chuàng)建 credential 用于同服務(wù)端確立 SSL 連接。否則會(huì)得到 “The certificate for this server is invalid...” 這樣的錯(cuò)誤而無法訪問。

比如在訪問 https://www.google.com 的時(shí)候咧，我們不實(shí)現(xiàn)這個(gè)方法也能訪問成功的。系統(tǒng)對(duì) Google 服務(wù)器返回來的證書鏈，從葉節(jié)點(diǎn)證書往根證書層層驗(yàn)證（有效期、簽名等等），遇到根證書時(shí)，發(fā)現(xiàn)作為可信錨點(diǎn)的它存在與可信證書列表中，那么驗(yàn)證就通過，允許與服務(wù)端建立連接。

google.png

而當(dāng)我們?cè)L問 https://www.12306.cn 時(shí)，就會(huì)出現(xiàn) "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." 的錯(cuò)誤。原因就是系統(tǒng)在驗(yàn)證到根證書時(shí)，發(fā)現(xiàn)它是自簽名、不可信的。

12306.png

自定義實(shí)現(xiàn)

如果我們要實(shí)現(xiàn)這個(gè)代理方法的話，需要提供 NSURLSessionAuthChallengeDisposition（處置方式）和 NSURLCredential（資格認(rèn)證）這兩個(gè)參數(shù)給 completionHandler 這個(gè) block：

-(void)URLSession:(NSURLSession *)session 
        didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
        completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, 
                    NSURLCredential * _Nullable))completionHandler {
    
    // 如果使用默認(rèn)的處置方式，那么 credential 就會(huì)被忽略
    NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling;
    NSURLCredential *credential = nil;
    
    if ([challenge.protectionSpace.authenticationMethod
            isEqualToString: 
            NSURLAuthenticationMethodServerTrust]) {

        /* 調(diào)用自定義的驗(yàn)證過程 */
        if ([self myCustomValidation:challenge]) {  
            credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];
            if (credential) {
                disposition = NSURLSessionAuthChallengeUseCredential;
            }   
        } else {
            /* 無效的話，取消 */
            disposition = NSURLSessionAuthChallengeCancelAuthenticationChallenge
        }
    }        
    if (completionHandler) {
        completionHandler(disposition, credential);
    } 
}

在 [self myCustomValidation:challenge] 調(diào)用自定義驗(yàn)證過程，結(jié)果是有效的話才創(chuàng)建 credential 確立連接。
自定義的驗(yàn)證過程，需要先拿出一個(gè) SecTrustRef 對(duì)象，它是一種執(zhí)行信任鏈驗(yàn)證的抽象實(shí)體，包含著驗(yàn)證策略（SecPolicyRef）以及一系列受信任的錨點(diǎn)證書，而我們能做的也是修改這兩樣?xùn)|西而已。

SecTrustRef trust = challenge.protectionSpace.serverTrust;

拿到 trust 對(duì)象之后，可以用下面這個(gè)函數(shù)對(duì)它進(jìn)行驗(yàn)證。

static BOOL serverTrustIsVaild(SecTrustRef trust) {
    BOOL allowConnection = NO;

// 假設(shè)驗(yàn)證結(jié)果是無效的
SecTrustResultType trustResult = kSecTrustResultInvalid;

// 函數(shù)的內(nèi)部遞歸地從葉節(jié)點(diǎn)證書到根證書的驗(yàn)證
OSStatus statue = SecTrustEvaluate(trust, &trustResult);

    if (statue == noErr) {
    // kSecTrustResultUnspecified: 系統(tǒng)隱式地信任這個(gè)證書
    // kSecTrustResultProceed: 用戶加入自己的信任錨點(diǎn)，顯式地告訴系統(tǒng)這個(gè)證書是值得信任的

    allowConnection = (trustResult == kSecTrustResultProceed 
                                || trustResult == kSecTrustResultUnspecified);
    }
    return allowConnection;
}

這個(gè)函數(shù)什么時(shí)候調(diào)用完全取決于你的需求，如果你不想對(duì)驗(yàn)證策略做修改而直接調(diào)用的話，那你居然還看到這里！？(╯‵□′)╯︵┻━┻

域名驗(yàn)證

可以通過以下的代碼獲得當(dāng)前的驗(yàn)證策略：

CFArrayRef policiesRef;
SecTrustCopyPolicies(trust, &policiesRef);

打印 policiesRef 后，你會(huì)發(fā)現(xiàn)默認(rèn)的驗(yàn)證策略就包含了域名驗(yàn)證，即“服務(wù)器證書上的域名和請(qǐng)求域名是否匹配”。如果你的一個(gè)證書需要用來連接不同域名的主機(jī)，或者你直接用 IP 地址去連接，那么你可以重設(shè)驗(yàn)證策略以忽略域名驗(yàn)證:

NSMutableArray *policies = [NSMutableArray array];
    
// BasicX509 不驗(yàn)證域名是否相同
SecPolicyRef policy = SecPolicyCreateBasicX509();
[policies addObject:(__bridge_transfer id)policy];
SecTrustSetPolicies(trust, (__bridge CFArrayRef)policies);

然后再調(diào)用 serverTrustIsVaild() 驗(yàn)證。

但是如果不驗(yàn)證域名的話，安全性就會(huì)大打折扣。拿瀏覽器舉??：

試想你要傳輸報(bào)文到 https://www.real-website.com ，然而由于域名劫持，把你帶到了 https://www.real-website.cn 這個(gè)??網(wǎng)站，大概有以下兩種結(jié)果：

  1. 這個(gè)偽造網(wǎng)站的證書是非 CA 頒布的偽造證書的話，那么瀏覽器會(huì)提醒你這個(gè)證書不可信；
  2. 這個(gè)偽造網(wǎng)站也使用了 CA 頒布的證書，由于我們不做域名驗(yàn)證，你的瀏覽器不會(huì)有任何的警告。

你可能會(huì)問：公鑰證書是每個(gè)人都能得到的，釣魚網(wǎng)站能不能返回真正的公鑰證書給我們呢？

我覺得是可以的，然而這并沒有什么卵用。沒有私鑰的釣魚服務(wù)器無法獲得第三個(gè)隨機(jī)數(shù)，無法生成 Session Key，也就不能對(duì)我們傳給它的數(shù)據(jù)進(jìn)行解密了。

自簽名的證書鏈驗(yàn)證

在 App 中想要防止上面提到的中間人公雞攻擊，比較好的做法是將公鑰證書打包進(jìn) App 中，然后在收到服務(wù)端證書鏈的時(shí)候，能夠有效地驗(yàn)證服務(wù)端是否可信，這也是驗(yàn)證自簽名的證書鏈所必須做的。

假設(shè)你的服務(wù)器返回：[你的自簽名的根證書] -- [你的二級(jí)證書] -- [你的客戶端證書]，系統(tǒng)是不信任這個(gè)三個(gè)證書的。
所以你在驗(yàn)證的時(shí)候需要將這三個(gè)的其中一個(gè)設(shè)置為錨點(diǎn)證書，當(dāng)然，多個(gè)也行。

比如將 [你的二級(jí)證書] 作為錨點(diǎn)后，SecTrustEvaluate() 函數(shù)只要驗(yàn)證到 [你的客戶端證書] 確實(shí)是由 [你的二級(jí)證書] 簽署的，那么驗(yàn)證結(jié)果為 kSecTrustResultUnspecified，表明了 [你的客戶端證書] 是可信的。下面是設(shè)置錨點(diǎn)證書的做法：

NSMutableArray *certificates = [NSMutableArray array];

NSDate *cerData = /* 在 App Bundle 中你用來做錨點(diǎn)的證書數(shù)據(jù)，證書是 CER 編碼的，常見擴(kuò)展名有：cer, crt...*/

SecCertificateRef cerRef = SecCertificateCreateWithData(NULL, (__bridge CFDataRef)cerData);

[certificates addObject:(__bridge_transfer id)cerRef];

// 設(shè)置錨點(diǎn)證書。
SecTrustSetAnchorCertificates(trust, (__bridge CFArrayRef)certificates);

只調(diào)用 SecTrustSetAnchorCertificates () 這個(gè)函數(shù)的話，那么就只有作為參數(shù)被傳入的證書作為錨點(diǎn)證書，連系統(tǒng)本身信任的 CA 證書不能作為錨點(diǎn)驗(yàn)證證書鏈。要想恢復(fù)系統(tǒng)中 CA 證書作為錨點(diǎn)的功能，還要再調(diào)用下面這個(gè)函數(shù)：

// true 代表僅被傳入的證書作為錨點(diǎn)，false 允許系統(tǒng) CA 證書也作為錨點(diǎn)
SecTrustSetAnchorCertificatesOnly(trust, false);

這樣，再調(diào)用 serverTrustIsVaild() 驗(yàn)證證書有效性就能成功了。

CA 證書鏈的驗(yàn)證

上面說的是沒經(jīng)過 CA 認(rèn)證的自簽證書的驗(yàn)證，而 CA 的證書鏈的驗(yàn)證方式也是一樣，不同點(diǎn)在不可信錨點(diǎn)的證書類型不一樣而已：前者的錨點(diǎn)是自簽的需要被打包進(jìn) App 用于驗(yàn)證，后者的錨點(diǎn)可能本來就存在系統(tǒng)之中了。不過我腦補(bǔ)了這么的一個(gè)坑：

假如我們使用的是 CA 根證書簽署的數(shù)字證書，而且只用這個(gè) CA 根證書作為錨點(diǎn)，在不驗(yàn)證域名的情況下，是不是就會(huì)在握手階段信任被同一個(gè) CA 根證書簽名的偽造證書呢？

參考閱讀

iOS安全系列之一：HTTPS

iOS安全系列之二：HTTPS進(jìn)階

Overriding TLS Chain Validation Correctly

HTTPS Server Trust Evaluation

上文有什么我理解得不正確、或表達(dá)不準(zhǔn)確的地方，煩請(qǐng)指教。??

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

推薦閱讀更多精彩內(nèi)容