欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

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

TLS 的功能如下：

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

TLS 的原理

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

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

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

接下來(lái)會(huì)介紹 TLS 中如何做到加密、身份驗(yàn)證和完整性驗(yàn)證。

混合式加密

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

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

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

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

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

SSL/TLS 證書(shū)

SSL 證書(shū)，準(zhǔn)確來(lái)說(shuō)是 TLS 證書(shū)，是在 SSL/TLS 連接中用來(lái)進(jìn)行服務(wù)器身份驗(yàn)證的一份文件，是由 CA (Certificate Authority，證書(shū)頒發(fā)機(jī)構(gòu)) 發(fā)給個(gè)人或企業(yè)。

SSL/TLS 證書(shū)包含了以下重要信息：

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

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

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

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

MAC

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

會(huì)話密鑰是什么？

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

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

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

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

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

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

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

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

TLS 握手是什么？

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

每當(dāng)用戶使用 HTTPS 通信的時(shí)候，首先瀏覽器會(huì)和服務(wù)器通過(guò) TCP 握手建立 TCP 連接。當(dāng) TCP 連接建立完成后，就會(huì)開(kāi)始 TLS 握手。

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

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

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

RSA Key Exchange

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

Ephemeral Diffie-Hellman Key Exchange

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

前向保密 (Forward Secrecy)

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

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

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

SNI (Server Name Indication) 是什么？

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

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

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

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

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

SNI 就是要解決這個(gè)問(wèn)題。當(dāng)客戶端和服務(wù)器連接時(shí)，客戶端會(huì)告訴服務(wù)器目的地的域名，讓服務(wù)器端可以響應(yīng)相對(duì)應(yīng)的證書(shū)。

具體來(lái)說(shuō)，SNI 會(huì)在 client hello 的信息中包含域名，作為 TLS 握手的第一步。要特別注意的是，client hello 是明文的，所以 HTTPS 中域名是沒(méi)有加密的。

ESNI (Encrypted SNI)

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

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

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

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

HTTPS FAQ

下面討論一些 HTTPS 的常見(jiàn)問(wèn)題：

HTTPS 有加密哪些東西？

下面是一個(gè) HTTP 請(qǐng)求的范例：

因?yàn)?HTTP 是完全沒(méi)有加密的，所以這些東西都會(huì)被看光光：

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

HTTPS 加密后的請(qǐng)求范例如下：

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

HTTPS 沒(méi)有加密哪些東西？

在 HTTPS 中，沒(méi)有被加密的東西有 IP 地址和域名。

原因如下：

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

為什么 HTTPS 沒(méi)有加密域名？

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

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

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

HTTPS 如何預(yù)防 DNS spoofing？

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

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

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

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

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

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

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