談談HTTPS演變過程

前言

本文談談HTTPS設計演變過程，但願對你們理解HTTPS有幫助，有不對的地方歡迎指出。

密碼學基礎知識

在討論HTTPS以前，須要掌握一些密碼學基礎概念。

明文、密文、密鑰

明文： 指沒有通過加密的信息/數據。

密文： 明文被某種加密算法加密以後，會變成密文，從而確保原始數據的安全。密文也能夠被解密，獲得原始的明文。

密鑰： 是一種參數，它是在明文轉換爲密文或將密文轉換爲明文的算法中輸入的參數。密鑰分爲對稱密鑰與非對稱密鑰。

對稱加密

定義： 須要對加密和解密使用相同密鑰的加密算法。因爲其速度快，對稱性加密一般在消息發送方須要加密大量數據時使用。對稱性加密也稱爲密鑰加密。

經常使用的對稱加密算法： DES、3DES、TDEA、Blowfish、RC二、RC四、RC五、IDEA、SKIPJACK等。

加密過程： 明文 + 加密算法 + 私鑰 => 密文

解密過程： 密文 + 解密算法 + 私鑰 => 明文

因爲對稱加密的算法是公開的，因此一旦私鑰被泄露，那麼密文就很容易被破解，因此對稱加密的缺點是密鑰安全管理困難。

非對稱加密

定義

1. 非對稱加密算法須要兩個密鑰：公開密鑰和私有密鑰。公開密鑰與私有密鑰是一對，若是用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；若是用私有密鑰對數據進行加密，那麼只有用對應的公開密鑰才能解密。
2. 公鑰指的是公共的密鑰，任何人均可以得到該密鑰。私鑰被本身保存，不能對外泄露。
3. 由於加密和解密使用的是兩個不一樣的密鑰，因此這種算法叫做非對稱加密算法。

經常使用非對稱加密算法： RSA、Elgamal、揹包算法、Rabin、D-H、ECC（橢圓曲線加密算法）等。

被公鑰加密過的密文只能被私鑰解密，過程以下：

明文 + 加密算法 + 公鑰 => 密文， 密文 + 解密算法 + 私鑰 => 明文

被私鑰加密過的密文只能被公鑰解密，過程以下：

明文 + 加密算法 + 私鑰 => 密文， 密文 + 解密算法 + 公鑰 => 明文

HTTP明文傳輸

HTTPS發展源頭是HTTP（超文本傳輸協議），因此咱們先來看看HTTP傳輸，以下：

流程

客戶端，把一條消息，以明文的方式，發送到服務器。

那麼在網絡上赤裸裸的明文傳輸會有什麼問題呢？

問題

請君試想，若是HTTP請求被某個不懷好意的中間人截取，而且，消息包含銀行密碼等敏感信息的話，形成的後果不堪設想吧。

解決方案

既然明文傳輸會有問題，那麼，咱們能夠用加密算法加密嘛。

對稱算法加密+HTTP

接下來，看看用對稱算法加密後，是怎樣的，如圖：

流程

• 客戶端把要發送的消息，用密鑰加密成密文。
• 客戶端把密文發送到服務器。
• 服務器收到密文消息，用同一把密鑰把密文解密成明文。

問題

這種方式仍是有問題，一開始客戶端怎麼把密鑰發過去呢？若是不懷好意的中間人截取到了密鑰，發送的消息仍是會被盜取和利用呢。

解決方案

能夠考慮非對稱加密試試。

非對稱加密+HTTP

OK,咱們再來看看，使用非對稱加密算法，又是怎樣，如圖：

流程

• 客戶端向服務器發起HTTPS請求，鏈接到服務器的443端口。
• 服務端將本身的公鑰返回到客戶端。
• 客戶端使用返回的公鑰，給要發送的消息加密。
• 客戶端將加密以後的消息密文發送給服務器。
• 服務器接收到客戶端發來的密文以後，會用本身的私鑰對其進行非對稱解密，解密以後獲得消息數據。

問題

縱觀整個過程，感受沒啥問題，即便中間人截取了公鑰，也沒啥用，他沒有私鑰解密不了。可是，非對稱算法（如：RSA）有個弊端，它很慢。試想一下，若是你用瀏覽器請求，它好久才響應，你能接受嗎？

解決方案

由於對稱加密快，可是它安全性不高，非對稱加密安全性高，可是它慢，那麼，能夠考慮非對稱加密+對稱加密結合一塊兒嘛。

非對稱加密+對稱加密+HTTP

非對稱加密+對稱加密雙劍合璧的流程圖以下：

流程

