HTTP 協(xié)議僅僅制定了互聯(lián)網(wǎng)傳輸?shù)臉?biāo)準(zhǔn)，簡(jiǎn)化了直接使用 TCP 協(xié)議進(jìn)行通信的難度。

[[333773]]

圖片來(lái)自 Pexels

less is more 的概念本身很好，但是過(guò)于簡(jiǎn)單也會(huì)承擔(dān)一些后果：

①通信使用明文，內(nèi)容可能會(huì)竊聽(tīng)

HTTP 本身不具備加密的功能，所以也無(wú)法做到對(duì)通信整體(使用 HTTP 協(xié)議通信的請(qǐng)求和響應(yīng)的內(nèi)容)進(jìn)行加密。即，HTTP 報(bào)文使用明文(指未經(jīng)過(guò)加密的報(bào)文)方式發(fā)送。

②報(bào)文是否是正經(jīng)用戶發(fā)出的報(bào)文無(wú)法得知，可能被篡改

HTTP 協(xié)議無(wú)法證明通信的報(bào)文完整性，因此，在請(qǐng)求或響應(yīng)送出之后直到對(duì)方接收之前的這段時(shí)間內(nèi)，即使請(qǐng)求或響應(yīng)的內(nèi)容遭到篡改，也沒(méi)有辦法獲悉。

換句話說(shuō)，沒(méi)有任何辦法確認(rèn)，發(fā)出的請(qǐng)求/響應(yīng)和接收到的請(qǐng)求/響應(yīng)是前后相同的。

③不驗(yàn)證發(fā)送方身份，可能遭遇偽裝

HTTP 協(xié)議中的請(qǐng)求和響應(yīng)不會(huì)對(duì)通信方進(jìn)行確認(rèn)。在 HTTP 協(xié)議通信時(shí)，由于不存在確認(rèn)通信方的處理步驟，任何人都可以發(fā)起請(qǐng)求。

另外，服務(wù)器只要接收到請(qǐng)求，不管對(duì)方是誰(shuí)都會(huì)返回一個(gè)響應(yīng)(但也僅限于發(fā)送端的 IP 地址和端口號(hào)沒(méi)有被 Web 服務(wù)器設(shè)定限制訪問(wèn)的前提下)。

HTTP 協(xié)議無(wú)法驗(yàn)證通信方身份，任何人都可以偽造虛假服務(wù)器欺騙用戶，實(shí)現(xiàn)釣魚欺詐，用戶無(wú)法察覺(jué)。

因?yàn)橛幸陨蠁?wèn)題且隨著時(shí)代發(fā)展，黑客的技術(shù)能力也越來(lái)越強(qiáng)，非加密的 HTTP 請(qǐng)求很容易引起相關(guān)的網(wǎng)絡(luò)安全問(wèn)題，對(duì)于安全性能的攻防控制需求也越來(lái)越強(qiáng)烈。

什么是安全

既然 HTTP 不安全，那什么樣的通信過(guò)程才是安全的呢?

通常認(rèn)為，如果通信過(guò)程具備了四個(gè)特性，就可以認(rèn)為是安全的：

• 機(jī)密性(Secrecy/Confidentiality)：是指對(duì)數(shù)據(jù)的保密，只能由可信的人訪問(wèn)，對(duì)其他人是不可見(jiàn)的秘密，簡(jiǎn)單來(lái)說(shuō)就是不能讓不相關(guān)的人看到不該看的東西。
• 完整性(Integrity，也叫一致性)：是指數(shù)據(jù)在傳輸過(guò)程中沒(méi)有被竄改，不多也不少，完完整整地保持著原狀。
• 身份認(rèn)證(Authentication)：是指確認(rèn)對(duì)方的真實(shí)身份，也就是證明你真的是你，保證消息只能發(fā)送給可信的人。如果通信時(shí)另一方是假冒的網(wǎng)站，那么數(shù)據(jù)再保密也沒(méi)有用，黑客完全可以使用冒充的身份套出各種信息，加密和沒(méi)加密一樣。
• 不可否認(rèn)(Non-repudiation/Undeniable)，也叫不可抵賴，意思是不能否認(rèn)已經(jīng)發(fā)生過(guò)的行為，不能說(shuō)話不算數(shù)，耍賴皮。

使用前三個(gè)特性，可以解決安全通信的大部分問(wèn)題，但如果缺了不可否認(rèn)，那通信的事務(wù)真實(shí)性就得不到保證，有可能出現(xiàn)老賴。

比如，小明借了小紅一千元，沒(méi)寫借條，第二天矢口否認(rèn)，小紅也確實(shí)拿不出借錢的證據(jù)，只能認(rèn)倒霉。

另一種情況是小明借錢后還了小紅，但沒(méi)寫收條，小紅于是不承認(rèn)小明還錢的事，說(shuō)根本沒(méi)還，要小明再掏出一千元。

所以，只有同時(shí)具備了機(jī)密性、完整性、身份認(rèn)證、不可否認(rèn)這四個(gè)特性，通信雙方的利益才能有保障，才能算得上是真正的安全。

HTTPS 解決什么問(wèn)題

HTTPS 為 HTTP 增加了剛才所說(shuō)的四大安全特性。

HTTPS 其實(shí)是一個(gè)非常簡(jiǎn)單的協(xié)議，RFC 文檔只有短短的 7 頁(yè)，里面規(guī)定了新的協(xié)議名 HTTPS，默認(rèn)端口號(hào) 443。

至于其他的什么請(qǐng)求，應(yīng)答模式、報(bào)文結(jié)構(gòu)、請(qǐng)求方法、URI、頭字段、連接管理等等都完全沿用 HTTP，沒(méi)有任何新的東西。

也就是說(shuō)，除了協(xié)議名 HTTP 和端口號(hào) 80 這兩點(diǎn)不同，HTTPS 協(xié)議在語(yǔ)法、語(yǔ)義上和 HTTP 完全一樣，優(yōu)缺點(diǎn)也照單全收(當(dāng)然要除去明文和不安全 )。

HTTPS 憑什么就能做到機(jī)密性、完整性這些安全特性呢?

秘密就在于 HTTPS 名字里的 S，它把 HTTP 下層的傳輸協(xié)議由 TCP/IP 換成了 SSL/TLS，由 HTTP over TCP/IP 變成了 HTTP over SSL/TLS，讓 HTTP 運(yùn)行在了安全的 SSL/TLS 協(xié)議上，收發(fā)報(bào)文不再使用 Socket API，而是調(diào)用專門的安全接口。

HTTPS 本身并沒(méi)有什么驚世駭俗的本事，全是靠著后面的 SSL/TLS 撐腰。只要學(xué)會(huì)了 SSL/TLS，HTTPS 自然就手到擒來(lái)。

