HTTP 協(xié)議僅僅制定了互聯(lián)網(wǎng)傳輸?shù)臉藴?，簡化了直接使?TCP 協(xié)議進行通信的難度。

[[333773]]

圖片來自 Pexels

less is more 的概念本身很好，但是過于簡單也會承擔一些后果：

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

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

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

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

換句話說，沒有任何辦法確認，發(fā)出的請求/響應和接收到的請求/響應是前后相同的。

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

HTTP 協(xié)議中的請求和響應不會對通信方進行確認。在 HTTP 協(xié)議通信時，由于不存在確認通信方的處理步驟，任何人都可以發(fā)起請求。

另外，服務(wù)器只要接收到請求，不管對方是誰都會返回一個響應(但也僅限于發(fā)送端的 IP 地址和端口號沒有被 Web 服務(wù)器設(shè)定限制訪問的前提下)。

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

因為有以上問題且隨著時代發(fā)展，黑客的技術(shù)能力也越來越強，非加密的 HTTP 請求很容易引起相關(guān)的網(wǎng)絡(luò)安全問題，對于安全性能的攻防控制需求也越來越強烈。

什么是安全

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

通常認為，如果通信過程具備了四個特性，就可以認為是安全的：

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

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

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

另一種情況是小明借錢后還了小紅，但沒寫收條，小紅于是不承認小明還錢的事，說根本沒還，要小明再掏出一千元。

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

HTTPS 解決什么問題

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

HTTPS 其實是一個非常簡單的協(xié)議，RFC 文檔只有短短的 7 頁，里面規(guī)定了新的協(xié)議名 HTTPS，默認端口號 443。

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

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

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

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

HTTPS 本身并沒有什么驚世駭俗的本事，全是靠著后面的 SSL/TLS 撐腰。只要學會了 SSL/TLS，HTTPS 自然就手到擒來。

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

什么是 SSL/TLS

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

SSL 即安全套接層(Secure Sockets Layer)，在 OSI 模型中處于第 5 層(會話層)，由網(wǎng)景公司于 1994 年發(fā)明，有 v2 和 v3 兩個版本，而 v1 因為有嚴重的缺陷從未公開過。

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

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

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

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

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

TLS 的密碼套件命名非常規(guī)范，格式很固定?；镜男问绞敲荑€交換算法+簽名算法+對稱加密算法+摘要算法。

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

OpenSSL

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

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

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

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

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

[[333774]]

機密性實現(xiàn)：加密

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

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

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

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

比如，說密鑰長度是 128，就是 16 字節(jié)的二進制串，密鑰長度 1024，就是 128 字節(jié)的二進制串。

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

• 對稱加密
• 非對稱加密

對稱加密

很好理解，就是指加密和解密時使用的密鑰都是同一個，是對稱的，只要保證了密鑰的安全，那整個通信過程就可以說具有了機密性。

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

黑客即使能夠竊聽，看到的也只是亂碼，因為沒有密鑰無法解出明文，所以就實現(xiàn)了機密性。

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

DES 的全稱是 Data Encryption Standard(數(shù)據(jù)加密標準) ，它是用于數(shù)字數(shù)據(jù)加密的對稱密鑰算法。

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

AES 的意思是高級加密標準(Advanced Encryption Standard)，AES-128，AES-192 和 AES-256 都是屬于 AES 。

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

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

分組模式

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

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

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

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

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

非對稱加密

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

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

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

它有兩個密鑰，一個叫公鑰(public key)，一個叫 私鑰(private key)。兩個密鑰是不同的，不對稱，公鑰可以公開給任何人使用，而私鑰必須嚴格保密。

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

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

而黑客因為沒有私鑰，所以就無法破解密文。

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

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

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

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

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

缺點是算法實現(xiàn)復雜，用于密鑰交換的歷史不長，沒有經(jīng)過長時間的安全攻擊測試。

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

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

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

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

混合加密

看到這里你是不是認為可以拋棄對稱加密，只用非對稱加密來實現(xiàn)機密性呢?

