狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

HTTPS 是一種網絡通信協議，可確保數據在使用者的電腦和網站之間傳輸時的安全性。本文深入探討 HTTPS 背后的技術原理，包括對稱加密、非對稱加密和 TLS，展示為何 HTTPS 是確保網絡通信安全的關鍵所在。

HTTP 是什么？

在了解什么是 HTTPS 之前，我們需要先稍微了解 HTTP 是什么，HTTPS 其實就只是有加密版本的 HTTP。

HTTP 是超文本傳輸協議 (Hypertext Transfer Protocol)，通過一些事先定義好的格式來傳遞數據。許多通過網絡的數據傳輸都是通過 HTTP 協議達成的，例如瀏覽網頁以及 API 調用。

HTTP 的信息主要分為兩種：請求 (request) 和響應 (response)。當我們在網頁上進行交互時，會產生 HTTP 請求和 HTTP 響應。舉例來說，當我們點擊超鏈接或是在 Google 搜索內容時，會發出 HTTP GET 請求到服務器，服務器會處理這些請求并響應 HTML 作為 HTTP 響應，讓瀏覽器可以渲染頁面。

一個 HTTP 請求可能像這樣：

GET /hello.txt HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.example.com
Accept-Language: en

這個 HTTP 請求會由瀏覽器產生，并通過網絡發送給服務器。

一個 HTTP 響應可能像這樣：

HTTP/1.1 200 OK
Date: Wed, 30 Jan 2019 12:14:39 GMT
Server: Apache
Last-Modified: Mon, 28 Jan 2019 11:17:01 GMT
Accept-Ranges: bytes
Content-Length: 12
Vary: Accept-Encoding
Content-Type: text/plain

Hello World!

注意 HTTP 是明文傳遞的，使用 HTTP 表示任何人都可以讀取請求和響應的內容，包括敏感信息，例如：信用卡號、帳號密碼等，所以 HTTP 是不安全的。

HTTPS 是什么? 和 HTTP 的差別是什么？

HTTPS 是安全版本的 HTTP。HTTP 和 HTTPS 的差別在于，HTTPS 使用 TLS 協議來加密 HTTP 請求和響應。

HTTP 不安全的理由主要有三個：

1. 因為 HTTP 的數據是明文傳遞的，也就是說當我們在使用 HTTP 時，我們的敏感信息如密碼、信用卡號是未加密的，可以被任何第三者看到。
2. 因為 HTTP 沒有身份驗證的功能，我們沒辦法確定通信的對方就是他所宣稱的身份。
3. 因為 HTTP 沒有可靠的驗證內容的方法，我們沒辦法確定通信的內容沒有被竄改過，也就是所謂的中間人攻擊。

TLS 可以有效的解決這些問題。使用了 TLS 協議，會有以下的好處：

1. 加密：客戶端和服務器之間傳輸的所有數據都是經過加密的，第三者即使攔截數據也只能看到一串亂碼，沒辦法知道通信的內容。
2. 身份驗證：通過 TLS 證書的機制，可以驗證對方的身份。
3. 完整性驗證：通過 MAC (Message Authentication Code，消息驗證碼) 的機制，可以保證數據在傳遞過程中沒有被篡改。

使用 HTTPS 協議的網站 URL 以 https:// 開頭，使用 HTTP 協議的網站 URL 則是以 http:// 開頭。

通過 HTTPS 傳遞的內容，攻擊者只能看到一堆隨機的字符串，而不是明文。舉例來說，用 HTTP 傳輸的內容，攻擊者可以看到類似以下的明文信息：

GET /hello.txt HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.example.com
Accept-Language: en

相反地，用 HTTPS 傳輸的內容，攻擊者只能看到類似以下的加密字符串：

t8Fw6T8UV81pQfyhDkhebbz7+oiwldr1j2gHBB3L3RFTRsQCpaSnSBZ78Vme+DpDVJPvZdZUZHpzbbcqmSW1+3xXGsERHg9YDmpYk0VVDiRvw1H5miNieJeJ/FNUjgH0BmVRWII6+T4MnDwmCMZUI/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==

整個 HTTPS 信息都經過完整的加密，包含 HTTP 方法、狀態碼、URL、query string、HTTP headers (包含 cookie)、HTTP body 等全部都有加密。

值得注意的是，域名 和 IP 是在 HTTPS 中沒有被加密的。

要了解 HTTPS 和 TLS 如何運作，需要對加密有基本的了解，下面就來介紹加密的基本常識。

加密的原理

加密是一種將明文轉變成難以理解的密文的過程。通常加密會需要一個密鑰 (key)，解密也會需要一個 key，只有通過解密的 key 才能夠將密文轉變回明文。Key 通常是一個字符串。

 

加密主要有兩種形式：對稱加密 (symmetric encryption) 和 非對稱加密 (asymmetric encryption)。

對稱加密 (Symmetric Encryption)

對稱加密中，加密和解密都是使用同一把 key。下圖展示了對稱加密的原理：

 

非對稱加密 (Asymmetric Encryption)

非對稱加密中，有兩把 key，一把 key 是公開的，任何人都可以拿到，所以又稱為公鑰 (public key)；另外一把 key 是保密的，只有 key 的主人擁有這把 key，因此又稱為私鑰 (private key)。非對稱加密也被稱為公鑰加密。

非對稱加密有兩個主要的使用方式：

1. 用公鑰加密的數據，只能用私鑰解開。因此通過非對稱加密算法，所有人都可以將加密過的信息傳給私鑰的擁有者，只有私鑰的擁有者能解開。
2. 用私鑰加密的數據，只能用公鑰解開。因此通過非對稱加密算法，所有人都可以用公鑰解開一條由私鑰加密過的信息，確認這條信息是由私鑰的擁有者所送出。

下圖展示了非加密對稱的原理：

 

SSL/TLS 是什么？

SSL (Secure Socket Layer) 是一種加密協議，可以讓客戶端和服務器端之間的通信保持加密。

TLS (Transport Layer Security，傳輸層安全性協議) 是 SSL 的更安全版本，目前網絡的世界中的安全通信大多采用 TLS，TLS 1.3 是最新的版本。

在 HTTPS 中，使用了 TLS 保護數據傳輸的安全。

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

TLS 的功能如下：

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

TLS 的原理

建立 TLS 連接的第一步是由 TLS 握手開始。客戶端和服務器在 TLS 握手中會執行以下幾件事：

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

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

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

混合式加密

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

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

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

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

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

SSL/TLS 證書

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

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

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

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

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

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

MAC

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

會話密鑰是什么？

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

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

在 TLS 握手的過程中，會產生下列的隨機數據，這些隨機數據會被用來產生會話密鑰：

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

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

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

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

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

TLS 握手是什么？

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

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

TLS 握手期間會發生以下的事情：

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

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

RSA Key Exchange

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

Ephemeral Diffie-Hellman Key Exchange

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

前向保密 (Forward Secrecy)

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

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

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

SNI (Server Name Indication) 是什么？

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

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

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

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

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

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

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

ESNI (Encrypted SNI)

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

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

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

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

HTTPS FAQ

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

HTTPS 有加密哪些東西？

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

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

• IP
• 域名
• 完整的請求 URL，包含 query string
• HTTP method (GET/POST/…)
• HTTP status code (HTTP 狀態碼)
• 所有的 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 的信息中夾帶明文的域名，以便服務器可以返回正確的 TLS certificate 供客戶端認證。

為什么 HTTPS 沒有加密域名？

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

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

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

HTTPS 如何預防 DNS spoofing？

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

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

HTTPS 和 HTTP/2 有什么關系？

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

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

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

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