HTTPS 協(xié)議的主要功能基本都依賴于 TLS/SSL 協(xié)議，TLS/SSL 的功能實(shí)現(xiàn)主要依賴于三類基本算法：散列函數(shù) 、對(duì)稱加密和非對(duì)稱加密，利用非對(duì)稱加密實(shí)現(xiàn)身份認(rèn)證和密鑰協(xié)商，對(duì)稱加密算法采用協(xié)商的密鑰對(duì)數(shù)據(jù)加密，基于散列函數(shù)驗(yàn)證信息的完整性。

什么是 SSL/TLS

現(xiàn)在我們就來(lái)看看 SSL/TLS，它到底是個(gè)什么來(lái)歷。

SSL 即安全套接層(Secure Sockets Layer)，在 OSI 模型中處于第 5 層(會(huì)話層)，由網(wǎng)景公司于 1994 年發(fā)明，有 v2 和 v3 兩個(gè)版本，而 v1 因?yàn)橛袊?yán)重的缺陷從未公開(kāi)過(guò)。

SSL 發(fā)展到 v3 時(shí)已經(jīng)證明了它自身是一個(gè)非常好的安全通信協(xié)議，于是互聯(lián)網(wǎng)工程組 IETF 在 1999 年把它改名為 TLS(傳輸層安全，Transport Layer Security)，正式標(biāo)準(zhǔn)化，版本號(hào)從 1.0 重新算起，所以 TLS1.0 實(shí)際上就是 SSLv3.1。

到今天 TLS 已經(jīng)發(fā)展出了三個(gè)版本，分別是 2006 年的 1.1、2008 年的 1.2 和去年(2018)的 1.3，每個(gè)新版本都緊跟密碼學(xué)的發(fā)展和互聯(lián)網(wǎng)的現(xiàn)狀，持續(xù)強(qiáng)化安全和性能，已經(jīng)成為了信息安全領(lǐng)域中的權(quán)威標(biāo)準(zhǔn)。

目前應(yīng)用的最廣泛的 TLS 是 1.2，而之前的協(xié)議(TLS1.1/1.0、SSLv3/v2)都已經(jīng)被認(rèn)為是不安全的，各大瀏覽器即將在 2020 年左右停止支持，所以接下來(lái)的講解都針對(duì)的是 TLS1.2。

TLS 由記錄協(xié)議、握手協(xié)議、警告協(xié)議、變更密碼規(guī)范協(xié)議、擴(kuò)展協(xié)議等幾個(gè)子協(xié)議組成，綜合使用了對(duì)稱加密、非對(duì)稱加密、身份認(rèn)證等許多密碼學(xué)前沿技術(shù)。

瀏覽器和服務(wù)器在使用 TLS 建立連接時(shí)需要選擇一組恰當(dāng)?shù)募用芩惴▉?lái)實(shí)現(xiàn)安全通信，這些算法的組合被稱為密碼套件(cipher suite，也叫加密套件)。

TLS 的密碼套件命名非常規(guī)范，格式很固定。基本的形式是密鑰交換算法+簽名算法+對(duì)稱加密算法+摘要算法。

比如剛才的密碼套件的意思就是：握手時(shí)使用 ECDHE 算法進(jìn)行密鑰交換，用 RSA 簽名和身份認(rèn)證，握手后的通信使用 AES 對(duì)稱算法，密鑰長(zhǎng)度 256 位，分組模式是 GCM，摘要算法 SHA384 用于消息認(rèn)證和產(chǎn)生隨機(jī)數(shù)。

OpenSSL

說(shuō)到 TLS，就不能不談到 OpenSSL，它是一個(gè)著名的開(kāi)源密碼學(xué)程序庫(kù)和工具包，幾乎支持所有公開(kāi)的加密算法和協(xié)議，已經(jīng)成為了事實(shí)上的標(biāo)準(zhǔn)，許多應(yīng)用軟件都會(huì)使用它作為底層庫(kù)來(lái)實(shí)現(xiàn) TLS 功能，包括常用的 Web 服務(wù)器 Apache、Nginx 等。

OpenSSL 是從另一個(gè)開(kāi)源庫(kù) SSLeay 發(fā)展出來(lái)的，曾經(jīng)考慮命名為 OpenTLS，但當(dāng)時(shí)(1998 年)TLS 還未正式確立，而 SSL 早已廣為人知，所以最終使用了 OpenSSL 的名字。

OpenSSL 目前有三個(gè)主要的分支，1.0.2 和 1.1.0 都將在今年(2019)年底不再維護(hù)，最新的長(zhǎng)期支持版本是 1.1.1。

由于 OpenSSL 是開(kāi)源的，所以它還有一些代碼分支，比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL。

這些分支在 OpenSSL 的基礎(chǔ)上刪除了一些老舊代碼，也增加了一些新特性，雖然背后有大金主，但離取代 OpenSSL 還差得很遠(yuǎn)。

[[333774]]

機(jī)密性實(shí)現(xiàn)：加密

實(shí)現(xiàn)機(jī)密性最常用的手段是加密(encrypt)，就是把消息用某種方式轉(zhuǎn)換成誰(shuí)也看不懂的亂碼，只有掌握特殊鑰匙的人才能再轉(zhuǎn)換出原始文本。

這里的鑰匙就叫做密鑰(key)，加密前的消息叫明文(plain text/clear text)，加密后的亂碼叫密文(cipher text)，使用密鑰還原明文的過(guò)程叫解密(decrypt)。

所有的加密算法都是公開(kāi)的，任何人都可以去分析研究，而算法使用的密鑰則必須保密。

這個(gè)關(guān)鍵的密鑰又是什么呢?由于 HTTPS、TLS 都運(yùn)行在計(jì)算機(jī)上，所以密鑰就是一長(zhǎng)串的數(shù)字，但約定俗成的度量單位是位(bit)，而不是字節(jié)(byte)。

比如，說(shuō)密鑰長(zhǎng)度是 128，就是 16 字節(jié)的二進(jìn)制串，密鑰長(zhǎng)度 1024，就是 128 字節(jié)的二進(jìn)制串。

按照密鑰的使用方式，加密可以分為兩大類：

• 對(duì)稱加密
• 非對(duì)稱加密

對(duì)稱加密

很好理解，就是指加密和解密時(shí)使用的密鑰都是同一個(gè)，是對(duì)稱的，只要保證了密鑰的安全，那整個(gè)通信過(guò)程就可以說(shuō)具有了機(jī)密性。

舉個(gè)例子，你想要登錄某網(wǎng)站，只要事先和它約定好使用一個(gè)對(duì)稱密碼，通信過(guò)程中傳輸?shù)娜怯妹荑€加密后的密文，只有你和網(wǎng)站才能解密。

黑客即使能夠竊聽(tīng)，看到的也只是亂碼，因?yàn)闆](méi)有密鑰無(wú)法解出明文，所以就實(shí)現(xiàn)了機(jī)密性。

