深刻淺出 HTTPS (詳解版)

時間 2021-01-02

標籤 html 算法瀏覽器安全性能優化服務器網絡 session dom 函數欄目 HTML 简体版

原文原文鏈接

前言

1990年互聯網誕生之初，就已經開始用超文本傳輸協議 HTTP 傳輸數據，這也是爲何如今網頁地址都是以 http 開頭的緣由。可是HTTP協議傳輸數據是明文傳輸，任意的人抓包就能看到傳輸的數據，這顯然不安全。1994年，Netscape 公司用加密協議增長了 HTTP，開始在 HTTP 的基礎上加入 SSL 即安全套接層（Secure Socket Layer）。稱爲 "HTTP over SSL" 或者 "HTTP Secure"，也就是咱們如今熟知的 HTTPS。html

HTTPS 實際上是一個「很是簡單」的協議，RFC 文檔很小，只有短短的 7 頁，裏面規定了新的協議名「https」，默認端口號 443，至於其餘的什麼請求 - 應答模式、報文結構、請求方法、URI、頭字段、鏈接管理等等都徹底沿用 HTTP，沒有任何新的東西。算法

也就是說，除了協議名「http」和端口號 80 這兩點不一樣，HTTPS 協議在語法、語義上和 HTTP 徹底同樣，優缺點也「照單全收」（固然要除去「明文」和「不安全」）。瀏覽器

對於 http 請求還不是很瞭解的，能夠閱讀如下幾篇文章安全

SSL/TLS

SSL/TLS是位於TCP/IP 7層協議中的會話層，用於認證用戶和服務器，加解密數據以及維護數據的完整性，確保數據在傳輸過程當中不會被修改。性能優化

SSL 有 v2 和 v3 兩個版本，而 v1 由於有嚴重的缺陷從未公開過。SSL 發展到 v3 時已經證實了它自身是一個很是好的安全通訊協議，因而互聯網工程組 IETF 在 1999 年把它更名爲 TLS（傳輸層安全，Transport Layer Security），正式標準化，版本號從 1.0 從新算起，因此 TLS1.0 實際上就是 SSLv3.1。服務器

到今天 TLS 已經發展出了三個版本，分別是 2006 年的 1.一、2008 年的 1.2 和去年（2018）的 1.3，每一個新版本都緊跟密碼學的發展和互聯網的現狀，持續強化安全和性能，已經成爲了信息安全領域中的權威標準。網絡

目前應用的最普遍的 TLS 是 1.2，而以前的協議（TLS1.1/1.0、SSLv3/v2）都已經被認爲是不安全的，各大瀏覽器即將在 2020 年左右中止支持，因此接下來的講解都針對的是 TLS1.2。session

TLS 由記錄協議、握手協議、警告協議、變動密碼規範協議、擴展協議等幾個子協議組成，綜合使用了對稱加密、非對稱加密、身份認證等許多密碼學前沿技術。瀏覽器和服務器在使用 TLS 創建鏈接時須要選擇一組恰當的加密算法來實現安全通訊，這些算法的組合被稱爲「密碼套件」（cipher suite，也叫加密套件）。dom

SSL/TLS分爲對稱加密和非對稱加密兩種方式。函數

對稱加密

對稱加密是指加密和解密都用同一份密鑰。以下圖所示：

AES 的意思是「高級加密標準」（Advanced Encryption Standard），密鑰長度能夠是 12八、192 或 256。它是 DES 算法的替代者，安全強度很高，性能也很好，並且有的硬件還會作特殊優化，因此很是流行，是應用最普遍的對稱加密算法。

ChaCha20 是 Google 設計的另外一種加密算法，密鑰長度固定爲 256 位，純軟件運行性能要超過 AES，曾經在移動客戶端上比較流行，但 ARMv8 以後也加入了 AES 硬件優化，因此如今再也不具備明顯的優點，但仍然算得上是一個不錯算法。

非對稱加密

非對稱加密對應於一對密鑰，稱爲私鑰和公鑰，用私鑰加密後須要用公鑰解密，用公鑰加密後須要用私鑰解密。以下圖所示：

對稱加密看上去好像完美地實現了機密性，但其中有一個很大的問題：如何把密鑰安全地傳遞給對方，術語叫「密鑰交換」。

由於在對稱加密算法中只要持有密鑰就能夠解密。若是你和網站約定的密鑰在傳遞途中被黑客竊取，那他就能夠在以後隨意解密收發的數據，通訊過程也就沒有機密性可言了。

