由于歷史的因素，很多時候 SSL/TLS 兩個詞會被混用。下圖是 SSL/TLS 的發(fā)展歷史圖：

TLS 的功能如下：

1. 加密：TLS 對內(nèi)容加密，因此即使第三方攔截了數(shù)據(jù)，也沒辦法判讀內(nèi)容，只能看到一串亂碼。
2. 身份驗證：TLS 用證書確定通信的服務(wù)器的身份。
3. 完整性驗證：TLS 確保數(shù)據(jù)在傳輸?shù)倪^程中沒有被竄改。

TLS 的原理

建立 TLS 連接的第一步是由 TLS 握手開始?？蛻舳撕头?wù)器在 TLS 握手中會執(zhí)行以下幾件事：

1. 指定使用的 TLS 版本。
2. 指定使用的密碼套件（cipher suite），其中包含了用于會話密鑰加密的算法、密鑰交換算法，以及消息認證碼（MAC）驗證算法。
3. 客戶端使用服務(wù)器提供的 TLS 證書驗證服務(wù)器的身份。
4. 握手完成后生成會話密鑰 (session key) 用來加密客戶端和服務(wù)器之間的信息。

在 TLS 握手的過程中，首先服務(wù)器會提供 TLS 證書向客戶端證明其身份，接著通過密鑰交換的機制產(chǎn)生用來加密信息的會話密鑰。后續(xù)的數(shù)據(jù)會被加密，并且使用 MAC 算法進行簽名，接受方可以用 MAC 驗證數(shù)據(jù)是否有被篡改。

接下來會介紹 TLS 中如何做到加密、身份驗證和完整性驗證。

混合式加密

對稱式加密的好處是快速且能進行雙向通信，但是如果沒辦法讓通信的兩端安全的使用同一把密鑰，那么對稱式加密也無用武之地。

非對稱加密的好處是能實現(xiàn)安全的單向通信，但是缺點是速度慢，也不適合雙向的通信。那該怎么克服這些缺點，讓我們能夠安全又快速的傳遞信息呢？

在 TLS 中，同時使用了對稱加密和非對稱加密兩種技術(shù)，來實現(xiàn)安全又高效的雙向通信。

在 TLS 中，會使用會話密鑰來進行信息的加密。會話密鑰是對稱式加密，客戶端和服務(wù)器端擁有同樣的會話密鑰，可同時用于加密和解密。

同時，為了要讓客戶端和服務(wù)器端兩邊有同樣的會話密鑰，客戶端和服務(wù)器端會使用密鑰交換算法 (運用到非對稱加密技術(shù)) 來安全地產(chǎn)生會話密鑰。

SSL/TLS 證書

SSL 證書，準確來說是 TLS 證書，是在 SSL/TLS 連接中用來進行服務(wù)器身份驗證的一份文件，是由 CA (Certificate Authority，證書頒發(fā)機構(gòu)) 發(fā)給個人或企業(yè)。

SSL/TLS 證書包含了以下重要信息：

• 域名 (domain) 的擁有者是誰
• 服務(wù)器的公鑰(并且被 CA 的私鑰簽署 (sign) 過)。

為了要能夠進行服務(wù)器的身份驗證，首先在網(wǎng)站需要在服務(wù)器上安裝 SSL/TLS 證書，然后在 TLS 握手的過程中傳給客戶端。比如瀏覽器通常內(nèi)建 CA 的公鑰，因此可以驗證被 CA 簽署過的證書，達到驗證服務(wù)器身份的目的。

按照支持的域名類型來區(qū)分，SSL證書可以分為單域名證書、通配符證書以及多域名SSL證書等。

在證書頒發(fā)機構(gòu)（CA）簽發(fā) TLS 證書之前，會進行不同程度的身份驗證。依據(jù)驗證的嚴格程度，TLS 證書可分為域名驗證（Domain Validation, DV）、組織驗證（Organization Validation, OV）和擴展驗證（Extended Validation, EV）SSL 證書。

MAC

加密過后的信息可以用 MAC (Message Authentication Code，消息驗證碼) 的技術(shù)來達到完整性驗證。常見的有 MD5/SHA 等算法。

會話密鑰是什么？

會話密鑰（session key）的作用是加密 HTTPS 中服務(wù)器端和客戶端之間溝通的信息。

要使用會話密鑰對 HTTPS 的信息加密，需要先進行TLS 握手，TLS 握手的其中一個目的就是讓客戶端和服務(wù)器端協(xié)商產(chǎn)生會話密鑰。