TLS 里有非常多的對(duì)稱加密算法可供選擇，比如 RC4、DES、3DES、AES、ChaCha20 等，但前三種算法都被認(rèn)為是不安全的，通常都禁止使用，目前常用的有 AES-128、AES-192、AES-256 和 ChaCha20。

DES 的全稱是 Data Encryption Standard(數(shù)據(jù)加密標(biāo)準(zhǔn)) ，它是用于數(shù)字?jǐn)?shù)據(jù)加密的對(duì)稱密鑰算法。

盡管其 56 位的短密鑰長(zhǎng)度使它對(duì)于現(xiàn)代應(yīng)用程序來(lái)說(shuō)太不安全了，但它在加密技術(shù)的發(fā)展中具有很大的影響力。

AES 的意思是高級(jí)加密標(biāo)準(zhǔn)(Advanced Encryption Standard)，AES-128，AES-192 和 AES-256 都是屬于 AES 。

密鑰長(zhǎng)度可以是 128、192 或 256。它是 DES 算法的替代者，安全強(qiáng)度很高，性能也很好，而且有的硬件還會(huì)做特殊優(yōu)化，所以非常流行，是應(yīng)用最廣泛的對(duì)稱加密算法。

ChaCha20 是 Google 設(shè)計(jì)的另一種加密算法，密鑰長(zhǎng)度固定為 256 位，純軟件運(yùn)行性能要超過(guò) AES，曾經(jīng)在移動(dòng)客戶端上比較流行，但 ARMv8 之后也加入了 AES 硬件優(yōu)化，所以現(xiàn)在不再具有明顯的優(yōu)勢(shì)。

分組模式

對(duì)稱算法還有一個(gè)分組模式的概念，它可以讓算法用固定長(zhǎng)度的密鑰加密任意長(zhǎng)度的明文，把小秘密(即密鑰)轉(zhuǎn)化為大秘密(即密文)。

最早有 ECB、CBC、CFB、OFB 等幾種分組模式，但都陸續(xù)被發(fā)現(xiàn)有安全漏洞，所以現(xiàn)在基本都不怎么用了。

最新的分組模式被稱為 AEAD(Authenticated Encryption with Associated Data)，在加密的同時(shí)增加了認(rèn)證的功能，常用的是 GCM、CCM 和 Poly1305。

把上面這些組合起來(lái)，就可以得到 TLS 密碼套件中定義的對(duì)稱加密算法。

比如，AES128-GCM，意思是密鑰長(zhǎng)度為 128 位的 AES 算法，使用的分組模式是 GCM;ChaCha20-Poly1305 的意思是 ChaCha20 算法，使用的分組模式是 Poly1305。

非對(duì)稱加密

對(duì)稱加密看上去好像完美地實(shí)現(xiàn)了機(jī)密性，但其中有一個(gè)很大的問(wèn)題：如何把密鑰安全地傳遞給對(duì)方，術(shù)語(yǔ)叫密鑰交換。

因?yàn)樵趯?duì)稱加密算法中只要持有密鑰就可以解密。如果你和網(wǎng)站約定的密鑰在傳遞途中被黑客竊取，那他就可以在之后隨意解密收發(fā)的數(shù)據(jù)，通信過(guò)程也就沒(méi)有機(jī)密性可言了。

這個(gè)問(wèn)題該怎么解決呢?一般來(lái)說(shuō)除非是雙方私下約定好了密鑰，如果是每次通信都會(huì)發(fā)生變化的密鑰是不能在通信過(guò)程中帶給對(duì)端，這樣你就陷入了要給密鑰加一次密的尷尬境地。所以，就出現(xiàn)了非對(duì)稱加密(也叫公鑰加密算法)。

它有兩個(gè)密鑰，一個(gè)叫公鑰(public key)，一個(gè)叫 私鑰(private key)。兩個(gè)密鑰是不同的，不對(duì)稱，公鑰可以公開(kāi)給任何人使用，而私鑰必須嚴(yán)格保密。

公鑰和私鑰有個(gè)特別的單向 性，雖然都可以用來(lái)加密解密，但公鑰加密后只能用私鑰解密，反過(guò)來(lái)，私鑰加密后也只能用公鑰解密。

非對(duì)稱加密可以解決密鑰交換的問(wèn)題。網(wǎng)站秘密保管私鑰，在網(wǎng)上任意分發(fā)公鑰，你想要登錄網(wǎng)站只要用公鑰加密就行了，密文只能由私鑰持有者才能解密。

而黑客因?yàn)闆](méi)有私鑰，所以就無(wú)法破解密文。

非對(duì)稱加密算法的設(shè)計(jì)要比對(duì)稱算法難得多，在 TLS 里只有很少的幾種，比如 DH、DSA、RSA、ECC 等。

RSA 可能是其中最著名的一個(gè)，幾乎可以說(shuō)是非對(duì)稱加密的代名詞，它的安全性基于整數(shù)分解的數(shù)學(xué)難題，使用兩個(gè)超大素?cái)?shù)的乘積作為生成密鑰的材料，想要從公鑰推算出私鑰是非常困難的。

10 年前 RSA 密鑰的推薦長(zhǎng)度是 1024，但隨著計(jì)算機(jī)運(yùn)算能力的提高，現(xiàn)在 1024 已經(jīng)不安全，普遍認(rèn)為至少要 2048 位。

ECC(Elliptic Curve Cryptography)是非對(duì)稱加密里的后起之秀，它基于橢圓曲線離散對(duì)數(shù)的數(shù)學(xué)難題，使用特定的曲線方程和基點(diǎn)生成公鑰和私鑰，子算法 ECDHE 用于密鑰交換，ECDSA 用于數(shù)字簽名。

ECDHE 即使用橢圓曲線(ECC)的 DH 算法，優(yōu)點(diǎn)是能用較小的素?cái)?shù)(256 位)實(shí)現(xiàn) RSA 相同的安全等級(jí)。

缺點(diǎn)是算法實(shí)現(xiàn)復(fù)雜，用于密鑰交換的歷史不長(zhǎng)，沒(méi)有經(jīng)過(guò)長(zhǎng)時(shí)間的安全攻擊測(cè)試。

目前比較常用的兩個(gè)曲線是 P-256(secp256r1，在 OpenSSL 稱為 prime256v1)和 x25519。

P-256 是 NIST(美國(guó)國(guó)家標(biāo)準(zhǔn)技術(shù)研究所)和 NSA(美國(guó)國(guó)家安全局)推薦使用的曲線，而 x25519 被認(rèn)為是最安全、最快速的曲線。

比起 RSA，ECC 在安全強(qiáng)度和性能上都有明顯的優(yōu)勢(shì)。160 位的 ECC 相當(dāng)于 1024 位的 RSA，而 224 位的 ECC 則相當(dāng)于 2048 位的 RSA。

因?yàn)槊荑€短，所以相應(yīng)的計(jì)算量、消耗的內(nèi)存和帶寬也就少，加密解密的性能就上去了，對(duì)于現(xiàn)在的移動(dòng)互聯(lián)網(wǎng)非常有吸引力。

