詳解HTTP/HTTPS（二）——HTTPS協議

HTTP/HTTPS協議無疑是面試中最常問的幾個計網協議之一。然而網上很多博客都寫得偏簡略，不夠全面。於是我便打算做一個整合。內容較多，大致會分爲兩篇篇博客，一篇介紹HTTP協議，一篇介紹HTTPS協議。

《詳解HTTP/HTTPS（一）——HTTP協議》

《詳解HTTP/HTTPS（二）——HTTPS協議》

HTTP協議全稱爲超文本傳輸協議，而HTTPS全稱爲超文本安全傳輸協議。HTTPS是構建在SSL/TLS協議之上的HTTP協議，即HTTP直接與運輸層的TCP協議進行通信，而HTTPS則需要先將報文傳給會話層的SSL/TLS協議，經加密等操作後再將報文交由運輸層的TCP協議進行傳輸。因此要掌握HTTPS協議，我們首先需要弄清楚SSL/TLS協議是什麼。

一、SSL協議介紹

　　安全套接字（Secure Socket Layer，SSL）協議是Web瀏覽器與Web服務器之間安全交換信息的協議，它提供了兩個基本的安全服務：鑑別與保密。SSL是Netscape於1994年開發的，用以保障在Internet上數據傳輸之安全，利用數據加密技術，可確保數據在網絡上之傳輸過程中不會被截取。後來成爲了世界上最著名的web安全機制，所有主要的瀏覽器都支持SSL協議。SSL協議最新版更名爲TLS協議。

二、SSL協議的三個特性

1. 保密。通過加密來傳輸數據。安全套接層協議採用的加密技術既有對稱密鑰，也有公開密鑰。具體來說，就是客戶機與服務器交換數據之前，先交換SSL初始握手信息。在SSL握手信息中採用了各種加密技術，以保證其機密性和數據的完整性，並且經數字證書鑑別，這樣就可以防止非法用戶破譯。
2. 身份鑑別。用戶和服務器在通信前需要進行合法性認證。使得用戶和服務器能夠確信數據將被髮送到正確的客戶機和服務器上。客戶機和服務器都有各自的識別號，由公開密鑰編排。爲了驗證用戶，安全套接層協議要求在握手交換數據中做數字認證，以此來確保用戶的合法性。認證又分爲可選的客戶端認證，和強制的服務器端認證。
3. 完整性。傳送的消息包括消息完整性檢查（使用MAC）。安全套接層協議採用密碼雜湊函數和機密共享的方法，提供完整信息性的服務，來建立客戶機與服務器之間的安全通道，使所有經過安全套接層協議處理的業務，在傳輸過程中都能完整、準確無誤地到達目的地。

三、SSL位置與結構

（一）位置

SSL介於應用層和TCP層之間。應用層數據不再直接傳遞給傳輸層，而是傳遞給SSL層，SSL層對從應用層收到的數據進行加密，並增加自己的SSL頭。如下圖：

（二）結構

SSL的體系結構中包含兩個協議子層，其中底層是SSL記錄協議層（SSL Record Protocol Layer）；高層是SSL握手協議層（SSL HandShake Protocol Layer）。

SSL記錄協議層的作用是爲高層協議提供基本的安全服務。SSL紀錄協議針對HTTP協議進行了特別的設計，使得超文本的傳輸協議HTTP能夠在SSL運行。紀錄封裝各種高層協議，具體實施壓縮解壓縮、加密解密、計算和校驗MAC等與安全有關的操作。

SSL握手協議層包括SSL握手協議（SSL HandShake Protocol）、SSL密碼參數修改協議（SSL Change Cipher Spec Protocol）和SSL告警協議（SSL Alert Protocol）。握手層的這些協議用於SSL管理信息的交換，允許應用協議傳送數據之間相互驗證，協商加密算法和生成密鑰等。SSL握手協議最主要的作用是協調客戶和服務器的狀態，使雙方能夠達到狀態的同步。

