HTTPS 與加密那些事兒

前言

HTTPS 在咱們平常中常常能用到，咱們常常說 HTTPS 安全，那麼你知道它爲何安全嗎？有些同窗會說：是由於加密啊，那麼你知道它是怎麼加密的嗎？

若是你對此不是很明白，歡迎閱讀本文，但願能讓你解開 HTTPS 的迷霧，但若是你是大神級別的人物，那麼請輕噴，由於我也不是很懂。。

HTTP

在說 HTTPS 以前，咱們須要先知道 HTTP，HTTP 是基於 TCP 協議的一個無狀態協議，若是你不是很懂歡迎閱讀我上一篇文章，在瀏覽器輸入 URL 回車以後發生了什麼，此文講解了一個 HTTP 請求的過程。

缺點：

1. 使用明文進行傳輸，內容可能被竊聽
2. 不驗證通訊方的身份，通訊方的身份多是假裝
3. 沒法證實報文的完整性，報文有可能被篡改

HTTPS

HTTPS 並非一個新協議，而是 HTTP 先和 http://www.javashuo.com/tag/SSL/TLS，再由 SSL/TLS 和 TCP 通訊。也就是說 HTTPS 使用了隧道進行通訊。

爲何不直接對 HTTP 報文進行加密，而是多加一層 SSL/TLS 呢？由於 HTTP 報文分爲報文首部和報文主體，若是隻對發送內容進行加密（也就是報文主體），而未加密的報文首部信息也會致使信息不安全。

在開始講以前咱們須要介紹一下加密算法。

加密算法

加密算法的實現原理是公開的，讀者可能以爲這觀點很奇怪，不少開發者喜歡設計千奇百怪的算法，竊覺得別人並不知道，其實自行設計的算法根本不具有嚴格的數學模型，很容易被攻破。流行的密碼學算法其算法實現是公開的，通過了長時間的考驗。

對稱加密

簡單來講就是加密和解密都是經過同一個密鑰，好比我要傳輸的明文是 5201314，我在傳輸前將明文的全部數字+1，獲得：6302425，而後接收方根據相同的密鑰將密文進行解密，獲得明文。

通常的對稱加密算法是使用 XOR（異或） 這個特色，例如：

var a = 5201314 // 明文
var b = 123456 // 密鑰
var c = a ^ b // 加密 
var d = c ^ b // 解密 => 5201314 
複製代碼

若是對按位操做符感興趣能夠閱讀我以前的文章：深刻理解按位操做符

一次性加密

上面這個例子就是一次性加密，在不知道密鑰的狀況下，理論上是沒法破解，由於即使你遍歷了全部狀況，但因爲你不肯定破譯出來的是否是原文，因此這就是它沒法破解的緣由。這個理論是香農(C.E.Shannon)於 1949 年經過數學方法加以證實的。

DES 加密

DES 是 1977年美國聯邦信息處理標準中採用的一種對稱加密算法，可是在 1998 年已經被成功破解，耗時牢牢22小時，目前再也不推薦使用。

它是一種把 64 位明文加密成 64 位密文的對稱加密算法，也就是一次性只能加密 64 位，若是超過了 64 位，就須要進行分組加密。

對稱加密還有不少種，想要了解更多能夠查看這篇文章：漫遊對稱加密算法

對稱加密的缺點

不管對稱加密算法再怎麼複雜，它們都有一個共同的弱點，就是

• 如何傳輸密鑰

若是咱們要和接收方進行通訊，咱們須要提早協商好一個密鑰，那麼這個如何才能保證密鑰能安全地送達，而不會落到中間人手中？

天然是將密鑰進行加密，但如何依然使用對稱加密，那是否是又須要另一個密鑰？因此這就陷入死循環了。

這時候就要介紹密碼學上偉大的發明：RSA（公鑰私鑰密碼算法），也就是非對稱加密算法。

非對稱加密算法

1977年，三位數學家Rivest、Shamir 和 Adleman 設計了一種算法，能夠實現非對稱加密。這種算法用他們三我的的名字命名，叫作RSA算法。

非對稱加密有公鑰和私鑰，也就是私鑰加密的密文只有公鑰才能解密，公鑰加密的密文只有私鑰才能解密。

關於原理部分我認爲阮一峯老師的這篇文章RSA算法原理已經講得很通俗易懂了，這裏再也不贅述。