混合加密

看到這里你是不是認(rèn)為可以拋棄對(duì)稱加密，只用非對(duì)稱加密來(lái)實(shí)現(xiàn)機(jī)密性呢?

很遺憾，雖然非對(duì)稱加密沒(méi)有 密鑰交換 的問(wèn)題，但因?yàn)樗鼈兌际腔趶?fù)雜的數(shù)學(xué)難題，運(yùn)算速度很慢，即使是 ECC 也要比 AES 差上好幾個(gè)數(shù)量級(jí)。

如果僅用非對(duì)稱加密，雖然保證了安全，但通信速度有如烏龜、蝸牛，實(shí)用性就變成了零。

是不是能夠把對(duì)稱加密和非對(duì)稱加密結(jié)合起來(lái)呢，兩者互相取長(zhǎng)補(bǔ)短，即能高效地加密解密，又能安全地密鑰交換。

這就是現(xiàn)在 TLS 里使用的混合加密方式，其實(shí)說(shuō)穿了也很簡(jiǎn)單：在通信剛開(kāi)始的時(shí)候使用非對(duì)稱算法，比如 RSA、ECDHE，首先解決密鑰交換的問(wèn)題。

然后用隨機(jī)數(shù)產(chǎn)生對(duì)稱算法使用的 「會(huì)話密鑰」(session key)，再用公鑰加密。因?yàn)闀?huì)話密鑰很短，通常只有 16 字節(jié)或 32 字節(jié)，所以慢一點(diǎn)也無(wú)所謂。

對(duì)方拿到密文后用私鑰解密，取出會(huì)話密鑰。這樣，雙方就實(shí)現(xiàn)了對(duì)稱密鑰的安全交換，后續(xù)就不再使用非對(duì)稱加密，全都使用對(duì)稱加密。

這樣混合加密就解決了對(duì)稱加密算法的密鑰交換問(wèn)題，而且安全和性能兼顧，完美地實(shí)現(xiàn)了機(jī)密性。

完整性

摘要算法

實(shí)現(xiàn)完整性的手段主要是摘要算法(Digest Algorithm)，也就是常說(shuō)的散列函數(shù)、哈希函數(shù)(Hash Function)。

你可以把摘要算法近似地理解成一種特殊的壓縮算法，它能夠把任意長(zhǎng)度的數(shù)據(jù)壓縮成固定長(zhǎng)度、而且獨(dú)一無(wú)二的摘要字符串，就好像是給這段數(shù)據(jù)生成了一個(gè)數(shù)字指紋。

換一個(gè)角度，也可以把摘要算法理解成特殊的單向加密算法，它只有算法，沒(méi)有密鑰，加密后的數(shù)據(jù)無(wú)法解密，不能從摘要逆推出原文。

摘要算法實(shí)際上是把數(shù)據(jù)從一個(gè) 大空間映射到了小空間，所以就存在沖突(collision，也叫碰撞)的可能性，就如同現(xiàn)實(shí)中的指紋一樣，可能會(huì)有兩份不同的原文對(duì)應(yīng)相同的摘要。

好的摘要算法必須能夠抵抗沖突，讓這種可能性盡量地小。因?yàn)檎惴▽?duì)輸入具有單向性和雪崩效應(yīng)，輸入的微小不同會(huì)導(dǎo)致輸出的劇烈變化，所以也被 TLS 用來(lái)生成偽隨機(jī)數(shù)(PRF，pseudo random function)。

你一定在日常工作中聽(tīng)過(guò)、或者用過(guò) MD5(Message-Digest 5)、SHA-1(Secure Hash Algorithm 1)，它們就是最常用的兩個(gè)摘要算法，能夠生成 16 字節(jié)和 20 字節(jié)長(zhǎng)度的數(shù)字摘要。

但這兩個(gè)算法的安全強(qiáng)度比較低，不夠安全，在 TLS 里已經(jīng)被禁止使用了。目前 TLS 推薦使用的是 SHA-1 的后繼者：SHA-2。

SHA-2 實(shí)際上是一系列摘要算法的統(tǒng)稱，總共有 6 種，常用的有 SHA224、SHA256、SHA384，分別能夠生成 28 字節(jié)、32 字節(jié)、48 字節(jié)的摘要。

摘要算法保證了數(shù)字摘要和原文是完全等價(jià)的。所以，我們只要在原文后附上它的摘要，就能夠保證數(shù)據(jù)的完整性。

比如，你發(fā)了條消息：有內(nèi)鬼，終止交易，然后再加上一個(gè) SHA-2 的摘要。網(wǎng)站收到后也計(jì)算一下消息的摘要，把這兩份指紋做個(gè)對(duì)比，如果一致，就說(shuō)明消息是完整可信的，沒(méi)有被修改。

如果黑客在中間哪怕改動(dòng)了一個(gè)標(biāo)點(diǎn)符號(hào)，摘要也會(huì)完全不同，網(wǎng)站計(jì)算比對(duì)就會(huì)發(fā)現(xiàn)消息被竄改，是不可信的。

不過(guò)摘要算法不具有機(jī)密性，如果明文傳輸，那么黑客可以修改消息后把摘要也一起改了，網(wǎng)站還是鑒別不出完整性。

所以，真正的完整性必須要建立在機(jī)密性之上，在混合加密系統(tǒng)里用會(huì)話密鑰加密消息和摘要，這樣黑客無(wú)法得知明文，也就沒(méi)有辦法動(dòng)手腳了。

這有個(gè)術(shù)語(yǔ)，叫哈希消息認(rèn)證碼(HMAC)。

數(shù)字簽名

加密算法結(jié)合摘要算法，我們的通信過(guò)程可以說(shuō)是比較安全了。但這里還有漏洞，就是通信的兩個(gè)端點(diǎn)(endpoint)。

就像一開(kāi)始所說(shuō)的，黑客可以偽裝成網(wǎng)站來(lái)竊取信息。而反過(guò)來(lái)，他也可以偽裝成你，向網(wǎng)站發(fā)送支付、轉(zhuǎn)賬等消息，網(wǎng)站沒(méi)有辦法確認(rèn)你的身份，錢可能就這么被偷走了。

現(xiàn)實(shí)生活中，解決身份認(rèn)證的手段是簽名和印章，只要在紙上寫下簽名或者蓋個(gè)章，就能夠證明這份文件確實(shí)是由本人而不是其他人發(fā)出的。

回想一下上面的介紹在 TLS 里有什么東西和現(xiàn)實(shí)中的簽名、印章很像，只能由本人持有，而其他任何人都不會(huì)有呢?只要用這個(gè)東西，就能夠在數(shù)字世界里證明你的身份。