四、SSL握手過程

SSL握手部分主要做了三件事：一是協議加密算法、二是認證服務器，三是建立用於加密和計算MAC的密鑰。具體過程如下：

整個握手部分又可以分爲四個階段，接下來我們一個個對其進行探究。

（一）SSL建立的第一階段

客戶端首先發送ClientHello消息到服務端，服務端收到ClientHello消息後，再發送ServerHello消息迴應客戶端。

1、Client Hello

握手第一步是客戶端向服務端發送 Client Hello 消息，這個消息裏包含了一個客戶端生成的隨機數 Random1、客戶端支持的加密套件（Support Ciphers）和 SSL Version 等信息。

Client Hello中涉及到的具體消息如下：

• 客戶端版本：按優先級列出客戶端支持的協議版本，首選客戶端希望支持的最新協議版本。
• 客戶端隨機數Random
• 會話ID（Session id）：如果客戶端第一次連接到服務器，那麼這個字段就會保持爲空。上圖中該字段爲空，說明這是第一次連接到服務器。如果該字段不爲空，說明以前是與服務器有連接的，在此期間，服務器將使用Session ID映射對稱密鑰，並將Session ID存儲在客戶端瀏覽器中，爲映射設置一個時間限。如果瀏覽器將來連接到同一臺服務器（在時間到期之前），它將發送Session ID，服務器將對映射的Session ID進行驗證，並使用以前用過的對稱密鑰來恢復Session，這種情況下不需要完全握手。也叫作SSL會話恢復。後面會有介紹。
• 加密套件：客戶端會給服務器發送自己已經知道的密碼套件列表，這是由客戶按優先級排列的，但完全由服務器來決定發送與否。TLS中使用的密碼套件有一種標準格式。上面的報文中，客戶端發送了74套加密套件。服務端會從中選出一種來作爲雙方共同的加密套件。
• 壓縮方法：爲了減少帶寬，可以進行壓縮。但從成功攻擊TLS的事例中來看，其中使用壓縮時的攻擊可以捕獲到用HTTP頭髮送的參數，這個攻擊可以劫持Cookie，這個漏洞我們稱爲CRIME。從TLS 1.3開始，協議就禁用了TLS壓縮。
• 擴展包：
• 其他參數（如服務器名稱，填充，支持的簽名算法等）可以作爲擴展名使用。這些是客戶端問候的一部分，如果已收到客戶端問候，接下來就是服務器的確認，服務器將發送服務器問候。

2、Server Hello

收到客戶端問候之後服務器必鬚髮送服務器問候信息，服務器會檢查指定諸如TLS版本和算法的客戶端問候的條件，如果服務器接受並支持所有條件，它將發送其證書以及其他詳細信息，否則，服務器將發送握手失敗消息。

如果接受，第二步是服務端向客戶端發送 Server Hello 消息，這個消息會從 Client Hello 傳過來的 Support Ciphers 裏確定一份加密套件，這個套件決定了後續加密和生成摘要時具體使用哪些算法，另外還會生成一份隨機數 Random2。注意，至此客戶端和服務端都擁有了兩個隨機數（Random1+ Random2），這兩個隨機數會在後續生成對稱祕鑰時用到。

ServerHello中涉及到的具體參數：