在 TLS 握手的過程中，會產(chǎn)生下列的隨機數(shù)據(jù)，這些隨機數(shù)據(jù)會被用來產(chǎn)生會話密鑰：

• Client Random: 從客戶端發(fā)送到服務(wù)器的隨機字符串。
• Server Random: 從服務(wù)器發(fā)送到客戶端的隨機字符串。
• Premaster Secret（預主密鑰）: 一個隨機字符串，經(jīng)過一些運算得出。在某些版本的 TLS 握手中，客戶端生成預主密鑰并加密后送至服務(wù)器；某些版本的 TLS 握手中，客戶端和服務(wù)器分別使用相同的算法和參數(shù)算出相同的預主密鑰。
• Master Secret（主密鑰）: 客戶端和服務(wù)器通過組合 client random, server random, premaster secret 運算出主密鑰。

客戶端和服務(wù)器可以用主密鑰（master secret） 計算出四個會話密鑰（session key），分別是：

• 客戶端寫密鑰（Client Write Key）
• 服務(wù)器寫密鑰（Server Write Key）
• 客戶端寫消息認證碼密鑰（Client Write MAC Key）
• 服務(wù)器寫消息認證碼密鑰（Server Write MAC Key）

Client write key 是對稱密鑰，由客戶端發(fā)送的信息會由 client write key 加密，在服務(wù)器端會由同一把 client write key 解密；同樣的，Server write key 也是對稱密鑰，由服務(wù)器端發(fā)送給客戶端的信息會由 server write key 加密，在客戶端由瀏覽器或設(shè)備用同一把 server write key 解密。

Client/Server MAC Key 的作用是對信息進行簽名。服務(wù)器用 server write MAC key 對發(fā)給客戶端的信息進行簽名，客戶端收到信息后可以用自己的 server write MAC key 做驗證；同樣地，客戶端用 client write MAC key 對發(fā)送給服務(wù)器端的信息進行簽名，服務(wù)器用自己的 client write MAC key 進行驗證。

TLS 握手是什么？

為了要使用 TLS 加密協(xié)議，我們要先啟動 TLS 握手。

每當用戶使用 HTTPS 通信的時候，首先瀏覽器會和服務(wù)器通過 TCP 握手建立 TCP 連接。當 TCP 連接建立完成后，就會開始 TLS 握手。

TLS 握手期間會發(fā)生以下的事情：

1. 指定使用的 TLS 版本 (TLS 1.0, 1.2, 1.3 等)
2. 決定使用的密碼套件（ cipher suite ）。密碼套件是一組算法的組合：
• 密鑰交換算法。
• 加密算法。
• MAC 算法
3. 驗證服務(wù)器的身份
4. 產(chǎn)生 session key（會話密鑰）

TLS 握手的具體步驟根據(jù)密鑰交換算法不同而有所差異。下面舉 RSA 和 Ephemeral Diffie-Hellman 兩種不同的密鑰交換算法為例：

RSA Key Exchange

1. Client hello: 客戶端向服務(wù)器端發(fā)送 “client hello”，其中包含客戶端支持的 TLS 版本、客戶端支持的密碼套件、由客戶端產(chǎn)生的隨機字符串 client random。
2. Server hello: 服務(wù)器端回復 “server hello” 的信息，其中包含服務(wù)器的 SSL 證書、選擇使用的密碼套件、由服務(wù)器端產(chǎn)生的隨機字符串 server random。
3. 客戶端用 SSL 證書驗證服務(wù)器的身份。
4. 客戶端再產(chǎn)生一個隨機字符串 premaster secret（預主密鑰），并且用公鑰加密過后傳給服務(wù)器 (公鑰來自于 SSL 證書)。因為用公鑰加密過，只有擁有私鑰的服務(wù)器端可以解密。
5. 服務(wù)器用私鑰解密 premaster secret（預主密鑰）。
6. 客戶端和服務(wù)器端分別使用 client random + server random + premaster secret （預主密鑰）產(chǎn)生 session key（會話密鑰）。他們會得到同樣的結(jié)果。
7. 客戶端向服務(wù)器端發(fā)送一條用會話密鑰加密過的 “finished” 的消息。
8. 服務(wù)器端向客戶端發(fā)送一條用會話密鑰加密過的 “finished” 的消息。
9. 握手完成，之后的信息都使用會話密鑰加解密。

Ephemeral Diffie-Hellman Key Exchange