沒(méi)錯(cuò)，這個(gè)東西就是非對(duì)稱加密里的私鑰，使用私鑰再加上摘要算法，就能夠?qū)崿F(xiàn)數(shù)字簽名，同時(shí)實(shí)現(xiàn)身份認(rèn)證和不可否認(rèn)。

數(shù)字簽名的原理其實(shí)很簡(jiǎn)單，就是把公鑰私鑰的用法反過(guò)來(lái)，之前是公鑰加密、私鑰解密，現(xiàn)在是私鑰加密、公鑰解密。

但又因?yàn)榉菍?duì)稱加密效率太低，所以私鑰只加密原文的摘要，這樣運(yùn)算量就小的多，而且得到的數(shù)字簽名也很小，方便保管和傳輸。

簽名和公鑰一樣完全公開(kāi)，任何人都可以獲取。但這個(gè)簽名只有用私鑰對(duì)應(yīng)的公鑰才能解開(kāi)，拿到摘要后，再比對(duì)原文驗(yàn)證完整性，就可以像簽署文件一樣證明消息確實(shí)是你發(fā)的。

剛才的這兩個(gè)行為也有專用術(shù)語(yǔ)，叫做簽名和驗(yàn)簽。

只要你和網(wǎng)站互相交換公鑰，就可以用簽名和驗(yàn)簽來(lái)確認(rèn)消息的真實(shí)性，因?yàn)樗借€保密，黑客不能偽造簽名，就能夠保證通信雙方的身份。

比如，你用自己的私鑰簽名一個(gè)消息馬冬梅你別跑。網(wǎng)站收到后用你的公鑰驗(yàn)簽，確認(rèn)身份沒(méi)問(wèn)題，于是也用它的私鑰簽名消息十年翻身同學(xué)會(huì)，拆散一對(duì)是一對(duì)。

你收到后再用它的公鑰驗(yàn)一下，也沒(méi)問(wèn)題，這樣你和網(wǎng)站就都知道對(duì)方不是假冒的，后面就可以用混合加密進(jìn)行安全通信了。

數(shù)字證書和 CA：身份認(rèn)證

到現(xiàn)在，綜合使用對(duì)稱加密、非對(duì)稱加密和摘要算法，我們已經(jīng)實(shí)現(xiàn)了安全的四大特性，是不是已經(jīng)完美了呢?

不是的，這里還有一個(gè)公鑰的信任問(wèn)題。因?yàn)檎l(shuí)都可以發(fā)布公鑰，我們還缺少防止黑客偽造公鑰的手段，也就是說(shuō)，怎么來(lái)判斷這個(gè)公鑰就是你的公鑰呢?

我們可以用類似密鑰交換的方法來(lái)解決公鑰認(rèn)證問(wèn)題，用別的私鑰來(lái)給公鑰簽名，顯然，這又會(huì)陷入俄羅斯套娃。

[[333778]]

但這次實(shí)在是沒(méi)招了，要終結(jié)這個(gè)死循環(huán)，就必須引入外力，找一個(gè)公認(rèn)的可信第三方，讓它作為信任的起點(diǎn)，遞歸的終點(diǎn)，構(gòu)建起公鑰的信任鏈。

這個(gè)第三方就是我們常說(shuō)的CA(Certificate Authority，證書認(rèn)證機(jī)構(gòu))。它就像網(wǎng)絡(luò)世界里的公安局、教育部、公證中心，具有極高的可信度，由它來(lái)給各個(gè)公鑰簽名，用自身的信譽(yù)來(lái)保證公鑰無(wú)法偽造，是可信的。

CA 對(duì)公鑰的簽名認(rèn)證也是有格式的，不是簡(jiǎn)單地把公鑰綁定在持有者身份上就完事了，還要包含序列號(hào)、用途、頒發(fā)者、有效時(shí)間等等，把這些打成一個(gè)包再簽名，完整地證明公鑰關(guān)聯(lián)的各種信息，形成數(shù)字證書(Certificate)。

知名的 CA 全世界就那么幾家，比如 DigiCert、VeriSign、Entrust、Let’s Encrypt 等，它們簽發(fā)的證書分 DV、OV、EV 三種，區(qū)別在于可信程度。

DV 是最低的，只是域名級(jí)別的可信，背后是誰(shuí)不知道。EV 是最高的，經(jīng)過(guò)了法律和審計(jì)的嚴(yán)格核查，可以證明網(wǎng)站擁有者的身份(在瀏覽器地址欄會(huì)顯示出公司的名字，例如 Apple、GitHub 的網(wǎng)站)。

不過(guò)，CA 怎么證明自己呢?這還是信任鏈的問(wèn)題。

小一點(diǎn)的 CA 可以讓大 CA 簽名認(rèn)證，但鏈條的最后，也就是「Root CA」，就只能自己證明自己了，這個(gè)就叫 「自簽名證書」(Self-Signed Certificate)或者 「根證書」(Root Certificate)。

你必須相信，否則整個(gè)證書信任鏈就走不下去了。

有了這個(gè)證書體系，操作系統(tǒng)和瀏覽器都內(nèi)置了各大 CA 的根證書，上網(wǎng)的時(shí)候只要服務(wù)器發(fā)過(guò)來(lái)它的證書，就可以驗(yàn)證證書里的簽名。

順著證書鏈(Certificate Chain)一層層地驗(yàn)證，直到找到根證書，就能夠確定證書是可信的，從而里面的公鑰也是可信的。

證書體系的弱點(diǎn)

證書體系(PKI，Public Key Infrastructure)雖然是目前整個(gè)網(wǎng)絡(luò)世界的安全基礎(chǔ)設(shè)施，但絕對(duì)的安全是不存在的，它也有弱點(diǎn)，還是關(guān)鍵的信任二字。

如果 CA 失誤或者被欺騙，簽發(fā)了錯(cuò)誤的證書，雖然證書是真的，可它代表的網(wǎng)站卻是假的。

還有一種更危險(xiǎn)的情況，CA 被黑客攻陷，或者 CA 有惡意，因?yàn)樗?即根證書)是信任的源頭，整個(gè)信任鏈里的所有證書也就都不可信了。

這兩種事情并不是聳人聽(tīng)聞，都曾經(jīng)實(shí)際出現(xiàn)過(guò)。所以需要再給證書體系打上一些補(bǔ)丁。

針對(duì)第一種，開(kāi)發(fā)出了 CRL(證書吊銷列表，Certificate revocation list)和 OCSP(在線證書狀態(tài)協(xié)議，Online Certificate Status Protocol)，及時(shí)廢止有問(wèn)題的證書。

對(duì)于第二種因?yàn)樯婕暗淖C書太多，就只能操作系統(tǒng)或者瀏覽器從根上下狠手了，撤銷對(duì) CA 的信任，列入黑名單，這樣它頒發(fā)的所有證書就都會(huì)被認(rèn)為是不安全的。

我們來(lái)看一下 Github 的數(shù)字證書長(zhǎng)什么樣子：