• 服務器版本Version：服務器會選擇客戶端支持的最新版本。
• 服務器隨機數Random：服務器和客戶端都會生成32字節的隨機數。用來創建加密密鑰。
• 加密套件：服務器會從客戶端發送的加密套件列表中選出一個加密套件。
• 會話ID（Session ID）：服務器將約定的Session參數存儲在TLS緩存中，並生成與其對應的Session id。它與Server Hello一起發送到客戶端。客戶端可以寫入約定的參數到此Session id，並給定到期時間。客戶端將在Client Hello中包含此id。如果客戶端在此到期時間之前再次連接到服務器，則服務器可以檢查與Session id對應的緩存參數，並重用它們而無需完全握手。這非常有用，因爲服務器和客戶端都可以節省大量的計算成本。在涉及亞馬遜和谷歌等流量巨大的應用程序時，這種方法存在缺點。每天都有數百萬人連接到服務器，服務器必須使用Session密鑰保留所有Session參數的TLS緩存。這是一個巨大的開銷。爲了解決這個問題，在擴展包里加入了Session Tickets, 在這裏，客戶端可以在client hello中指定它是否支持Session Ticket。然後，服務器將創建一個新的會話票證(Session Ticket)，並使用只有服務器知道的經過私鑰加密的Session參數。它將存儲在客戶端上，因此所有Session數據僅存儲在客戶端計算機上，但Ticket仍然是安全的，因爲該密鑰只有服務器知道。此數據可以作爲名爲Session Ticket的擴展包含在Client Hello中。
• 壓縮算法：如果支持，服務器將同意客戶端的首選壓縮方法。
• 擴展包

這個階段之後，客戶端服務端知道了下列內容：

• SSL版本
• 密鑰交換、信息驗證和加密算法
• 壓縮方法
• 有關密鑰生成的兩個隨機數。

（二）SSL握手第二階段

服務器向客戶端發送消息。

服務器啓動SSL握手第2階段，是本階段所有消息的唯一發送方，客戶機是所有消息的唯一接收方。該階段分爲4步：

第一步，證書：服務器將數字證書和到根CA整個鏈發給客戶端，使客戶端能用服務器證書中的服務器公鑰認證服務器。

第二步，服務器密鑰交換（可選）：這裏視密鑰交換算法而定

第三步，證書請求：服務端可能會要求客戶自身進行驗證。

第四步，服務器握手完成：第二階段的結束，第三階段開始的信號

1、Certificate消息（可選）

一般情況下，除了會話恢復時不需要發送該消息，在SSL握手的全流程中，都需要包含該消息。消息包含一個X.509證書，證書中包含公鑰，發給客戶端用來驗證簽名或在密鑰交換的時候給消息加密。

這一步是服務端將自己的證書下發給客戶端，讓客戶端驗證自己的身份，客戶端驗證通過後取出證書中的公鑰。

2、Server Key Exchange（可選）

根據之前在ClientHello消息中包含的CipherSuite信息，決定了密鑰交換方式（例如RSA或者DH），因此在Server Key Exchange消息中便會包含完成密鑰交換所需的一系列參數。

3、Certificate Request（可選）

這一步是可選的，如果在對安全性要求高的常見可能用到。服務器用來驗證客戶端。服務器端發出Certificate Request消息，要求客戶端發他自己的證書過來進行驗證。該消息中包含服務器端支持的證書類型（RSA、DSA、ECDSA等）和服務器端所信任的所有證書發行機構的CA列表，客戶端會用這些信息來篩選證書。

4、Server Hello Done

該消息表示服務器已經將所有信息發送完畢，接下來等待客戶端的消息。

（三）SSL建立第三階段

客戶端收到服務器發送的一系列消息並解析後，將本端相應的消息發送給服務器。

客戶機啓動SSL握手第三階段，是本階段所有消息的唯一發送方，服務器是所有消息的唯一接收方。該階段分爲3步：

第一步，發送證書（可選）：爲了對服務器證明自身，客戶要發送一個證書信息，這是可選的。

第二步，客戶機密鑰交換（Pre-master-secret）：客戶端將預備主密鑰用服務端的公鑰加密後發送給服務端。

第三步，證書驗證（可選），對預備祕密和隨機數進行簽名，證明自身擁有證書的公鑰。

1、Certificate（可選）

如果在第二階段服務器端要求發送客戶端證書，客戶端便會在該階段將自己的證書發送過去。服務器端在之前發送的Certificate Request消息中包含了服務器端所支持的證書類型和CA列表，因此客戶端會在自己的證書中選擇滿足這兩個條件的第一個證書發送過去。若客戶端沒有證書，則發送一個no_certificate警告。

