本文為《三萬長文50+趣圖帶你領悟web程式設計的內功心法》第五個章節。
5、HTTPS
我們知道，明文傳輸和不安全是HTTP的其中一個特點，但是隨著越來越多機密的業務交易轉移到線上，如銀行轉賬、證券交易、線上支付、電商等，我們對傳輸的安全性有了更高的要求，為此，出現了HTTP的擴充套件：HTTPS，Hypertext Transfer Protocol Secure，超文字傳輸安全協議。
HTTPS預設埠號為433，基於HTTP擴充套件了安全傳輸的特性，其他特性完全沿用HTTP。
5.1、HTTPS協議架構
我們先來看一看HTTP的協議架構和HTTPS協議架構的區別：
HTTP是基於TCP/IP的協議，中間沒有任何安全傳輸相關的模組。為此，HTTPS在中間引入了一個傳輸級的密碼安全層，該層可以使用安全套接層 Secure Sockets Layer(SSL)，也可以使用其後繼者：傳輸層安全 Transport Layer Security(TLS)。
HTTPS = HTTP + SSL or TLS
加入這層之後，收發報文也就不再是使用Socket API，而是呼叫了安全層提供的安全API。在使用HTTPS時無需過多的修改協議處理邏輯。
為此，如果我們弄清楚這個SSL/TLS，就理解了HTTPS的精華所在了。
5.2、SSL/TLS發展歷史
為了保證安全性，SSL/TLS在不斷的迭代升級版本，引入了更加安全的演算法套件。下面是大致的升級過程：
在1999年，SSL 3.0升級為TLS 1.0，寫入到RFC 2246標準中。
不過由於安全問題，TLS 1.1及其以下版本都將作廢，不再維護，目前主要在用的是TLS 1.2和TLS 1.3。
OpenSSL是開源版本的實現，目前急需在維護的是OpenSSL 1.1.1版本。
5.3、TLS詳解
瀏覽器和伺服器通訊之前，會先協商，選出他們都支援的加密套件，用於實現安全的通訊。
常見的加密套件可以參考 161 Cipher Suites[1]。
我們選一個來看看加密套件的命名格式：
如最後一個組合，意味著：
- ECDHE: 握手時，使用ECDHE演算法交換金鑰；
- ECDSA: 使用ECDSA演算法進行簽名；
- AES128-GCM: 使用AES256對稱加密演算法進行通訊，金鑰長度128，分組模式GCM；
- SHA256: 使用SHA256演算法進行訊息的完整性驗證和產生隨機數。
5.3.1、為什麼需要用到這麼多演算法？
以密碼學為基礎的資訊保安包含主要的五個方面：機密性，可用性，完整性，認證性，不可否認性。
為了保證安全，TLS就需要保證這五個特性。簡要說明下這個五個特性：
機密性：保密資訊不會透露給非授權的使用者或實體；可用性：指的是加密服務的高可用；完整性：資訊不回被非法篡改，有對應的篡改檢測機制；認證性：參與資訊交換的兩個主體需要確認對方的身份是否可信，避免資訊被不懷好意的人給竊取或者篡改；不可否認性：指的是使用者在事後無法否認曾經進行的資訊交換、簽發；
每種演算法，在TLS中都有其特定的用處，下面先簡單介紹各種演算法。
5.3.2、對稱加密演算法
所謂對稱加密，就是使用同一個金鑰進行加解密。
最常見的就是AES加密演算法。
但是對稱加密，加解密雙方如何安全的傳遞金鑰是一個問題。如果伺服器直接把金鑰傳輸給客戶端，然後才進行加密通訊，可能在傳輸金鑰的過程中，金鑰就被竊取了。
5.3.3、非對稱加密
非對稱加密通常包含一對金鑰，稱為公鑰(public key)和私鑰(private key)。
其中一個金鑰加密後的資料，只能讓另一個金鑰進行解密。
使用公鑰推算出私鑰是非常困難的，但是隨著計算機運算能力提升，目前在程式中使用的非對稱金鑰至少要2048位才能保證安全性。
雖然非對稱加密能夠保證安全性，但是效能卻比對稱加密差很多。
為此，在TLS中，實際上用的是用到了兩種演算法的混合加密。通過非對稱加密演算法交換對稱加密演算法的金鑰，交換完成之後，在使用對稱加密進行加解密傳輸資料。這樣就保證了會話的機密性。
5.3.4、摘要演算法
摘要演算法主要用於保證資訊的完整性，相當於資訊的指紋資訊。常見的雜湊函式，雜湊函式，MD5演算法都屬於這類演算法，其特點是單向性，無法反推原文。
為了保證安全性，目前TLS推薦使用SHA-2摘要演算法，禁止使用MD5和SHA-1。
有了摘要演算法就能保證完整性了嗎？
假如黑客擷取了資訊，改動了資訊之後，重新生成了摘要，那麼，這個時候就判斷不出來訊息是被篡改過了。
為了避免這類訊息發生，我們需要給摘要也通過會話金鑰進行加密，這樣就看不到摘要明文資訊了，能更好的保證資訊的安全性了。
可見，離開了機密性，完整性也就無從說起了。
5.3.5、數字簽名
到目前為止，我們還有一個問題沒有解決，那就是：怎麼知道我們要連線的網站不是偽造的呢，如果是偽造的，即使他給了我們他的公鑰，也是可以成功進行加解密的，因為他給的公鑰給他自己的私鑰本身就是一對。
如下圖，客戶端的請求被中間人截獲了，中間人給了客戶端自己的公鑰，最終客戶端把訊息發給了中間人，中間人這個時候是可以解密密文拿到原始資料的。然後中間人請求實際的伺服器，拿到了實際伺服器的公鑰，再把訊息轉發給實際的伺服器。這樣就竊取了客戶端的資訊了。
中間人攻擊
為了避免拿到假的公鑰，所以我們需要一個權威機構幫忙驗證這個公鑰是不是真的。
通過CA機構生成數字證照
這個時候我們請來了權威的機構，來幫忙我們生成網站公鑰的數字證照：
如上圖，伺服器和CA機構分別有一對金鑰，伺服器請求CA機構把伺服器公鑰生成一個數字證照，生成流程：
- CA機構通過摘要演算法生成公鑰的摘要；
- CA機構通過自己的CA私鑰以及特定的簽名演算法加密摘要，生成簽名；
- 把簽名、伺服器公鑰，以及其他基本資訊打包放入數字證照中。
最後，CA機構把生成的數字證照返回給伺服器。
伺服器配置好生成的證照，以後客戶端連線伺服器，都先把這個證照返回給客戶端，讓客戶端驗證並獲取伺服器的公鑰。
伺服器公鑰驗證流程
客戶端接收到伺服器傳送的數字證照和CA機構的公鑰，通過CA機構的公鑰對數字證照上的簽名進行驗證。
驗證過程：
- 使用CA公鑰和宣告的簽名演算法對CA中的簽名進行解密，得到伺服器公鑰的摘要內容；
- 拿到證照裡面的伺服器公鑰，用摘要演算法生成摘要內容，與第一步的結果對比，如果一致，則說該證照就是合法的，裡面的公鑰是正確的，否則證照就是非法的。
誰來保證CA的公鑰的正確性?
伺服器驗證的時候，需要拿到數字證照釋出機構的CA公鑰，但是怎麼證明這個CA公鑰是正確的呢？這個時候就需要有更大的CA幫小的CA的公鑰做認證了，一層一層的背書，最頂層的CA，Root CA，稱為根證照，作為信任鏈的根，是全球皆知的的極大著名CA，這些根證照一般會內建到作業系統中。
大家可以到作業系統的證照目錄下，或者瀏覽器，看看證照檔案裡面都有什麼內容。
思考題：
- 即使證照驗證通過了，這樣就能夠保證安全了麼，想想還有沒有其他原因導致請求的網站身份不可信的；
- 有了CA機構，就沒法進行中間人攻擊了嗎？
5.3.6、演算法總結
我們來總結一下上面提到的各種演算法的作用：
- 簽名演算法：通過數字證照，和CA公鑰，驗證獲取到的伺服器公鑰的可靠性，保證了認證性；
- 金鑰交換演算法 + 對稱加密演算法：通過交換的金鑰，進行加密通訊，保證了機密性和不可否認性；
- 摘要演算法：保證完整性。
本文首次發表於: HTTPS：網路安全攻堅戰 以及公眾號 Java架構雜談，未經許可，不得轉載。
5.4、HTTPS連線過程
HTTS連線訪問比HTTP多了一步TLS連線：DNS解析，TCP連線、TLS連線。
最關鍵的就是TLS連線，這裡我們重點來分析。
其中TLS連線認證分為單向認證和雙向認證：
單向認證 ：伺服器提供證照，客戶端驗證伺服器證照；
雙向認證 ：伺服器客戶端分別提供證照給對方，並互相驗證對方的證照。
不過，大多數執行HTTPS的web伺服器都不需要客戶端提供證照，如果伺服器需要驗證客戶端的身份，一般是通過使用者名稱和密碼、手機驗證碼等之類的憑證來完成。對於更高安全級別要求的系統，如大額網銀轉賬等，則會提供雙向認證的場景，來確保對客戶身份提供認證性。
早期的TLS金鑰交換用的是RSA演算法，目前主流都是用ECDHE演算法來做金鑰交換的。下面我們分別來介紹下。
5.4.1、基於TLS1.2的HTTPS連線過程
5.4.1.1、RSA金鑰交換演算法
這個過程稍微有點複雜，還是先上圖，流程的關鍵部分都加上了註釋，後面詳細解釋。
如上圖：
- 首先是TCP三次握手，握手成功之後，就可以開始通過TCP傳輸資料了；
- 接下來是TLS握手的流程：
- Client Hello：客戶端生成一個Client Random隨機數，明文傳送給伺服器，同時提供自己的 TLS版本號，以及自己支援的加密套件；
- Server Hello：伺服器收到之後，也生成了一個Server Random隨機數，明文傳送給客戶端，同時告知自己選擇的TLS版本號，以及選擇的加密套件；
- Server Certificate：伺服器傳送自己的證照給到客戶端；
- Server Hello Done：提示伺服器資訊傳送完畢；
- 客戶端收到證照之後進行證照的校驗，確保公鑰是合法的；
- Client Key Exchange：客戶端生成一個PreMaster隨機數，通過伺服器的公鑰加密傳輸給伺服器；
- 這個時候客戶端和伺服器都有三個引數：Server Random、Client Random、PreMaster，其中PreMaster是無法被不懷好意的人截獲的，通過這三個引數，生成對稱金鑰；
- 客戶端Change Cipher Spec：客戶端通知伺服器後續改用剛剛生成的金鑰進行加密通訊；
- 客戶端Encrypted Handshake Message：客戶端準備用剛剛的引數加密傳輸，驗證加密通訊；
- 伺服器Change Cipher Spec：伺服器也通知客戶端後續改用剛剛生成的金鑰進行加密通訊；
- 伺服器Encrypted Handshake Message：伺服器準備用剛剛的引數加密傳輸，驗證加密通訊；
- 在雙方都確認好了之後，最後是驗證的訊息。
這裡的核心是：通過非對稱加密交換引數，生成對稱通訊加密的金鑰，其中PreMaster是非對稱加密傳輸的，保證了不會洩露通訊加密的金鑰。
下面我們再來看看主流的ECDHE金鑰交換演算法的HTTPS連線過程。
5.4.1.2、ECDHE金鑰交換演算法
我把與基於RSA演算法的連線過程的差非同步驟都進行高亮顯示了，如下圖：
這裡我重點說明不一樣的地方：
- Server Key Exchange：在服務端傳送完證照之後，多了這一步，這個是橢圓曲線引數Server Params，為了保證認證性，這裡同時生成了Server Params的簽名，一起發給客戶端；
- Client Key Exchange：這裡不再是直接傳送客戶端生成PreMaster，而是生成客戶端的橢圓曲線引數Client Params，直接傳送給服務端；接著，客戶端和服務端雙方通過ECDHE演算法用Client Params和Server Params算出最終的PreMaster，這個PreMaster是保證不會被截獲的。這樣雙方就有了：Client Random，Server Random，PreMaster引數了，通過這三個引數就可以生成通訊金鑰了；
- 在客戶端傳送了Encrypted Handshake Message之後，就立刻傳送測試包了，不用等到服務端傳送完Encrypted Handshake Message。
5.4.2、TLS1.3對安全性和效能的提升
TLS1.3是2018年釋出的，這個版本中對安全性和效能上有了大幅度提升。
5.4.2.1、安全性提升
這個版本中砍掉了很多不夠安全點加密套件中的演算法，只提供了少而精的加密套件。
金鑰交換演算法廢棄了RSA，更好地保證了安全性，不會因為RSA私鑰洩露導致歷史報文被破解的問題出現。
假設有人故意截獲了會話中所有的加密報文，在RSA演算法中，如果私鑰洩露，那麼就可以推算出PreMaster和對稱金鑰，那麼儲存了所有的歷史報文都會被破解。
5.4.2.2、效能提升
上圖我們看到，TLS握手經歷了兩個RTT。
TLS1.3簡化了握手過程，主要就是把原來兩個RTT中的資訊，打包成一個傳送了，減少傳輸次數，最終只需要1個RTT就完成了資訊的交換和握手。
思考：用了HTTPS肯定會變慢，有什麼提升速度的措施呢？
這篇文章的內容就介紹到這裡，能夠閱讀到這裡的朋友真的是很有耐心，為你點個贊。
本文為arthinking基於相關技術資料和官方文件撰寫而成，確保內容的準確性，如果你發現了有何錯漏之處，煩請高抬貴手幫忙指正，萬分感激。
如果您覺得讀完本文有所收穫的話，可以關注我的賬號，或者點贊吧，碼字不易，您的支援就是我寫作的最大動力，再次感謝！
為了把相關係列文章收集起來，方便後續查閱，這裡我建立了一個Github倉庫，把釋出的文章按照分類收集起來了，感興趣的朋友可以Star跟進：
關注我的部落格IT宅(itzhai.com)或者公眾號Java架構雜談，及時獲取最新的文章。我將持續更新後端相關技術，涉及JVM、Java基礎、架構設計、網路程式設計、資料結構、資料庫、演算法、併發程式設計、分散式系統等相關內容。
References
- 謝希仁. 計算機網路(第6版). 電子工業出版社.
- TCP/IP詳解 卷1：協議（原書第2版）. 機械工業出版社.
- UNIX網路程式設計 卷1：套接字聯網API. 人民郵電出版社
- HTTP權威指南. 人民郵電出版社
- HTTP/2基礎教程. 人民郵電出版社
- 劉超. 趣談網路協議. 極客時間
- 羅劍鋒. 透視HTTP協議. 即可時間
本文同步發表於我的部落格IT宅(itzhai.com)和公眾號(Java架構雜談)
作者：arthinking | 公眾號：Java架構雜談
部落格連結：https://www.itzhai.com/articles/https-the-battle-for-network-security.html
版權宣告： 版權歸作者所有，未經許可不得轉載，侵權必究！聯絡作者請加公眾號。