• 客戶端向服務器發起HTTPS請求，鏈接到服務器的443端口。
• 服務端將本身的公鑰返回到客戶端。
• 客戶端產生對稱加密密鑰，並用服務端返回的公鑰對它加密
• 客戶端會發起HTTPS中的第二個HTTP請求，將加密以後的客戶端密鑰發送給服務器。
• 服務器接收到客戶端發來的密文以後，會用本身的私鑰對其進行非對稱解密，解密以後獲得客戶端密鑰，而後用客戶端密鑰對返回數據進行對稱加密，這樣數據就變成了密文。
• 服務器將加密後的密文返回給客戶端。
• 客戶端收到服務器發返回的密文，用本身的密鑰（客戶端密鑰）對其進行對稱解密，獲得服務器返回的數據。

問題

這個流程看來，彷佛已經完美無缺了呢？可是，若是中間人又來搞事情呢？要是中間人截取公鑰，把公鑰進行篡改呢? 打個比喻，把公鑰比喻你本身的手機號，它是公開的，誰均可以給你打電話。假設你發消息給你朋友，告訴他你的手機號，而後消息被中間人截取修改了，改成110，而後你朋友不知情的狀況下，撥通110，打電話給你。。。

解決方案

爲了不公鑰被篡改，須要引入數字簽名，相似給你的公鑰蓋個章，證實身份用。

數字證書登場

爲了不公鑰被篡改，引入了數字證書，如圖所下：

數字證書構成

• 公鑰和我的信息，通過Hash算法加密，造成消息摘要；將消息摘要拿到擁有公信力的認證中心（CA），用它的私鑰對消息摘要加密，造成數字簽名.
• 公鑰和我的信息、數字簽名共同構成數字證書。

數字證書驗證

• 拿到數字證書以後，用一樣的Hash算法， 先再次生成消息摘要；
• 而後用CA的公鑰對數字簽名解密， 獲得CA建立的消息摘要， 二者對比，就知道有沒有人篡改了。

完整的HTTPS運行流程圖

介紹完數字證書，完整的HTTPS流程千呼萬喚始出來了，如圖：

1. 用戶在瀏覽器裏輸入一個https網址，而後鏈接到server的443端口。
2. 服務器必需要有一套數字證書，能夠本身製做，也能夠向組織申請，區別就是本身頒發的證書須要客戶端驗證經過。這套證書其實就是一對公鑰和私鑰。
3. 服務器將本身的數字證書（含有公鑰）發送給客戶端。
4. 客戶端收到服務器端的數字證書以後，會對其進行檢查，若是不經過，則彈出警告框。若是證書沒問題，則生成一個密鑰（對稱加密），用證書的公鑰對它加密。
5. 客戶端會發起HTTPS中的第二個HTTP請求，將加密以後的客戶端密鑰發送給服務器。
6. 服務器接收到客戶端發來的密文以後，會用本身的私鑰對其進行非對稱解密，解密以後獲得客戶端密鑰，而後用客戶端密鑰對返回數據進行對稱加密，這樣數據就變成了密文。
7. 服務器將加密後的密文返回給客戶端。
8. 客戶端收到服務器發返回的密文，用本身的密鑰（客戶端密鑰）對其進行對稱解密，獲得服務器返回的數據。

總結

1. 對稱加密 效率高，因此最終目的是要使用對稱加密進行客戶端與服務端的通訊。 但客戶端如何告訴服務端要共同使用的密鑰，而不被第三方獲取
2. 因此引入了非對稱加密，客戶端先與服務端創建鏈接，而後服務端保留本身的私鑰，把公鑰返回給客戶端。 但客戶端接收公鑰的過程當中，第三方也能夠截取公鑰，甚至對公鑰進行篡改
3. 因此引入了數字證書，起初服務端在返回給客戶端公鑰的時候，附帶了數字證書。數字證書是使用非對稱加密，切私鑰永遠只保存在CA，且數字證書的造成是可逆的。
4. 因此客戶端在對比服務端的公鑰沒問題後，使用服務端的公鑰非對稱加密 對將要使用的 對稱加密密鑰 加密後，發送給服務端，而後服務端私鑰解密。
5. 至此客戶端、服務端僅彼此得到了對稱加密的密鑰，達成了高效安全傳輸數據的目的。

參考與感謝

• Https原理及流程
• 談談 HTTPS
• 圖解HTTPS
• 一個故事講完https

我的公衆號

• 若是你是個愛學習的好孩子，能夠關注我公衆號，一塊兒學習討論。
• 若是你以爲本文有哪些不正確的地方，能夠評論，也能夠關注我公衆號，私聊我，你們一塊兒學習進步哈。