2、Client Key exchange

根據之前從服務器端收到的隨機數，按照不同的密鑰交換算法，算出一個pre-master，發送給服務器，服務器端收到pre-master算出main master。而客戶端當然也能自己通過pre-master算出main master。如此以來雙方就算出了對稱密鑰。

如果是RSA算法，會生成一個48字節的隨機數，然後用server的公鑰加密後再放入報文中。如果是DH算法，這是發送的就是客戶端的DH參數，之後服務器和客戶端根據DH算法，各自計算出相同的pre-master secret。

本消息在給服務器發送的過程中，使用了服務器的公鑰加密。服務器用自己的私鑰解密後才能得到pre-master key.（向服務器證明自己的確持有客戶端證書私鑰。）

3、Certificate verify（可選）

只有在客戶端發送了自己證書到服務器端，這個消息才需要發送。其中包含一個簽名，對從第一條消息以來的所有握手消息的HMAC值（用master_secret）進行簽名。

（四）、SSL建立第四階段

完成握手協議，建立SSL連接。

客戶機啓動SSL握手第四階段分爲四步，前兩個消息來自客戶機，後兩個消息來自服務器。

建立起一個安全的連接，客戶端發送一個Change Cipher Spec消息，並且把協商得到的CipherSuite拷貝到當前連接的狀態之中。然後，客戶端用新的算法、密鑰參數發送一個Finished消息，這條消息可以檢查密鑰交換和認證過程是否已經成功。其中包括一個校驗值，對客戶端整個握手過程的消息進行校驗。服務器同樣發送Change Cipher Spec消息和Finished消息。握手過程完成，客戶端和服務器可以交換應用層數據進行通信。

1、ChangeCipherSpec

編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送（ChangeCipherSpec是一個獨立的協議，體現在數據包中就是一個字節的數據，用於告知服務端，客戶端已經切換到之前協商好的加密套件（Cipher Suite）的狀態，準備使用之前協商好的加密套件加密數據並傳輸了）

2、Clinet Finished

客戶端握手結束通知, 表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗（使用HMAC算法計算收到和發送的所有握手消息的摘要，然後通過RFC5246中定義的一個僞函數PRF計算出結果，加密後發送。此數據是爲了在正式傳輸應用數據之前對剛剛握手建立起來的加解密通道進行驗證。）

3、ChangeCipherSpec

4、Server Finished

服務端握手結束通知。

根據之前的握手信息，如果客戶端和服務端都能對Finish信息進行正常加解密且消息正確的被驗證，則說明握手通道已經建立成功，接下來，雙方可以使用上面產生的Session Secret對數據進行加密傳輸了。

當服務器或客戶端使用主密鑰加密數據時，它還會計算明文數據的校驗和（哈希值），這個校驗和稱爲消息驗證代碼（MAC）。然後在發送之前將MAC包含在加密數據中。密鑰用於從數據中生成MAC，以確保傳輸過程中攻擊者無法從數據中生成相同的MAC，故而MAC被稱爲HMAC（哈希消息認證碼）。另一方面，在接收到消息時，解密器將MAC與明文分開，然後用它的密鑰計算明文的校驗和，並將其與接收到的MAC進行比較，如果匹配，那我們就可以得出結論：數據在傳輸過程中沒有被篡改。

五、SSL記錄協議詳解

SSL記錄協議主要用來實現對數據塊的分塊、加密解密、壓縮與解壓縮、完整性檢查及封裝各種高層協議。結構如下

（一）SSL記錄協議的內容

1. 內容類型
2. 協議版本號，目前有2.0和3.0版本
3. 記錄數據的長度
4. 數據由載荷
5. 散列算法計算消息認證代碼

（二）SSL記錄協議工作原理

