本文為《三萬長文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。
有了摘要算法就能保證完整性了嗎？
假如黑客截取了信息，改動了信息之后，重新生成了摘要，那么，這個時候就判斷不出來消息是被篡改過了。
image-20200905224436088為了避免這類消息發生，我們需要給摘要也通過會話密鑰進行加密，這樣就看不到摘要明文信息了，能更好的保證信息的安全性了。
image-20200905230547998可見，離開了機密性，完整性也就無從說起了。
5.3.5、數字簽名
到目前為止，我們還有一個問題沒有解決，那就是：怎么知道我們要連接的網站不是偽造的呢，如果是偽造的，即使他給了我們他的公鑰，也是可以成功進行加解密的，因為他給的公鑰給他自己的私鑰本身就是一對。
如下圖，客戶端的請求被中間人截獲了，中間人給了客戶端自己的公鑰，最終客戶端把消息發給了中間人，中間人這個時候是可以解密密文拿到原始數據的。然后中間人請求實際的服務器，拿到了實際服務器的公鑰，再把消息轉發給實際的服務器。這樣就竊取了客戶端的信息了。
中間人攻擊
為了避免拿到假的公鑰，所以我們需要一個權威機構幫忙驗證這個公鑰是不是真的。
通過CA機構生成數字證書
這個時候我們請來了權威的機構，來幫忙我們生成網站公鑰的數字證書：
如上圖，服務器和CA機構分別有一對密鑰，服務器請求CA機構把服務器公鑰生成一個數字證書，生成流程：
- CA機構通過摘要算法生成公鑰的摘要；
- CA機構通過自己的CA私鑰以及特定的簽名算法加密摘要，生成簽名；
- 把簽名、服務器公鑰，以及其他基本信息打包放入數字證書中。
最后，CA機構把生成的數字證書返回給服務器。
服務器配置好生成的證書，以后客戶端連接服務器，都先把這個證書返回給客戶端，讓客戶端驗證并獲取服務器的公鑰。
服務器公鑰驗證流程
客戶端接收到服務器發送的數字證書和CA機構的公鑰，通過CA機構的公鑰對數字證書上的簽名進行驗證。
驗證過程：
- 使用CA公鑰和聲明的簽名算法對CA中的簽名進行解密，得到服務器公鑰的摘要內容；
- 拿到證書里面的服務器公鑰，用摘要算法生成摘要內容，與第一步的結果對比，如果一致，則說該證書就是合法的，里面的公鑰是正確的，否則證書就是非法的。
誰來保證CA的公鑰的正確性?
服務器驗證的時候，需要拿到數字證書發布機構的CA公鑰，但是怎么證明這個CA公鑰是正確的呢？這個時候就需要有更大的CA幫小的CA的公鑰做認證了，一層一層的背書，最頂層的CA，Root CA，稱為根證書，作為信任鏈的根，是全球皆知的的極大著名CA，這些根證書一般會內置到操作系統中。
image-20200906182339641大家可以到操作系統的證書目錄下，或者瀏覽器，看看證書文件里面都有什么內容。
思考題：
- 即使證書驗證通過了，這樣就能夠保證安全了么，想想還有沒有其他原因導致請求的網站身份不可信的；
- 有了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
版權聲明： 版權歸作者所有，未經許可不得轉載，侵權必究！聯系作者請加公眾號。