這個問題該怎麼解決呢？

你或許會說：「把密鑰再加密一下發過去就行了」，但傳輸「加密密鑰的密鑰」又成了新問題。這就像是「雞生蛋、蛋生雞」，能夠無限遞歸下去。只用對稱加密算法，是絕對沒法解決密鑰交換的問題的。

因此，就出現了非對稱加密（也叫公鑰加密算法）。

它有兩個密鑰，一個叫「公鑰」（public key），一個叫「私鑰」（private key）。兩個密鑰是不一樣的，「不對稱」，公鑰能夠公開給任何人使用，而私鑰必須嚴格保密。

公鑰和私鑰有個特別的「單向」性，雖然均可以用來加密解密，但公鑰加密後只能用私鑰解密，反過來，私鑰加密後也只能用公鑰解密。

非對稱加密能夠解決「密鑰交換」的問題。網站祕密保管私鑰，在網上任意分發公鑰，你想要登陸網站只要用公鑰加密就好了，密文只能由私鑰持有者才能解密。而黑客由於沒有私鑰，因此就沒法破解密文。

非對稱加密算法的設計要比對稱算法可貴多，在 TLS 裏只有不多的幾種，好比 DH、DSA、RSA、ECC 等。

RSA 多是其中最著名的一個，幾乎能夠說是非對稱加密的代名詞，它的安全性基於「整數分解」的數學難題，使用兩個超大素數的乘積做爲生成密鑰的材料，想要從公鑰推算出私鑰是很是困難的。10 年前 RSA 密鑰的推薦長度是 1024，但隨着計算機運算能力的提升，如今 1024 已經不安全，廣泛認爲至少要 2048 位。
ECC（Elliptic Curve Cryptography）是非對稱加密裏的「後起之秀」，它基於「橢圓曲線離散對數」的數學難題，使用特定的曲線方程和基點生成公鑰和私鑰，子算法 ECDHE 用於密鑰交換，ECDSA 用於數字簽名。

比起 RSA，ECC 在安全強度和性能上都有明顯的優點。160 位的 ECC 至關於 1024 位的 RSA，而 224 位的 ECC 則至關於 2048 位的 RSA。由於密鑰短，因此相應的計算量、消耗的內存和帶寬也就少，加密解密的性能就上去了，對於如今的移動互聯網很是有吸引力。

對稱加密的優勢是運算速度快，缺點是互聯網環境下沒法將密鑰安全的傳送給對方。非對稱加密的優勢是能夠安全的將公鑰傳遞給對方，可是運算速度慢。

看到這裏，你是否是認爲能夠拋棄對稱加密，只用非對稱加密來實現機密性呢？

這裏 TLS 把對稱加密和非對稱加密結合起來，二者互相取長補短，即能高效地加密解密，又能安全地密鑰交換。其實說穿了也很簡單：

在通訊剛開始的時候使用非對稱算法，好比 RSA、ECDHE，首先解決密鑰交換的問題。

而後用隨機數產生對稱算法使用的「會話密鑰」（session key），再用公鑰加密。由於會話密鑰很短，一般只有 16 字節或 32 字節，因此慢一點也無所謂。

對方拿到密文後用私鑰解密，取出會話密鑰。這樣，雙方就實現了對稱密鑰的安全交換，後續就再也不使用非對稱加密，全都使用對稱加密。

這樣混合加密就解決了對稱加密算法的密鑰交換問題，並且安全和性能兼顧，完美地實現了機密性。

不過這只是「萬里長征的第一步」，後面還有完整性、身份認證、不能否認等特性沒有實現，因此如今的通訊還不是絕對安全。

數字簽名與證書

黑客雖然拿不到會話密鑰，沒法破解密文，但能夠經過竊聽收集到足夠多的密文，再嘗試着修改、重組後發給網站。由於沒有完整性保證，服務器只能「照單全收」，而後他就能夠經過服務器的響應獲取進一步的線索，最終就會破解出明文。

另外，黑客也能夠僞造身份發佈公鑰。若是你拿到了假的公鑰，混合加密就徹底失效了。你覺得本身是在和「某寶」通訊，實際上網線的另外一端倒是黑客，銀行卡號、密碼等敏感信息就在「安全」的通訊過程當中被竊取了。

