本文為《三萬長文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，這些根證書一般會內置到作業系統中，

大家可以到作業系統的證書目錄下，或者瀏覽器，看看證書檔案里面都有什么內容，

思考題：

1. 即使證書驗證通過了，這樣就能夠保證安全了么，想想還有沒有其他原因導致請求的網站身份不可信的；
2. 有了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跟進：

https://github.com/arthinking/java-tech-stack

關注我的博客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

著作權宣告： 著作權歸作者所有，未經許可不得轉載，侵權必究！聯系作者請加公眾號，

標籤：Java

上一篇：zookeeper go客戶端原理總結

下一篇：JUnit5學習之五：標簽(Tag)和自定義注解