證書上的信息可以得知：類型是 EV，擁有最高權(quán)威認(rèn)證;過(guò)期時(shí)間;證書所屬組織;證書簽發(fā)機(jī)構(gòu)。

TLS 協(xié)議的組成

當(dāng)你在瀏覽器地址欄里鍵入 HTTPS 開(kāi)頭的 URI，再按下回車，會(huì)發(fā)生什么呢?瀏覽器首先要從 URI 里提取出協(xié)議名和域名。

因?yàn)閰f(xié)議名是 HTTPS，所以瀏覽器就知道了端口號(hào)是默認(rèn)的 443，它再用 DNS 解析域名，得到目標(biāo)的 IP 地址，然后就可以使用三次握手與網(wǎng)站建立 TCP 連接了。

在 HTTP 協(xié)議里，建立連接后，瀏覽器會(huì)立即發(fā)送請(qǐng)求報(bào)文。但現(xiàn)在是 HTTPS 協(xié)議，它需要再用另外一個(gè)握手過(guò)程，在 TCP 上建立安全連接，之后才是收發(fā) HTTP 報(bào)文。

這個(gè)握手過(guò)程與 TCP 有些類似，是 HTTPS 和 TLS 協(xié)議里最重要、最核心的部分。

在講 TLS 握手之前，先簡(jiǎn)單介紹一下 TLS 協(xié)議的組成。

TLS 包含幾個(gè)子協(xié)議，你也可以理解為它是由幾個(gè)不同職責(zé)的模塊組成，比較常用的有：記錄協(xié)議、警報(bào)協(xié)議、握手協(xié)議、變更密碼規(guī)范協(xié)議等。

記錄協(xié)議(Record Protocol)規(guī)定了 TLS 收發(fā)數(shù)據(jù)的基本單位：記錄(record)。

它有點(diǎn)像是 TCP 里的 segment，所有的其他子協(xié)議都需要通過(guò)記錄協(xié)議發(fā)出。

但多個(gè)記錄數(shù)據(jù)可以在一個(gè) TCP 包里一次性發(fā)出，也并不需要像 TCP 那樣返回 ACK。

警報(bào)協(xié)議(Alert Protocol)的職責(zé)是向?qū)Ψ桨l(fā)出警報(bào)信息，有點(diǎn)像是 HTTP 協(xié)議里的狀態(tài)碼。

比如，protocol_version 就是不支持舊版本，bad_certificate 就是證書有問(wèn)題，收到警報(bào)后另一方可以選擇繼續(xù)，也可以立即終止連接。

握手協(xié)議(Handshake Protocol)是 TLS 里最復(fù)雜的子協(xié)議，要比 TCP 的 SYN/ACK 復(fù)雜的多，瀏覽器和服務(wù)器會(huì)在握手過(guò)程中協(xié)商 TLS 版本號(hào)、隨機(jī)數(shù)、密碼套件等信息，然后交換證書和密鑰參數(shù)，最終雙方協(xié)商得到會(huì)話密鑰，用于后續(xù)的混合加密系統(tǒng)。

變更密碼規(guī)范協(xié)議(Change Cipher Spec Protocol)，它非常簡(jiǎn)單，就是一個(gè)通知，告訴對(duì)方，后續(xù)的數(shù)據(jù)都將使用加密保護(hù)。那么反過(guò)來(lái)，在它之前，數(shù)據(jù)都是明文的。

下面的這張圖簡(jiǎn)要地描述了 TLS 的握手過(guò)程，其中每一個(gè)框都是一個(gè)記錄，多個(gè)記錄組合成一個(gè) TCP 包發(fā)送。

所以，最多經(jīng)過(guò)兩次消息往返(4 個(gè)消息)就可以完成握手，然后就可以在安全的通信環(huán)境里發(fā)送 HTTP 報(bào)文，實(shí)現(xiàn) HTTPS 協(xié)議。

在 TCP 完成三次握手建立連接之后， HTTPS 開(kāi)始加密認(rèn)證握手流程。TLS 的握手過(guò)程如下：

以上過(guò)程我們可以使用 wireShark 抓包工具看到。

在 TCP 建立連接之后，瀏覽器會(huì)首先發(fā)一個(gè) client_hello 消息，里面有客戶端的版本號(hào)、支持的密碼套件，還有一個(gè)隨機(jī)數(shù)(Client Random)，用于后續(xù)生成會(huì)話密鑰：

可以看到客戶端發(fā)送給服務(wù)端他所支持的密碼套件有 16 套之多，另外客戶端使用的 TLS 版本是 1.2。

服務(wù)器收到 Client Hello 后，會(huì)返回一個(gè) Server Hello 消息。把版本號(hào)對(duì)一下，也給出一個(gè)隨機(jī)數(shù)(Server Random)。

然后從客戶端的列表里選一個(gè)作為本次通信使用的密碼套件。在這里它選擇了 Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)。

然后服務(wù)器為了證明自己的身份，就把證書也發(fā)給了客戶端(Server Certificate)。

接下來(lái)是一個(gè)關(guān)鍵的操作，因?yàn)榉?wù)器選擇了 ECDHE 算法，所以它會(huì)在證書后發(fā)送 Server Key Exchange 消息，里面是橢圓曲線的公鑰(Server Params)，用來(lái)實(shí)現(xiàn)密鑰交換算法，再加上自己的私鑰簽名認(rèn)證。

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... 

這相當(dāng)于說(shuō)：剛才我選的密碼套件有點(diǎn)復(fù)雜，所以再給你個(gè)算法的參數(shù)，和剛才的隨機(jī)數(shù)一樣有用別丟了。為了防止別人冒充，我又蓋了個(gè)章。

之后是 Server Hello Done 消息，服務(wù)器說(shuō)：我的信息就是這些，打招呼完畢。

這樣第一個(gè)消息往返就結(jié)束了(兩個(gè) TCP 包)，結(jié)果是客戶端和服務(wù)器通過(guò)明文共享了三個(gè)信息：Client Random、Server Random 和 Server Params。

客戶端這時(shí)也拿到了服務(wù)器的證書，那這個(gè)證書是不是真實(shí)有效的呢?下面客戶端就開(kāi)始鑒定證書的真?zhèn)巍Ｐｒ?yàn)過(guò)程如下：

①首先讀取證書所有者有效期等信息進(jìn)行校驗(yàn)，查找內(nèi)置的收信人證書發(fā)布機(jī)構(gòu) CA 與證書 CA 相對(duì)比，校驗(yàn)是否是合法機(jī)構(gòu)頒發(fā)。

這一步會(huì)做如下操作：

• 證書鏈的可信性 (trusted certificate path)校驗(yàn)，發(fā)行服務(wù)器證書的 CA 是否可靠。
• 證書是否吊銷 (revocation)，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行為會(huì)不同。
• 有效期 (expiry date)，證書是否在有效時(shí)間范圍。
• 域名 (domain)，核查證書域名是否與當(dāng)前的訪問(wèn)域名匹配，匹配規(guī)則后續(xù)分析。

