前言

HTTP 是基于 TCP/IP 協(xié)議的應(yīng)用層協(xié)議。它不涉及數(shù)據(jù)包（packet）傳輸，主要規(guī)定了客戶端和服務(wù)器之間的通信格式，默認(rèn)使用80端口。但是傳輸?shù)倪^程是通過明文來傳輸。帶來了三大風(fēng)險

1. 竊聽風(fēng)險（eavesdropping）：第三方可以獲知通信內(nèi)容。
2. 篡改風(fēng)險（tampering）：第三方可以修改通信內(nèi)容。
3. 冒充風(fēng)險（pretending）：第三方可以冒充他人身份參與通信。

在安全問題日益突出的情況下，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織 ISOC 基于 HTTP 協(xié)議通信推出了 SSL/TLS 協(xié)議 也就是 HTTPS ， HTTPS 協(xié)議具有

1. 所有信息都是加密傳播，第三方無法竊聽。
2. 具有校驗(yàn)機(jī)制，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)。
3. 配備身份證書，防止身份被冒充。

數(shù)字證書

數(shù)字證書：該證書包含了公鑰等信息，一般是由服務(wù)器發(fā)給客戶端，接收方通過驗(yàn)證這個證書是不是由信賴的CA簽發(fā)，或者與本地的證書相對比，來判斷證書是否可信；假如需要雙向驗(yàn)證，則服務(wù)器和客戶端都需要發(fā)送數(shù)字證書給對方驗(yàn)證；

發(fā)展歷史

1994年，NetScape公司設(shè)計(jì)了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。
1995年，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴(yán)重漏洞。
1996年，SSL 3.0版問世，得到大規(guī)模應(yīng)用。
1999年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司，發(fā)布了SSL的升級版TLS 1.0版。
2006年和2008年，TLS進(jìn)行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。

目前，應(yīng)用最廣泛的是TLS 1.0，接下來是SSL 3.0。但是，主流瀏覽器都已經(jīng)實(shí)現(xiàn)了TLS 1.2的支持。
TLS 1.0通常被標(biāo)示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

通信原理

握手階段分為 4 個步驟

1、客戶端發(fā)起請求 (ClientHello)

客戶端向服務(wù)器提供

1. 支持的協(xié)議版本，比如TLS 1.0版。
2. 一個客戶端生成的隨機(jī)數(shù)，稍后用于生成"對話密鑰"。
3. 支持的加密方法，比如RSA公鑰加密。
4. 支持的壓縮方法。

2、服務(wù)器回應(yīng) (SeverHello)

服務(wù)器收到 ClientHello， 并作出回應(yīng)。此時服務(wù)器向客戶端發(fā)送

1. 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。
2. 一個服務(wù)器生成的隨機(jī)數(shù)，稍后用于生成"對話密鑰"。
3. 確認(rèn)使用的加密方法，比如RSA公鑰加密。
4. 服務(wù)器證書。

3、客戶端回應(yīng)

客戶端收到服務(wù)器回應(yīng)以后，首先驗(yàn)證服務(wù)器證書。如果證書不是可信機(jī)構(gòu)頒布、或者證書中的域名與實(shí)際域名不一致、或者證書已經(jīng)過期，由其選擇是否還要繼續(xù)通信。
驗(yàn)證通過之后客戶端會向服務(wù)端發(fā)送

1. 一個隨機(jī)數(shù)（pre-master key）。該隨機(jī)數(shù)用服務(wù)器公鑰加密，防止被竊聽(服務(wù)器可以通過私鑰來解密出公鑰加密的內(nèi)容)。
2. 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
3. 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供服務(wù)器校驗(yàn)。

4、服務(wù)器最后回應(yīng)

服務(wù)器收到客戶端的第三個隨機(jī)數(shù)pre-master key之后，根據(jù)之前的 2 個隨機(jī)數(shù)（ClientHello 和 SeverHello 階段）計(jì)算生成本次會話所用的"會話密鑰"。然后，向客戶端最后發(fā)送下面信息。

1. 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
2. 服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供客戶端校驗(yàn)。

傳輸過程

在結(jié)束上面4次握手通信之后，客戶端和服務(wù)端就可以進(jìn)入安全的傳輸過程。使用普通的HTTP協(xié)議，只不過用"會話密鑰"加密解密內(nèi)容。

iOS 中關(guān)于 HTTPS 的驗(yàn)證

iOS 關(guān)于 HTTPS 驗(yàn)證的 API 在 Security.Framework 框架中, 在使用 NSURLSession 時

在正規(guī)的 CA 機(jī)構(gòu)申請證書的情況下：

(1) 在回調(diào)

- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task
                            didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge 
                              completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * _Nullable credential))completionHandler;

中我們會收到系統(tǒng)的鑒定請求。獲取需要驗(yàn)證的信任對象(Trust Object)challenge.protectionSpace.serverTrust

(2) 使用系統(tǒng)默認(rèn)驗(yàn)證方式驗(yàn)證Trust Object。SecTrustEvaluate 方法會根據(jù)Trust Object的驗(yàn)證策略，一級一級往上，驗(yàn)證證書鏈上每一級數(shù)字簽名的有效性，從而評估證書的有效性。

(3) 第二步驗(yàn)證通過，就可以直接驗(yàn)證通過，進(jìn)入到下一步：使用Trust Object生成一份憑證([NSURLCredential credentialForTrust:serverTrust])，調(diào)用 completionHandler(disposition, credential) 來完成鑒勸過程。

自生成證書的情況下：
需要在第二步之前，調(diào)用SecTrustSetAnchorCertificates來注冊自己的證書到系統(tǒng)信任列表中，在進(jìn)行上面的第二部過程即可完成校驗(yàn)。