因此，在機密性的基礎上還必須加上完整性、身份認證等特性，才能實現真正的安全。

摘要算法

實現完整性的手段主要是摘要算法（Digest Algorithm），也就是常說的散列函數、哈希函數（Hash Function）。

你能夠把摘要算法近似地理解成一種特殊的壓縮算法，它可以把任意長度的數據「壓縮」成固定長度、並且獨一無二的「摘要」字符串，就好像是給這段數據生成了一個數字「指紋」。

換一個角度，也能夠把摘要算法理解成特殊的「單向」加密算法，它只有算法，沒有密鑰，加密後的數據沒法解密，不能從摘要逆推出原文。

摘要算法其實是把數據從一個「大空間」映射到了「小空間」，因此就存在「衝突」（collision，也叫碰撞）的可能性，就如同現實中的指紋同樣，可能會有兩份不一樣的原文對應相同的摘要。好的摘要算法必須可以「抵抗衝突」，讓這種可能性儘可能地小。

由於摘要算法對輸入具備「單向性」和「雪崩效應」，輸入的微小不一樣會致使輸出的劇烈變化，因此也被 TLS 用來生成僞隨機數（PRF，pseudo random function）。

你必定在平常工做中聽過、或者用過 MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1），它們就是最經常使用的兩個摘要算法，可以生成 16 字節和 20 字節長度的數字摘要。但這兩個算法的安全強度比較低，不夠安全，在 TLS 裏已經被禁止使用了。

目前 TLS 推薦使用的是 SHA-1 的後繼者：SHA-2。

SHA-2 其實是一系列摘要算法的統稱，總共有 6 種，經常使用的有 SHA22四、SHA25六、SHA384，分別可以生成 28 字節、32 字節、48 字節的摘要。

完整性

摘要算法保證了「數字摘要」和原文是徹底等價的。因此，咱們只要在原文後附上它的摘要，就可以保證數據的完整性。

好比，你發了條消息：「轉帳 1000 元」，而後再加上一個 SHA-2 的摘要。網站收到後也計算一下消息的摘要，把這兩份「指紋」作個對比，若是一致，就說明消息是完整可信的，沒有被修改。

若是黑客在中間哪怕改動了一個標點符號，摘要也會徹底不一樣，網站計算比對就會發現消息被竄改，是不可信的。

不過摘要算法不具備機密性，若是明文傳輸，那麼黑客能夠修改消息後把摘要也一塊兒改了，網站仍是鑑別不出完整性。

因此，真正的完整性必需要創建在機密性之上，在混合加密系統裏用會話密鑰加密消息和摘要，這樣黑客沒法得知明文，也就沒有辦法動手腳了。

這有個術語，叫哈希消息認證碼（HMAC）。

數字簽名

加密算法結合摘要算法，咱們的通訊過程能夠說是比較安全了。但這裏還有漏洞，就是通訊的兩個端點（endpoint）。

就像一開始所說的，黑客能夠假裝成網站來竊取信息。而反過來，他也能夠假裝成你，向網站發送支付、轉帳等消息，網站沒有辦法確認你的身份，錢可能就這麼被偷走了。

現實生活中，解決身份認證的手段是簽名和印章，只要在紙上寫下簽名或者蓋個章，就可以證實這份文件確實是由本人而不是其餘人發出的。

在這裏，使用非對稱加密裏的「私鑰」再加上摘要算法，就可以實現「數字簽名」，同時實現「身份認證」和「不能否認」。

數字簽名的原理其實很簡單，就是把公鑰私鑰的用法反過來，以前是公鑰加密、私鑰解密，如今是私鑰加密、公鑰解密。

但又由於非對稱加密效率過低，因此私鑰只加密原文的摘要，這樣運算量就小的多，並且獲得的數字簽名也很小，方便保管和傳輸。

簽名和公鑰同樣徹底公開，任何人均可以獲取。但這個簽名只有用私鑰對應的公鑰才能解開，拿到摘要後，再比對原文驗證完整性，就能夠像簽署文件同樣證實消息確實是你發的。

剛纔的這兩個行爲也有專用術語，叫作「簽名」和「驗籤」。

只要你和網站互相交換公鑰，就能夠用「簽名」和「驗籤」來確認消息的真實性，由於私鑰保密，黑客不能僞造簽名，就可以保證通訊雙方的身份。