1. Client hello: 客戶端向服務(wù)器端發(fā)送 “client hello”，其中包含客戶端支持的 TLS 版本、客戶端支持的密碼套件、由客戶端產(chǎn)生的隨機字符串 client random。
2. Server hello: 服務(wù)器端回復 “server hello” 的信息，其中包含服務(wù)器的 SSL 證書、選擇使用的密碼套件、以及服務(wù)器用私鑰加密過的 client random / server random / DH 參數(shù)，這個加密的動作等于數(shù)字簽名，可以驗證服務(wù)器的身份。
3. 驗證：客戶端用公鑰解開服務(wù)器加密的信息，同時驗證服務(wù)器的身份。
4. 客戶端將其 DH 參數(shù)傳給服務(wù)器。
5. 客戶端和服務(wù)器端各自用 DH 參數(shù)計算出 premaster secret（預主密鑰）。和 RSA 不同，客戶端并沒有將 premaster secret （預主密鑰）加密后送給服務(wù)器端。
6. 客戶端和服務(wù)器端分別使用 client random + server random + premaster secret（預主密鑰） 產(chǎn)生 session key（會話密鑰）。他們會得到同樣的結(jié)果。
7. 客戶端向服務(wù)器端發(fā)送一條用會話密鑰加密過的 “finished” 的消息。
8. 服務(wù)器端向客戶端發(fā)送一條用會話密鑰加密過的 “finished” 的消息。
9. 握手完成，之后的信息都使用會話密鑰加解密。

前向保密 (Forward Secrecy)

前向保密的意思是：即使私鑰被泄露，加密過的數(shù)據(jù)也維持著加密的狀態(tài)，不會被破解。

在 RSA 中，由于 premaster secret （預主密鑰）是通過公鑰加密，因此私鑰暴露表示可以解密所有的 premaster secret（預主密鑰），再加上 client random 及 server random 都是明文傳遞，可以計算出所有 session key（會話密鑰），因此 RSA 不具有前向保密性。

在 Ephemeral Diffie-Hellman 握手中，私鑰只用于驗證服務(wù)器身份，并且每個會話都產(chǎn)生獨立的 session key（會話密鑰），因此即使私鑰暴露也沒辦法解密過去的信息，具有前向保密能力。

SNI (Server Name Indication) 是什么？

SNI (Server Name Indication) 是 TLS 協(xié)議的一部份，其作用在于當多個不同的域名被托管在同一IP地址上時，服務(wù)器能夠根據(jù)客戶端在建立HTTPS 連接時發(fā)送的請求信息返回相應的 TLS 證書，從而確保 HTTPS 連接能夠正確且安全地建立。

之所以要介紹 SNI 的原因是，它關(guān)系到一個很細節(jié)但很重要的知識：HTTPS 沒有加密域名。

在了解 SNI 是什么之前，我們需要先了解一個常見的情境：很多個網(wǎng)站可以共享一個 IP，舉例來說 https://www.example.com 和 https://www.another-website.com 可能背后是由同一臺服務(wù)器服務(wù)，有著相同的 IP 地址。

在這個情況下，如果要進行 HTTPS 連接會有一個問題，就是服務(wù)器不知道要給客戶端哪一張 SSL 證書，因為服務(wù)器不知道客戶端打算跟哪一個網(wǎng)站連接。其中要特別注意的是，在 HTTPS 連接中，要先完成 TLS 握手才能進行真正的 HTTP 通信，所以我們沒辦法通過 HTTP 請求的內(nèi)容去判斷要跟哪一個域名連接。

如果服務(wù)器給了錯誤的證書，客戶端可能會顯示不是安全連接。

SNI 就是要解決這個問題。當客戶端和服務(wù)器連接時，客戶端會告訴服務(wù)器目的地的域名，讓服務(wù)器端可以響應相對應的證書。

具體來說，SNI 會在 client hello 的信息中包含域名，作為 TLS 握手的第一步。要特別注意的是，client hello 是明文的，所以 HTTPS 中域名是沒有加密的。

ESNI (Encrypted SNI)

SNI 是 TLS 握手過程中的 client hello 信息的一部分，包含了客戶端想要連接的服務(wù)器域名，服務(wù)器收到信息后應該回復相對應的證書。

注意到 SNI 是未加密的，只有在整個 TLS 握手完成后，通信的內(nèi)容才是有加密的。這表示任何人都可以知道客戶端正在跟哪個域名進行通信，這讓攻擊者有機可趁，例如攻擊者可以制作域名名稱和內(nèi)容相近的釣魚網(wǎng)站。