②第一步檢驗(yàn)通過(guò)之后產(chǎn)生隨機(jī)數(shù) Pre-master，并用證書公鑰加密，發(fā)送給服務(wù)器，作為以后對(duì)稱加密的密鑰。

客戶端向服務(wù)器發(fā)送 Client Key Exchange。最后客戶端與服務(wù)器互發(fā) Change Cipher Spec，Encrypted Handshake Message：

接下來(lái)服務(wù)器接收到客戶端發(fā)送的 Pre-master，解密出被加密的 Pre-master，然后通知客戶端：握手階段結(jié)束，隨后所有的通信將使用對(duì)稱加密的方式進(jìn)行。

雙向認(rèn)證

上面已經(jīng)講完了 TLS 握手，從上面的流程不難看出只是客戶端認(rèn)證了服務(wù)器的身份，而服務(wù)器是沒(méi)有認(rèn)證客戶端身份的，我們簡(jiǎn)稱單向認(rèn)證。

通常單向認(rèn)證通過(guò)后已經(jīng)建立了安全通信，用賬號(hào)、密碼等簡(jiǎn)單的手段就能夠確認(rèn)用戶的真實(shí)身份。

但為了防止賬號(hào)、密碼被盜，有的時(shí)候(比如網(wǎng)上銀行)還會(huì)使用 U 盾給用戶頒發(fā)客戶端證書，實(shí)現(xiàn)雙向認(rèn)證，這樣會(huì)更加安全。

雙向認(rèn)證的流程也沒(méi)有太多變化，只是在 Server Hello Done 之后，Client Key Exchange 之前，客戶端要發(fā)送 Client Certificate 消息，服務(wù)器收到后也把證書鏈走一遍，驗(yàn)證客戶端的身份。

不過(guò) TLS1.2 已經(jīng)是 10 年前(2008 年)的老協(xié)議了，雖然歷經(jīng)考驗(yàn)但畢竟 歲月不饒人，在安全、性能等方面已經(jīng)跟不上如今的互聯(lián)網(wǎng)。

經(jīng)過(guò)四年近 30 個(gè)草案的反復(fù)打磨，TLS1.3 在 2018 年推出，再次確立了信息安全領(lǐng)域的新標(biāo)準(zhǔn)。

最大化兼容性

由于 1.1、1.2 等協(xié)議已經(jīng)出現(xiàn)了很多年，很多應(yīng)用軟件、中間代理(官方稱為MiddleBox)只認(rèn)老的記錄協(xié)議格式，更新改造很困難，甚至是不可行(設(shè)備僵化)。

在早期的試驗(yàn)中發(fā)現(xiàn)，一旦變更了記錄頭字段里的版本號(hào)，也就是由 0x303(TLS1.2)改為 0x304(TLS1.3)的話，大量的代理服務(wù)器、網(wǎng)關(guān)都無(wú)法正確處理，最終導(dǎo)致 TLS 握手失敗。

為了保證這些被廣泛部署的老設(shè)備能夠繼續(xù)使用，避免新協(xié)議帶來(lái)的沖擊，TLS1.3 不得不做出妥協(xié)，保持現(xiàn)有的記錄格式不變，通過(guò)偽裝來(lái)實(shí)現(xiàn)兼容，使得 TLS1.3 看上去像是 TLS1.2。

那么，該怎么區(qū)分 1.2 和 1.3 呢?

這要用到一個(gè)新的擴(kuò)展協(xié)議(Extension Protocol)，它有點(diǎn) 補(bǔ)充條款 的意思，通過(guò)在記錄末尾添加一系列的擴(kuò)展字段來(lái)增加新的功能，老版本的 TLS 不認(rèn)識(shí)它可以直接忽略，這就實(shí)現(xiàn)了后向兼容。

在記錄頭的 Version 字段被兼容性固定的情況下，只要是 TLS1.3 協(xié)議，握手的 Hello 消息后面就必須有 supported_versions 擴(kuò)展，它標(biāo)記了 TLS 的版本號(hào)，使用它就能區(qū)分新舊協(xié)議。

你可以看一下 Client Hello 消息后面的擴(kuò)展，只是因?yàn)榉?wù)器不支持 1.3，所以就后向兼容降級(jí)成了 1.2。

TLS1.3 利用擴(kuò)展實(shí)現(xiàn)了許多重要的功能，比如supported_groups、key_share、signature_algorithms、server_name等，這些等后面用到的時(shí)候再說(shuō)。

強(qiáng)化安全

TLS1.2 在十來(lái)年的應(yīng)用中獲得了許多寶貴的經(jīng)驗(yàn)，陸續(xù)發(fā)現(xiàn)了很多的漏洞和加密算法的弱點(diǎn)，所以 TLS1.3 就在協(xié)議里修補(bǔ)了這些不安全因素。

比如：

• 偽隨機(jī)數(shù)函數(shù)由 PRF 升級(jí)為 HKDF(HMAC-based Extract-and-Expand Key Derivation Function)。
• 明確禁止在記錄協(xié)議里使用壓縮。
• 廢除了 RC4、DES 對(duì)稱加密算法。
• 廢除了 ECB、CBC 等傳統(tǒng)分組模式。
• 廢除了 MD5、SHA1、SHA-224 摘要算法。
• 廢除了 RSA、DH 密鑰交換算法和許多命名曲線。

經(jīng)過(guò)這一番減肥瘦身之后，TLS1.3 里只保留了 AES、ChaCha20 對(duì)稱加密算法，分組模式只能用 AEAD 的 GCM、CCM 和 Poly1305。

摘要算法只能用 SHA256、SHA384，密鑰交換算法只有 ECDHE 和 DHE，橢圓曲線也被砍到只剩 P-256 和 x25519 等 5 種。

算法精簡(jiǎn)后帶來(lái)了一個(gè)意料之中的好處：原來(lái)眾多的算法、參數(shù)組合導(dǎo)致密碼套件非常復(fù)雜，難以選擇，而現(xiàn)在的 TLS1.3 里只有 5 個(gè)套件，無(wú)論是客戶端還是服務(wù)器都不會(huì)再犯選擇困難癥了。

這里還要特別說(shuō)一下廢除 RSA 和 DH 密鑰交換算法的原因。在 RSA 密鑰交換中，共享密鑰由客戶端生成，然后客戶端利用服務(wù)器的公鑰(從證書中提取)將共享密鑰加密并將其發(fā)送到服務(wù)器。

DH 算法由 Diffie 和 Hellman 于 1976 年發(fā)明，即所謂的 Diffie-Hellman 密鑰交換。

在 Diffie-Hellman 中，客戶端和服務(wù)器都從創(chuàng)建 DH 參數(shù)對(duì)開(kāi)始。然后，他們將其 DH 參數(shù)的公共部分發(fā)送給另一方。

