簡述 HTTPS 的通信機制

原標題：簡述 HTTPS 的通信機制

本文轉載於SegmentFault社區

作者：WillemWei

HTTPS是什麼？

HTTPS = HTTP + 加密 + 認證 + 完整性保護。簡單點說HTTPS可以看做是對HTTP的一個擴展，在HTTP的基礎上添加了一些其他的東西。加密、認證和完整性保護，添加這麼些東西就很明顯是為了保證數據的安全性。

HTTP的不足：

1. 通信使用明文（未加密），內容可能會被竊聽

2. 沒有驗證通信方的身份，可能遭遇偽裝

3. 無法證明報文的完整性，可能會被篡改

HTTPS的作用便是為了解決上述問題。HTTPS並不是一個新的協議，只是HTTP披了一層SSL或TLS的馬甲。在四層模型中，HTTP位於應用層，是直接和傳輸層的TCP進行通信。當使用了SSL之後，則是HTTP和SSL通信，然後SSL再和TCP進行通信。

註：TLS實際上是以SSL3.0為基準制定的。當前主流版本是SSL3.0和TLS1.0。

關於SSL的加密方式

HTTPS相對於HTTP最重要的一點則是在對於數據的加密解密上。

共享秘鑰加密（對稱加密）

加密和解密使用同一個秘鑰的方式被稱為共享秘鑰加密。以這種方式加密時必須將秘鑰也發給對方，在複雜的網絡上傳輸秘鑰時，如果通信被監聽，秘鑰就很可能會落入到攻擊者的手中，加密便失去了意義。

公開秘鑰加密（非對稱加密）

公開秘鑰加密使用的是一對非對稱的秘鑰，一個叫做公開秘鑰，一個叫做私有秘鑰。顧名思義，任何人都可以得到公開秘鑰，而私有秘鑰則不能讓其他人知道。

使用公開秘鑰加密的方式，由發送方使用公鑰對信息進行加密，接收方則使用私鑰進行解密。使用這種方式則不需要擔心秘鑰被攻擊者盜走。

HTTPS採用的是混合的方式

公開秘鑰加密方式由於更加複雜，因此在通信是使用公開秘鑰加密的方式則效率相對來說會很低，而共享秘鑰加密的效率會很高，但卻不能讓秘鑰安全的進行交換。

所以應該充分利用兩者的優勢，使用公開秘鑰加密傳輸共享秘鑰加密使用的秘鑰，然後使用共享加密進行通信。

但還存在一個問題：不能保證公開密鑰本身就是有效的。為了解決這個問題，數字證書認證機構（CA）粉墨登場。

1. 伺服器運營人員會向CA提出公開秘鑰的申請，CA在判明申請者的神風之後，會對申請的公開秘鑰進行數字簽名並將其放入公鑰證書中

2. 伺服器會將公鑰證書放鬆給客戶端

3. 客戶端使用公鑰證書的公開秘鑰（一般內置在瀏覽器中）對證書進行驗證

4. 驗證通過後，客戶端便拿到了公開秘鑰加密中的公開秘鑰

HTTPS的通信過程

上面說了那麼多，再看看這張圖。有沒有感覺像是一個套娃的過程。

使用共享秘鑰加密，則需要交換秘鑰 => 使用公開秘鑰加密交換秘鑰，則需要交換公開密鑰 => CA認證，發送公開秘鑰證書 => 驗證有效性，取出公開秘鑰，對生成的秘鑰（隨機字符串）進行加密發送給伺服器 => 伺服器利用私有秘鑰解密出秘鑰 => 開始通信

為什麼不一直使用HTTPS？

• 由於存在加密過程和額外的SSL通信，處理速度會變慢

• AC認證需要花費增加額外的開銷

• 加密通信會消耗伺服器和客戶端更多的CPU和內存

參考：《HTTP圖解》