很遺憾，雖然非對稱加密沒有 密鑰交換 的問題，但因為它們都是基于復雜的數(shù)學難題，運算速度很慢，即使是 ECC 也要比 AES 差上好幾個數(shù)量級。

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

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

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

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

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

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

完整性

摘要算法

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

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

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

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

好的摘要算法必須能夠抵抗沖突，讓這種可能性盡量地小。因為摘要算法對輸入具有單向性和雪崩效應，輸入的微小不同會導致輸出的劇烈變化，所以也被 TLS 用來生成偽隨機數(shù)(PRF，pseudo random function)。

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

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

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

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

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

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

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

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

這有個術(shù)語，叫哈希消息認證碼(HMAC)。

數(shù)字簽名

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

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

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

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

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

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

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

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

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

只要你和網(wǎng)站互相交換公鑰，就可以用簽名和驗簽來確認消息的真實性，因為私鑰保密，黑客不能偽造簽名，就能夠保證通信雙方的身份。

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

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

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

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

不是的，這里還有一個公鑰的信任問題。因為誰都可以發(fā)布公鑰，我們還缺少防止黑客偽造公鑰的手段，也就是說，怎么來判斷這個公鑰就是你的公鑰呢?

我們可以用類似密鑰交換的方法來解決公鑰認證問題，用別的私鑰來給公鑰簽名，顯然，這又會陷入俄羅斯套娃。

[[333778]]

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

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

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

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

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

不過，CA 怎么證明自己呢?這還是信任鏈的問題。

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

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

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

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

證書體系的弱點

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

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

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

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

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

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

我們來看一下 Github 的數(shù)字證書長什么樣子：

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

TLS 協(xié)議的組成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在 TCP 完成三次握手建立連接之后， HTTPS 開始加密認證握手流程。TLS 的握手過程如下：

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

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

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

服務(wù)器收到 Client Hello 后，會返回一個 Server Hello 消息。把版本號對一下，也給出一個隨機數(shù)(Server Random)。

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

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

接下來是一個關(guān)鍵的操作，因為服務(wù)器選擇了 ECDHE 算法，所以它會在證書后發(fā)送 Server Key Exchange 消息，里面是橢圓曲線的公鑰(Server Params)，用來實現(xià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... 

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

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

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

客戶端這時也拿到了服務(wù)器的證書，那這個證書是不是真實有效的呢?下面客戶端就開始鑒定證書的真?zhèn)?。校驗過程如下：

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

這一步會做如下操作：

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

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

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

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

雙向認證

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

通常單向認證通過后已經(jīng)建立了安全通信，用賬號、密碼等簡單的手段就能夠確認用戶的真實身份。

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

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

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

經(jīng)過四年近 30 個草案的反復打磨，TLS1.3 在 2018 年推出，再次確立了信息安全領(lǐng)域的新標準。

最大化兼容性

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

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

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

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

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

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

你可以看一下 Client Hello 消息后面的擴展，只是因為服務(wù)器不支持 1.3，所以就后向兼容降級成了 1.2。

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

強化安全

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

比如：

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

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

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

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

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

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

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

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

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

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

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

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

上兩種模式都會使客戶端和服務(wù)器具有共享密鑰，但 RSA 模式有一個嚴重的缺點，這是因為它不具有前向安全(Forward Secrecy)。

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

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

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

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

RSA 密鑰交換在一段時間內(nèi)一直存在問題，其原因不僅僅是因為它支持前向保密。而是因為想要正確的實現(xiàn) RSA 密鑰交換也是不容易的。

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

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

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

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

為了降低非前向加密連接和 Bleichenbacher 漏洞所帶來的風險，RSA 加密已從 TLS 1.3 中刪除，將 Diffie-Hellman Ephemeral 作為唯一的密鑰交換機制。

提升性能

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

現(xiàn)在因為密碼套件大幅度簡化，也就沒有必要再像以前那樣走復雜的協(xié)商流程了。

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

那么它是怎么做的呢?其實具體的做法還是利用了擴展。

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

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

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

HTTPS 使用成本

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

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

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

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

作者：rickiyang

編輯：陶家龍

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