ESNI (Encrypyed ESI) 通過加密來保護使用者。服務(wù)器將公鑰加到他的 DSN 紀錄中，客戶端可以用公鑰對 ESI 的部分加密，只有特定的服務(wù)器可以解密。

然而光靠 ESNI 并沒有辦法阻止有心人士知道客戶端正在跟哪個網(wǎng)站連接。由于 DNS 是明文的，所以第三者還是可以知道你打算跟哪個網(wǎng)站連接。一些機制可以提供進一步的保護，像是 DNSSEC 可以確定我們連到一個可信的 DNS 服務(wù)器；DNS over HTTPS（DoH）和 DNS over TLS（DoT）則分別通過HTTPS協(xié)議和TLS協(xié)議加密DNS查詢過程，從而確保整個 DNS 查詢內(nèi)容在傳輸過程中是受到保護和加密的，防止數(shù)據(jù)被竊取或監(jiān)聽。

HTTPS FAQ

下面討論一些 HTTPS 的常見問題：

HTTPS 有加密哪些東西？

下面是一個 HTTP 請求的范例：

因為 HTTP 是完全沒有加密的，所以這些東西都會被看光光：

• IP
• 域名
• 完整的請求 URL，包含 query string
• HTTP method (GET/POST/…)
• HTTP status code (HTTP 狀態(tài)碼)
• 所有的 HTTP header，包含 cookie
• HTTP body

HTTPS 加密后的請求范例如下：

可以看到 URL 的后半段包含 query string 是有被加密的 (但是域名沒有)；HTTP method 和 status code 是有加密的；所有的 HTTP header (包含 cookie) 都是有被加密的；所有的 HTTP body 都是有被加密的。

HTTPS 沒有加密哪些東西？

在 HTTPS 中，沒有被加密的東西有 IP 地址和域名。

原因如下：

• 在 DNS lookup 的過程中，如果采用未加密的 DNS lookup，IP 跟域名就是明文傳遞的。
• 在 TLS 握手的過程中，SNI (Server Name Indication) 會在 client hello 的信息中夾帶明文的域名，以便服務(wù)器可以返回正確的 TLS certificate 供客戶端認證。

為什么 HTTPS 沒有加密域名？

主要是為了支持 SNI (Server Name Indication)，目的是讓多個域名可以綁定在同一個 IP 地址上。

在 TLS 握手的過程中，SNI (Server Name Indication) 會在 client hello 的信息中夾帶明文的域名，以便服務(wù)器可以返回正確的 TLS certificate 供客戶端認證。

另外，DNS lookup 的過程中也會泄露域名的信息，即使使用了 DNSSEC 也一樣。DNSSEC 只能保證拿到正確的 IP 地址，不能保證這個信息是有被加密的或是完整性，且如果失敗的話瀏覽器也不會有提示。

HTTPS 如何預防 DNS spoofing？

DNS Spoofing，又稱作 DNS Cache Poisoning，是將錯誤的信息放進 DNS cache，使得 DNS lookup 的結(jié)果錯誤，進而將用戶導到錯誤的網(wǎng)站。DNSSEC 是為了解決這個問題而生的，但尚未受到全面采用。

如果網(wǎng)站使用了 HSTS (HTTP Strict Transport Security)，可以強制瀏覽器在瀏覽網(wǎng)站的時候必須使用 HTTPS。這表示 DNS spoofing 的攻擊者同時也需要破解 HTTPS，可以讓攻擊的難度提升不少。

HTTPS 和 HTTP/2 有什么關(guān)系？

HTTP/2 是 HTTP/1.1 的更新版協(xié)議，完成于 2015 年，主要目的是提升 HTTP 協(xié)議的效率和性能。

雖然 HTTP/2 并沒有強制要求加密，但主流瀏覽器都只實現(xiàn)了加密的 HTTP/2，因此可以說 HTTP/2 強制使用 HTTPS。

如何決定是用 HTTPS 還是用 HTTP/2？

因為 HTTP/2 是基于 HTTPS 的，實務(wù)上在 TLS 握手的過程中，client hello 信息中可以通過 ALPN (Application Layer Protocol Negotiation，應用層協(xié)議協(xié)商) 表示客戶端支持 HTTP/2，如果服務(wù)器也支持 HTTP/2 就可以順利轉(zhuǎn)而使用 HTTP/2。