好比，你用本身的私鑰簽名一個消息「我是小明」。網站收到後用你的公鑰驗籤，確認身份沒問題，因而也用它的私鑰簽名消息「我是某寶」。你收到後再用它的公鑰驗一下，也沒問題，這樣你和網站就都知道對方不是假冒的，後面就能夠用混合加密進行安全通訊了。

數字證書和 CA

到如今，綜合使用對稱加密、非對稱加密和摘要算法，是否是已經完美了呢？

不是的，這裏還有一個「公鑰的信任」問題。由於誰均可以發佈公鑰，咱們還缺乏防止黑客僞造公鑰的手段，也就是說，怎麼來判斷這個公鑰就是你或者某寶的公鑰呢？

真是「按下葫蘆又起了瓢」，安全還真是個麻煩事啊，「一環套一環」的。

咱們能夠用相似密鑰交換的方法來解決公鑰認證問題，用別的私鑰來給公鑰簽名，顯然，這又會陷入「無窮遞歸」。但此次實在是「沒招」了，要終結這個「死循環」，就必須引入「外力」，找一個公認的可信第三方，讓它做爲「信任的起點，遞歸的終點」，構建起公鑰的信任鏈。

這個「第三方」就是咱們常說的 CA（Certificate Authority，證書認證機構）。它就像網絡世界裏的公安局、教育部、公證中心，具備極高的可信度，由它來給各個公鑰簽名，用自身的信譽來保證公鑰沒法僞造，是可信的。CA 對公鑰的簽名認證也是有格式的，不是簡單地把公鑰綁定在持有者身份上就完事了，還要包含序列號、用途、頒發者、有效時間等等，把這些打成一個包再簽名，完整地證實公鑰關聯的各類信息，造成「數字證書」（Certificate）。

知名的 CA 全世界就那麼幾家，好比 DigiCert、VeriSign、Entrust、Let’s Encrypt 等，它們簽發的證書分 DV、OV、EV 三種，區別在於可信程度。

DV 是最低的，只是域名級別的可信，背後是誰不知道。EV 是最高的，通過了法律和審計的嚴格覈查，能夠證實網站擁有者的身份（在瀏覽器地址欄會顯示出公司的名字，例如 Apple、GitHub 的網站）。

不過，CA 怎麼證實本身呢？

這仍是信任鏈的問題。小一點的 CA 可讓大 CA 簽名認證，但鏈條的最後，也就是Root CA，就只能本身證實本身了，這個就叫「自簽名證書」（Self-Signed Certificate）或者「根證書」（Root Certificate）。你必須相信，不然整個證書信任鏈就走不下去了。

有了這個證書體系，操做系統和瀏覽器都內置了各大 CA 的根證書，上網的時候只要服務器發過來它的證書，就能夠驗證證書裏的簽名，順着證書鏈（Certificate Chain）一層層地驗證，直到找到根證書，就可以肯定證書是可信的，從而裏面的公鑰也是可信的。

證書體系的弱點

證書體系（PKI，Public Key Infrastructure）雖然是目前整個網絡世界的安全基礎設施，但絕對的安全是不存在的，它也有弱點，仍是關鍵的「信任」二字。

若是 CA 失誤或者被欺騙，簽發了錯誤的證書，雖然證書是真的，可它表明的網站倒是假的。

還有一種更危險的狀況，CA 被黑客攻陷，或者 CA 有惡意，由於它（即根證書）是信任的源頭，整個信任鏈裏的全部證書也就都不可信了。

這兩種事情並非「聳人聽聞」，都曾經實際出現過。因此，須要再給證書體系打上一些補丁。

針對第一種，開發出了 CRL（證書吊銷列表，Certificate revocation list）和 OCSP（在線證書狀態協議，Online Certificate Status Protocol），及時廢止有問題的證書。

對於第二種，由於涉及的證書太多，就只能操做系統或者瀏覽器從根上「下狠手」了，撤銷對 CA 的信任，列入「黑名單」，這樣它頒發的全部證書就都會被認爲是不安全的。

HTTPS 創建鏈接

當你在瀏覽器地址欄裏鍵入「https」開頭的 URI，再按下回車，會發生什麼呢？

瀏覽器首先要從 URI 裏提取出協議名和域名。由於協議名是「https」，因此瀏覽器就知道了端口號是默認的 443，它再用 DNS 解析域名，獲得目標的 IP 地址，而後就可使用三次握手與網站創建 TCP 鏈接了。