非對稱加密的缺點

非對稱加密雖然安全，至今都沒法被破解，但也不是徹底沒有缺點的，一個比較顯著的缺點就是加密時須要通過大量的計算，消耗計算機資源。

HTTPS 採用的加密方式

對稱加密特色：

• 優勢：運算速度快
• 缺點：密鑰容易被獲取

非對稱加密特色：

• 優勢：更安全
• 缺點：運算速度慢

很明顯，若是 HTTPS 採用非對稱加密的話，會消耗大量的計算資源，那麼有沒有一種方式能夠解決這個問題呢？有的。

咱們知道對稱加密的缺點就是密鑰的分發問題，既然這樣，咱們可使用非對稱加密對密鑰進行加密，保證只有通訊雙方知道密鑰後，接着就可使用對稱加密進行通訊。

認證

但依然存在一個很嚴重的問題就是：公鑰如何分發？

由於客戶端沒法確認公鑰是來自服務器仍是來自中間人，因此須要一個客戶端和服務器雙方都信賴的第三方機構，配分配公鑰，這個機構就叫作 數字證書認證機構（CA，Certificate Authority）。

進行 HTTPS 通訊時，服務器會把證書發送給客戶端，客戶端取得其中的公開密鑰以後，先進行驗證，若是驗證經過，就能夠開始通訊。

但依然存在問題：證書怎麼安全傳輸？ 被篡改了怎麼辦？

使用數字簽名就行了，簡單來講就是將公鑰和我的信息用一個 Hash 算法生成一個信息摘要。咱們知道 Hash 算法有個極好的特徵，只要輸入的數據有一點點變化，那生成的信息摘要就會發生鉅變，這樣就能夠防止別人修改原始內容。

但還有個問題就是，如何防止別人冒充 CA？

若是連 CA 都沒法信任的話，那麼以前的一切都是徒勞的，因此必須打破僵局，咱們必須信任 CA。

CA 是像樹同樣分級的，在操做系統/瀏覽器中都會內置一些頂層的 CA 證書，而這些頂層 CA 會爲上層的 CA 作信用背書。

說到底其實咱們相信的是操做系統/瀏覽器，若是中間人連這個均可以假裝，那麼咱們就沒有安全可言了。

HTTPS 中的 TLS / SSL 協議

能讓 HTTPS 帶來安全性的是其背後的 TLS 協議。它源於九十年代中期在 Netscape 上開發的稱爲安全套接字層(SSL)的協議。到 20 世紀 90 年代末，Netscape 將 SSL 移交給了 IETF，IETF 將其重命名爲 TLS，並今後成爲該協議的管理者。許多人仍將 Web 加密稱做 SSL，即便絕大多數服務已切換到僅支持 TLS。

TLS/SSL 協議位於應用層和傳輸層 TCP 協議之間，注意 TLS/SSL 並非只有 HTTP 才能使用，而是位於應用層的協議均可以使用，換句話說 TLS/SSL 協議 是用於加密應用層協議並傳遞給下層的 TCP。

TLS 粗略的劃分又能夠分爲 2 層：

• 靠近應用層的握手協議 TLS Handshaking Protocols
• 靠近 TCP 的記錄層協議 TLS Record Protocol

TLS 握手協議還能細分爲 5 個子協議：

• change_cipher_spec (在 TLS 1.3 中這個協議已經刪除，爲了兼容 TLS 老版本，可能還會存在)
• alert
• handshake
• application_data
• heartbeat (這個是 TLS 1.3 新加的，TLS 1.3 以前的版本沒有這個協議)

TLS/SSL 能夠查看如下流程：

握手失敗

瀏覽器訪問 HTTPS 網站的時候，在握手階段可能會存在錯誤，好比證書的有效期過時、證書是自簽名證書、客戶端和服務器沒法協商出一致的密碼套件，遇到相似的狀況，瀏覽器會出現一個錯誤頁面，告知用戶存在的問題。

通常握手失敗時，瀏覽器會直接告訴用戶該網站不安全。

其實 TLS / SSL 協議的原理是很複雜的，如何感興趣能夠看一下《深刻淺出 HTTPS》這本書。

參考文獻

• 《深刻淺出 HTTPS》
• HTTPS 溫故知新
• 漫遊對稱加密算法