HTTPS：網絡安全攻堅戰

本文爲《三萬長文50+趣圖帶你領悟web編程的內功心法》第五個章節。

五、HTTPS

咱們知道，明文傳輸和不安全是HTTP的其中一個特色，可是隨着愈來愈多機密的業務交易轉移到線上，如銀行轉帳、證券交易、在線支付、電商等，咱們對傳輸的安全性有了更高的要求，爲此，出現了HTTP的擴展：HTTPS，Hypertext Transfer Protocol Secure，超文本傳輸安全協議。

HTTPS默認端口號爲433，基於HTTP擴展了安全傳輸的特性，其餘特性徹底沿用HTTP。

5.一、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.二、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.三、TLS詳解

瀏覽器和服務器通訊以前，會先協商，選出他們都支持的加密套件，用於實現安全的通訊。

常見的加密套件能夠參考 161 Cipher Suites^[1]。

咱們選一個來看看加密套件的命名格式：

如最後一個組合，意味着：

• ECDHE: 握手時，使用ECDHE算法交換密鑰；
• ECDSA: 使用ECDSA算法進行簽名；
• AES128-GCM: 使用AES256對稱加密算法進行通訊，密鑰長度128，分組模式GCM；
• SHA256: 使用SHA256算法進行消息的完整性驗證和產生隨機數。

5.3.一、爲何須要用到這麼多算法？

以密碼學爲基礎的信息安全包含主要的五個方面：機密性，可用性，完整性，認證性，不能否認性。

爲了保證安全，TLS就須要保證這五個特性。簡要說明下這個五個特性：

• 機密性：保密信息不會透露給非受權的用戶或實體；
• 可用性：指的是加密服務的高可用；
• 完整性：信息不回被非法篡改，有對應的篡改檢測機制；
• 認證性：參與信息交換的兩個主體須要確認對方的身份是否可信，避免信息被不懷好意的人給竊取或者篡改；
• 不能否認性：指的是用戶在過後沒法否定曾經進行的信息交換、簽發；

每種算法，在TLS中都有其特定的用處，下面先簡單介紹各類算法。

5.3.二、對稱加密算法

所謂對稱加密，就是使用同一個密鑰進行加解密。

最多見的就是AES加密算法。

可是對稱加密，加解密雙方如何安全的傳遞密鑰是一個問題。若是服務器直接把密鑰傳輸給客戶端，而後才進行加密通訊，可能在傳輸密鑰的過程當中，密鑰就被竊取了。

5.3.三、非對稱加密

非對稱加密一般包含一對密鑰，稱爲公鑰(public key)和私鑰(private key)。

其中一個密鑰加密後的數據，只能讓另外一個密鑰進行解密。

使用公鑰推算出私鑰是很是困難的，可是隨着計算機運算能力提高，目前在程序中使用的非對稱密鑰至少要2048位才能保證安全性。

雖然非對稱加密可以保證安全性，可是性能卻比對稱加密差不少。

爲此，在TLS中，實際上用的是用到了兩種算法的混合加密。經過非對稱加密算法交換對稱加密算法的密鑰，交換完成以後，在使用對稱加密進行加解密傳輸數據。這樣就保證了會話的機密性。

5.3.四、摘要算法

摘要算法主要用於保證信息的完整性，至關於信息的指紋信息。常見的散列函數，哈希函數，MD5算法都屬於這類算法，其特色是單向性，沒法反推原文。

爲了保證安全性，目前TLS推薦使用SHA-2摘要算法，禁止使用MD5和SHA-1。

有了摘要算法就能保證完整性了嗎？

假如黑客截取了信息，改動了信息以後，從新生成了摘要，那麼，這個時候就判斷不出來消息是被篡改過了。

爲了不這類消息發生，咱們須要給摘要也經過會話密鑰進行加密，這樣就看不到摘要明文信息了，能更好的保證信息的安全性了。

可見，離開了機密性，完整性也就無從提及了。

5.3.五、數字簽名

到目前爲止，咱們還有一個問題沒有解決，那就是：怎麼知道咱們要鏈接的網站不是僞造的呢，若是是僞造的，即便他給了咱們他的公鑰，也是能夠成功進行加解密的，由於他給的公鑰給他本身的私鑰自己就是一對。

以下圖，客戶端的請求被中間人截獲了，中間人給了客戶端本身的公鑰，最終客戶端把消息發給了中間人，中間人這個時候是能夠解密密文拿到原始數據的。而後中間人請求實際的服務器，拿到了實際服務器的公鑰，再把消息轉發給實際的服務器。這樣就竊取了客戶端的信息了。

中間人攻擊

爲了不拿到假的公鑰，因此咱們須要一個權威機構幫忙驗證這個公鑰是否是真的。

經過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.六、算法總結

咱們來總結一下上面提到的各類算法的做用：

• 簽名算法：經過數字證書，和CA公鑰，驗證獲取到的服務器公鑰的可靠性，保證了認證性；
• 密鑰交換算法 + 對稱加密算法：經過交換的密鑰，進行加密通訊，保證了機密性和不能否認性；
• 摘要算法：保證完整性。

本文首次發表於: HTTPS：網絡安全攻堅戰 以及公衆號 Java架構雜談，未經許可，不得轉載。

5.四、HTTPS鏈接過程

HTTS鏈接訪問比HTTP多了一步TLS鏈接：DNS解析，TCP鏈接、TLS鏈接。

最關鍵的就是TLS鏈接，這裏咱們重點來分析。

其中TLS鏈接認證分爲單向認證和雙向認證：

單向認證 ：服務器提供證書，客戶端驗證服務器證書；

雙向認證 ：服務器客戶端分別提供證書給對方，並互相驗證對方的證書。

不過，大多數運行HTTPS的web服務器都不須要客戶端提供證書，若是服務器須要驗證客戶端的身份，通常是經過用戶名和密碼、手機驗證碼等之類的憑證來完成。對於更高安全級別要求的系統，如大額網銀轉帳等，則會提供雙向認證的場景，來確保對客戶身份提供認證性。

早期的TLS密鑰交換用的是RSA算法，目前主流都是用ECDHE算法來作密鑰交換的。下面咱們分別來介紹下。

5.4.一、基於TLS1.2的HTTPS鏈接過程

5.4.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.二、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.二、TLS1.3對安全性和性能的提高

TLS1.3是2018年發佈的，這個版本中對安全性和性能上有了大幅度提高。

5.4.2.一、安全性提高

這個版本中砍掉了不少不夠安全點加密套件中的算法，只提供了少而精的加密套件。

密鑰交換算法廢棄了RSA，更好地保證了安全性，不會由於RSA私鑰泄露致使歷史報文被破解的問題出現。

假設有人故意截獲了會話中全部的加密報文，在RSA算法中，若是私鑰泄露，那麼就能夠推算出PreMaster和對稱密鑰，那麼保存了全部的歷史報文都會被破解。

5.4.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

版權聲明： 版權歸做者全部，未經許可不得轉載，侵權必究！聯繫做者請加公衆號。

---

1. 161 Cipher Suites. Retrieved from https://ciphersuite.info/cs/?software=openssl&singlepage=true ↩︎