在 HTTP 協議裏，創建鏈接後，瀏覽器會當即發送請求報文。但如今是 HTTPS 協議，它須要再用另一個「握手」過程，在 TCP 上創建安全鏈接，以後纔是收發 HTTP 報文。

這個「握手」過程與 TCP 有些相似，是 HTTPS 和 TLS 協議裏最重要、最核心的部分，懂了它，你就能夠自豪地說本身「掌握了 HTTPS」。

TLS 協議的組成

在講 TLS 握手以前，我先簡單介紹一下 TLS 協議的組成。

TLS 包含幾個子協議，你也能夠理解爲它是由幾個不一樣職責的模塊組成，比較經常使用的有記錄協議、警報協議、握手協議、變動密碼規範協議等。

記錄協議（Record Protocol）規定了 TLS 收發數據的基本單位：記錄（record）。它有點像是 TCP 裏的 segment，全部的其餘子協議都須要經過記錄協議發出。但多個記錄數據能夠在一個 TCP 包裏一次性發出，也並不須要像 TCP 那樣返回 ACK。
警報協議（Alert Protocol）的職責是向對方發出警報信息，有點像是 HTTP 協議裏的狀態碼。好比，protocol_version 就是不支持舊版本，bad_certificate 就是證書有問題，收到警報後另外一方能夠選擇繼續，也能夠當即終止鏈接。
握手協議（Handshake Protocol）是 TLS 裏最複雜的子協議，要比 TCP 的 SYN/ACK 複雜的多，瀏覽器和服務器會在握手過程當中協商 TLS 版本號、隨機數、密碼套件等信息，而後交換證書和密鑰參數，最終雙方協商獲得會話密鑰，用於後續的混合加密系統。
最後一個是變動密碼規範協議（Change Cipher Spec Protocol），它很是簡單，就是一個「通知」，告訴對方，後續的數據都將使用加密保護。那麼反過來，在它以前，數據都是明文的。

下面的這張圖簡要地描述了 TLS 的握手過程，其中每個「框」都是一個記錄，多個記錄組合成一個 TCP 包發送。因此，最多通過兩次消息往返（4 個消息）就能夠完成握手，而後就能夠在安全的通訊環境裏發送 HTTP 報文，實現 HTTPS 協議。

ECDHE 握手過程

剛纔你看到的是握手過程的簡要圖，又畫了一個詳細圖，下面我就用這個圖來仔細剖析 TLS 的握手過程。

在 TCP 創建鏈接以後，瀏覽器會首先發一個「Client Hello」消息，也就是跟服務器「打招呼」。裏面有客戶端的版本號、支持的密碼套件，還有一個隨機數（Client Random），用於後續生成會話密鑰。