當(dāng)雙方都收到對(duì)方方的公共參數(shù)時(shí)，它們將它與自己的私鑰組合在一起，最終計(jì)算出同一個(gè)值：前主密鑰。然后，服務(wù)器使用數(shù)字簽名來(lái)確保交換未被篡改。

如果客戶端和服務(wù)器都為每次密鑰交換選擇一個(gè)新的 DH 參數(shù)，則該密鑰交換稱為 “Ephemeral”(DHE)。

DH 是一個(gè)功能強(qiáng)大的工具，但并非所有 DH 參數(shù)都可以 “安全” 使用。DH 的安全性取決于稱為數(shù)學(xué)中離散對(duì)數(shù)問(wèn)題的難度。

如果可以解決一組參數(shù)的離散對(duì)數(shù)問(wèn)題，就可以提取私鑰并破壞協(xié)議的安全性。

一般來(lái)說(shuō)，使用的數(shù)字越大，解決離散對(duì)數(shù)問(wèn)題就越困難。因此，如果您選擇較小的 DH 參數(shù)，就有可能遭受攻擊。

上兩種模式都會(huì)使客戶端和服務(wù)器具有共享密鑰，但 RSA 模式有一個(gè)嚴(yán)重的缺點(diǎn)，這是因?yàn)樗痪哂星跋虬踩?Forward Secrecy)。

假設(shè)有這么一個(gè)很有耐心的黑客，一直在長(zhǎng)期收集混合加密系統(tǒng)收發(fā)的所有報(bào)文。

如果加密系統(tǒng)使用服務(wù)器證書里的 RSA 做密鑰交換，一旦私鑰泄露或被破解(使用社會(huì)工程學(xué)或者巨型計(jì)算機(jī))，那么黑客就能夠使用私鑰解密出之前所有報(bào)文的 Pre-Master，再算出會(huì)話密鑰，破解所有密文。

而 ECDHE 算法在每次握手時(shí)都會(huì)生成一對(duì)臨時(shí)的公鑰和私鑰，每次通信的密鑰對(duì)都是不同的，也就是一次一密，即使黑客花大力氣破解了這一次的會(huì)話密鑰，也只是這次通信被攻擊，之前的歷史消息不會(huì)受到影響，仍然是安全的。

所以現(xiàn)在主流的服務(wù)器和瀏覽器在握手階段都已經(jīng)不再使用 RSA，改用 ECDHE，而 TLS1.3 在協(xié)議里明確廢除 RSA 和 DH 則在標(biāo)準(zhǔn)層面保證了前向安全。

RSA 密鑰交換在一段時(shí)間內(nèi)一直存在問(wèn)題，其原因不僅僅是因?yàn)樗С智跋虮Ｃ堋６且驗(yàn)橄胍_的實(shí)現(xiàn) RSA 密鑰交換也是不容易的。

1998 年，Daniel Bleichenbacher 在 SSL 中使用 RSA 加密時(shí)發(fā)現(xiàn)了一個(gè)漏洞并創(chuàng)建了所謂的 “百萬(wàn)消息攻擊”。

它允許攻擊者通過(guò)發(fā)送數(shù)百萬(wàn)條消息或一些特定的消息給服務(wù)器，根據(jù)服務(wù)器響應(yīng)的不同錯(cuò)誤碼計(jì)算加密密鑰，進(jìn)而解密消息。

多年來(lái)，這種攻擊得到了改進(jìn)，在某些情況下只需要數(shù)千次就可破解，這使得在筆記本電腦上都可以破解。

最近發(fā)現(xiàn)，許多大型網(wǎng)站(包括 facebook.com)在 2017 年也受到 Bleichenbacher 變種漏洞的影響，即 ROBOT 攻擊。

為了降低非前向加密連接和 Bleichenbacher 漏洞所帶來(lái)的風(fēng)險(xiǎn)，RSA 加密已從 TLS 1.3 中刪除，將 Diffie-Hellman Ephemeral 作為唯一的密鑰交換機(jī)制。

提升性能

HTTPS 建立連接時(shí)除了要做 TCP 握手，還要做 TLS 握手，在 1.2 中會(huì)多花兩個(gè)消息往返(2-RTT)，可能導(dǎo)致幾十毫秒甚至上百毫秒的延遲，在移動(dòng)網(wǎng)絡(luò)中延遲還會(huì)更嚴(yán)重。

現(xiàn)在因?yàn)槊艽a套件大幅度簡(jiǎn)化，也就沒(méi)有必要再像以前那樣走復(fù)雜的協(xié)商流程了。

TLS1.3 壓縮了以前的 Hello 協(xié)商過(guò)程，刪除了 Key Exchange 消息，把握手時(shí)間減少到了 1-RTT，效率提高了一倍。

那么它是怎么做的呢?其實(shí)具體的做法還是利用了擴(kuò)展。

客戶端在 Client Hello 消息里直接用 supported_groups 帶上支持的曲線，比如 P-256、x25519，用 key_share 帶上曲線對(duì)應(yīng)的客戶端公鑰參數(shù)，用 signature_algorithms 帶上簽名算法。

服務(wù)器收到后在這些擴(kuò)展里選定一個(gè)曲線和參數(shù)，再用 key_share 擴(kuò)展返回服務(wù)器這邊的公鑰參數(shù)，就實(shí)現(xiàn)了雙方的密鑰交換，后面的流程就和 1.2 基本一樣了。

除了標(biāo)準(zhǔn)的 1-RTT 握手，TLS1.3 還引入了 0-RTT 握手，用 pre_shared_key 和 early_data 擴(kuò)展，在 TCP 連接后立即就建立安全連接發(fā)送加密消息，不過(guò)這需要有一些前提條件，限于篇幅這里暫且不講解。

HTTPS 使用成本

HTTPS 截止到目前為止國(guó)內(nèi)的大中型企業(yè)基本都支持并已經(jīng)使用。

一般來(lái)講，使用 HTTPS 前大家可能會(huì)非常關(guān)注如下問(wèn)題：

• 證書費(fèi)用以及更新維護(hù)：費(fèi)用主要是證書的申請(qǐng)，而且現(xiàn)在也有了免費(fèi)的證書機(jī)構(gòu)，比如著名的 mozilla 發(fā)起的免費(fèi)證書項(xiàng)目：let’s encrypt 就支持免費(fèi)證書安裝和自動(dòng)更新。
• HTTPS 降低用戶訪問(wèn)速度：HTTPS 對(duì)速度會(huì)有一定程度的降低，但是只要經(jīng)過(guò)合理優(yōu)化和部署，HTTPS 對(duì)速度的影響完全可以接受。

在很多場(chǎng)景下，HTTPS 速度完全不遜于 HTTP，如果使用 SPDY，HTTPS 的速度甚至還要比 HTTP 快。

作者：rickiyang

編輯：陶家龍

出處：轉(zhuǎn)載自微信公眾號(hào) rickiyang