1. 將消息分割爲多個片段
2. 對每個片段進行壓縮
3. 加上片段編號(防止重放攻擊)計算消息驗證碼MAC值(保證數據完整性)，追加在壓縮片段
4. 對稱密碼加密
5. 加上數據類型、版本號、壓縮後的長度組成的報頭， 就是最終的報文數據

六、SSL會話恢復

（一）概述

會話恢復是指只要客戶端和服務器已經通信過一次，它們就可以通過會話恢復的方式來跳過整個握手階段二直接進行數據傳輸。過程如下：

SSL協議採用會話恢復的方式來減少SSL握手過程中造成的巨大開銷。

（二）會話緩存機制

爲了加快建立握手的速度，減少協議帶來的性能降低和資源消耗(具體分析在後文)，TLS 協議有兩類會話緩存機制：

1. 會話標識 session ID：由服務器端支持，協議中的標準字段，因此基本所有服務器都支持，服務器端保存會話ID以及協商的通信信息，佔用服務器資源較多;
2. 會話記錄 session ticket：需要服務器和客戶端都支持，屬於一個擴展字段，支持範圍約60%(無可靠統計與來源)，將協商的通信信息加密之後發送給客戶端保存，密鑰只有服務器知道，佔用服務器資源很少。

二者對比，主要是保存協商信息的位置與方式不同，類似與 http 中的 session 與 cookie。二者都存在的情況下，優先使用 session_ticket。

（三）會話恢復過程

• Session ID機制

1. 如果客戶端和服務器之間曾經建立了連接，服務器會在握手成功後返回 session ID，並保存對應的通信參數在服務器中;
2. 如果客戶端再次需要和該服務器建立連接，則在 client_hello 中 session ID 中攜帶記錄的信息，發送給服務器;
3. 服務器根據收到的 session ID 檢索緩存記錄，如果沒有檢索到或檢索到的緩存已過期，則按照正常的握手過程進行;
4. 如果檢索到對應的緩存記錄，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個信息作用類似。其中encrypted_handshake_message 是到當前的通信參數與 master_secret的hash 值;
5. 如果客戶端能夠驗證服務器加密的數據，則客戶端同樣發送 change_cipher_spec 與 encrypted_handshake_message 信息;
6. 服務器驗證數據通過，則握手建立成功，開始進行正常的加密數據通信。

• Session ticket機制

1. 如果客戶端和服務器之間曾經建立了連接，服務器會在 new_session_ticket 數據中攜帶加密的 session_ticket 信息，客戶端保存;
2. 如果客戶端再次需要和該服務器建立連接，則在 client_hello 中擴展字段 session_ticket 中攜帶加密信息，一起發送給服務器;
3. 服務器解密 sesssion_ticket 數據，如果能夠解密失敗，則按照正常的握手過程進行;
4. 如果解密成功，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個信息作用與 session ID 中類似;
5. 如果客戶端能夠驗證通過服務器加密數據，則客戶端同樣發送 change_cipher_spec與encrypted_handshake_message 信息;
6. 服務器驗證數據通過，則握手建立成功，開始進行正常的加密數據通信。

七、HTTPS協議

（一）HTTPS的定義

所謂 HTTPS，其實就是身披 SSL 協議這層外殼的HTTP，即HTTPS=HTTP+SSL/TLS

（二）HTTP三大問題的解決

首先通過證書驗證並獲取服務器非對稱加密算法的公開密鑰，接着採用非對稱加密進行身份驗證和對稱加密密鑰的協商，其次使用對稱加密進行信息加密，最後通過散列算法進行完整性校驗。

（三）HTTPS的通信過程

首先先通過TCP三次握手建立TCP連接，接着在TCP連接之上進行SSL連接。

（四）HTTPS的侷限性

1. 多了一層SSL協議，需要耗費更多服務器資源
2. 通信過程更復雜，不如HTTP高效，流量成本高
3. SSL證書需要一定的費用，且功能越強大的證書費用越高