Handshake Protocol: Client Hello
Version: TLS 1.2 (0x0303)
Random: 1cbf803321fd2623408dfe…
Cipher Suites (17 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

這個的意思就是：「我這邊有這些這些信息，你看看哪些是能用的，關鍵的隨機數可得留着。」複製代碼

做爲「禮尚往來」，服務器收到「Client Hello」後，會返回一個「Server Hello」消息。把版本號對一下，也給出一個隨機數（Server Random），而後從客戶端的列表裏選一個做爲本次通訊使用的密碼套件，在這裏它選擇了「TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」。

Handshake Protocol: Server Hello
Version: TLS 1.2 (0x0303)
Random: 0e6320f21bae50842e96…
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

這個的意思就是：「版本號對上了，能夠加密，你的密碼套件挺多，我選一個最合適的吧，用橢圓曲線加 RSA、AES、SHA384。我也給你一個隨機數，你也得留着。」複製代碼

而後，服務器爲了證實本身的身份，就把證書也發給了客戶端（Server Certificate）。

接下來是一個關鍵的操做，由於服務器選擇了 ECDHE 算法，因此它會在證書後發送「Server Key Exchange」消息，裏面是橢圓曲線的公鑰（Server Params），用來實現密鑰交換算法，再加上本身的私鑰簽名認證。

Handshake Protocol: Server Key Exchange
EC Diffie-Hellman Server Params
Curve Type: named_curve (0x03)
Named Curve: x25519 (0x001d)
Pubkey: 3b39deaf00217894e...
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature: 37141adac38ea4...

這至關於說：「剛纔我選的密碼套件有點複雜，因此再給你個算法的參數，和剛纔的隨機數同樣有用，別丟了。爲了防止別人冒充，我又蓋了個章。」複製代碼

以後是「Server Hello Done」消息，服務器說：「個人信息就是這些，打招呼完畢。」

這樣第一個消息往返就結束了（兩個 TCP 包），結果是客戶端和服務器經過明文共享了三個信息：Client Random、Server Random 和 Server Params。

客戶端這時也拿到了服務器的證書，那這個證書是否是真實有效的呢？

這就要用到第 25 講裏的知識了，開始走證書鏈逐級驗證，確認證書的真實性，再用證書公鑰驗證簽名，就確認了服務器的身份：「剛纔跟我打招呼的不是騙子，能夠接着往下走。」

而後，客戶端按照密碼套件的要求，也生成一個橢圓曲線的公鑰（Client Params），用「Client Key Exchange」消息發給服務器。

Handshake Protocol: Client Key Exchange
　　EC Diffie-Hellman Client Params
　　　　Pubkey: 8c674d0e08dc27b5eaa…

如今客戶端和服務器手裏都拿到了密鑰交換算法的兩個參數（Client Params、Server Params），就用 ECDHE 算法一陣算，算出了一個新的東西，叫「Pre-Master」，其實也是一個隨機數。

至於具體的計算原理和過程，由於太複雜就不細說了，但算法能夠保證即便黑客截獲了以前的參數，也是絕對算不出這個隨機數的。

如今客戶端和服務器手裏有了三個隨機數：Client Random、Server Random 和 Pre-Master。用這三個做爲原始材料，就能夠生成用於加密會話的主密鑰，叫「Master Secret」。而黑客由於拿不到「Pre-Master」，因此也就得不到主密鑰。

爲何非得這麼麻煩，非要三個隨機數呢？

這就必須說 TLS 的設計者考慮得很是周到了，他們不信任客戶端或服務器僞隨機數的可靠性，爲了保證真正的「徹底隨機」「不可預測」，把三個不可靠的隨機數混合起來，那麼「隨機」的程度就很是高了，足夠讓黑客難以猜想。

你必定很想知道「Master Secret」到底是怎麼算出來的吧，貼一下 RFC 裏的公式：

master_secret = PRF(pre_master_secret, "master secret",ClientHello.random + ServerHello.random)

這裏的「PRF」就是僞隨機數函數，它基於密碼套件裏的最後一個參數，好比此次的 SHA384，經過摘要算法來再一次強化「Master Secret」的隨機性。複製代碼

主密鑰有 48 字節，但它也不是最終用於通訊的會話密鑰，還會再用 PRF 擴展出更多的密鑰，好比客戶端發送用的會話密鑰（client_write_key）、服務器發送用的會話密鑰（server_write_key）等等，避免只用一個密鑰帶來的安全隱患。

有了主密鑰和派生的會話密鑰，握手就快結束了。客戶端發一個「Change Cipher Spec」，而後再發一個「Finished」消息，把以前全部發送的數據作個摘要，再加密一下，讓服務器作個驗證。

意思就是告訴服務器：「後面都改用對稱算法加密通訊了啊，用的就是打招呼時說的 AES，加密對不對還得你測一下。」

服務器也是一樣的操做，發「Change Cipher Spec」和「Finished」消息，雙方都驗證加密解密 OK，握手正式結束，後面就收發被加密的 HTTP 請求和響應了。

RSA 握手過程

整個握手過程可真是夠複雜的，但你可能會問了，好像這個過程和其餘地方看到的不同呢？

剛纔說的實際上是現在主流的 TLS 握手過程，這與傳統的握手有兩點不一樣。

第一個，使用 ECDHE 實現密鑰交換，而不是 RSA，因此會在服務器端發出「Server Key Exchange」消息。

第二個，由於使用了 ECDHE，客戶端能夠不用等到服務器發回「Finished」確認握手完畢，當即就發出 HTTP 報文，省去了一個消息往返的時間浪費。這個叫「TLS False Start」，意思就是「搶跑」，和「TCP Fast Open」有點像，都是不等鏈接徹底創建就提早發應用數據，提升傳輸的效率。

這裏我也畫了個圖。

大致的流程沒有變，只是「Pre-Master」再也不須要用算法生成，而是客戶端直接生成隨機數，而後用服務器的公鑰加密，經過「Client Key Exchange」消息發給服務器。服務器再用私鑰解密，這樣雙方也實現了共享三個隨機數，就能夠生成主密鑰。