一、HTTP的缺點

HTTP 主要有這些不足， 例舉如下。

• 通訊使用明文（不加密） ， 內容可能會被竊聽
• 不驗證通訊方的身份， 因此有可能遭遇偽裝
• 無法證明報文的完整性， 所以有可能已遭篡改

這些問題不僅在 HTTP 上出現， 其他未加密的協議中也會存在這類問題。

1.1 通訊使用明文可能會被竊聽

上圖是HTTP基於TCP/IP協議的訪問請求過程。其實，在網際網路中的任何通訊線路上的資料，都有可能被竊取。即使對資料進行了加密，它依舊是可以被擷取竊聽，只是說因為加密，擷取到的資料不一定可以被解密使用。

• 通過加密處理防止竊聽

1. 將通訊加密 HTTP 協議中沒有加密機制， 但可以通過和 SSL（Secure Socket Layer， 安全套接層） 或TLS（Transport Layer Security， 安全層傳輸協議）
   的組合使用，加密 HTTP 的通訊內容。 用 SSL建立安全通訊線路之後， 就可以在這條線路上進行 HTTP通訊了。 與 SSL組合使用的 HTTP 被稱為 HTTPS（HTTPSecure， 超文字傳輸安全協議） 或 HTTP over SSL。
2. 將資料內容加密 HTTP 協議中沒有加密機制， 那麼就對 HTTP 協議傳輸的內容本身加密。 即把HTTP 報文裡所含的內容進行加密處理。在這種情況下， 客戶端需要對 HTTP 報文進行加密處理後再發送請求。

1.2 不驗證通訊方身份可能遭遇偽裝

HTTP 協議中的請求和響應不會對通訊方進行確認。 也就是說存在“伺服器是否就是傳送請求中 URI 真正指定的主機， 返回的響應是否真的返回到實際提出請求的客戶端”等類似問題。

SSL不僅提供加密處理， 而且還使用了一種被稱為證書的手段，可用於確定方。證書由值得信任的第三方機構頒發， 用以證明伺服器和客戶端是實際存在的。 另外， 偽造證書從技術角度來說是異常困難的一件事。 所以只要能夠確認通訊方（伺服器或客戶端） 持有的證書，即可判斷通訊方的真實意圖。

1.3 無法證明報文的完整性，可能已遭篡改

由於 HTTP 協議無法證明通訊的報文完整性，在請求或響應送出之後直到對方接收之前的這段時間內， 即使請求或響應的內容遭到篡改， 也沒有辦法獲悉。換句話說， 沒有任何辦法確認， 發出的請求 / 響應和接收到的請求 / 響應是前後相同的。 雖然有使用 HTTP 協議確定報文完整性的方法， 但事實上並不便捷、 可靠。 其中常用的是MD5 和 SHA-1 等雜湊值校驗的方法，以及用來確認檔案的數字簽名方法。但是，依然無法百分百保證確認結果正確。

二、HTTP+ 加密 + 認證 + 完整性保護 =HTTPS

2.1 HTTPS的結構

HTTPS 並非是應用層的一種新協議。== 只是 HTTP 通訊介面部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security） 協議代替而已。==通常， HTTP 直接和 TCP 通訊。 當使用 SSL時， 則演變成先和 SSL通訊， 再由 SSL和 TCP 通訊了。在採用 SSL後， HTTP 就擁有了 HTTPS 的加密、 證書和完整保護這些功能。

2.2 金鑰加密技術

1. 共享金鑰（對稱金鑰）

加密和解密同用一個金鑰的方式稱為共享金鑰加密（Common keycrypto system） ， 也被叫做對稱金鑰加密。

2. 公開金鑰（非對稱金鑰）

公開金鑰加密使用一對非對稱的金鑰。 一把叫做私有金鑰（private key） ， 另一把叫做公開金鑰（public key） 。 使用公開金鑰加密方式， 傳送密文的一方使用對方的公開金鑰進行加密處理， 對方收到被加密的資訊後， 再使用自己的私有金鑰進行解密。

3. HTTPS採用混合加密機制

2.3 證明公開金鑰正確性的證書

公開金鑰加密方式存在一個問題， 那就是無法證明公開金鑰本身就是貨真價實的公開金鑰。 可以使用由數字證書認證機構（CA， Certificate Authority） 和其相關機關頒發的公開金鑰證書。

數字證書認證機構處於客戶端與伺服器雙方都可信賴的第三方機構的立場上。

• 數字證書認證機構的業務流程： 1、伺服器的運營人員向數字證書認證機構提出公開金鑰的申請。 2、數字證書認證機構在判明提出申請者的身份之後， 會對已申請的公開金鑰做數字簽名， 然後分配這個已簽名的公開金鑰， 並將該公開金鑰放入公鑰證書後繫結在一起。

• 數字證書使用流程： 1、伺服器會將數字證書認證機構頒發的公鑰證書傳送給客戶端以進行公開金鑰加密方式通訊。 公鑰證書也可叫做數字證書或直接稱為證書。 2、接到證書的客戶端可使用數字證書認證機構的公開金鑰， 對那張證書上的數字簽名進行驗證， 一旦驗證通過， 客戶端便可明確兩件事：①認證伺服器的公開金鑰的是真實有效的數字證書認證機構。 ②伺服器的公開金鑰是值得信賴的。

三、HTTPS的安全通訊機制

具體步驟如下：

1. 客戶端通過傳送 Client Hello 報文開始 SSL通訊。 報文中包含客戶端支援的 SSL的指定版本、 加密元件（Cipher Suite） 列表（所使用的加密演算法及金鑰長度等） 。

2. 伺服器可進行 SSL通訊時， 會以 Server Hello 報文作為應答。 和客戶端一樣， 在報文中包含 SSL版本以及加密元件。 伺服器的加密元件內容是從接收到的客戶端加密元件內篩選出來的。
3. 之後伺服器傳送 Certificate 報文。 報文中包含公開金鑰證書。
4. 最後伺服器傳送 Server Hello Done 報文通知客戶端， 最初階段的 SSL握手協商部分結束。

5. SSL第一次握手結束之後， 客戶端以 Client Key Exchange 報文作為迴應。 報文中包含通訊加密中使用的一種被稱為 Pre-master secret 的隨機密碼串。 該報文已用步驟 3 中的公開金鑰進行加密。
6. 接著客戶端繼續傳送 Change Cipher Spec 報文。 該報文會提示伺服器， 在此報文之後的通訊會採用 Pre-master secret 金鑰加密。
7. 客戶端傳送 Finished 報文。 該報文包含連線至今全部報文的整體校驗值。 這次握手協商是否能夠成功， 要以伺服器是否能夠正確解密該報文作為判定標準。

8. 伺服器同樣傳送 Change Cipher Spec 報文。
9. 伺服器同樣傳送 Finished 報文。

10. 伺服器和客戶端的 Finished 報文交換完畢之後， SSL連線就算建立完成。 當然， 通訊會受到 SSL的保護。 從此處開始進行應用層協議的通訊， 即傳送 HTTP 請求。

11. 應用層協議通訊， 即傳送 HTTP 響應。

12. 最後由客戶端斷開連線。 斷開連線時， 傳送 close_notify 報文。 上圖做了一些省略， 這步之後再發送 TCP FIN 報文來關閉與 TCP的通訊。

SST 和 TLS

使用 SSL時， 它的處理速度會變慢。SSL的慢分兩種。 一種是指通訊慢。 另一種是指由於大量消耗CPU 及記憶體等資源， 導致處理速度變慢。 ------ 針對速度變慢這一問題， 並沒有根本性的解決方案， 我們會使用SSL加速器這種（專用伺服器）硬體來改善該問題。 該硬體為SSL通訊專用硬體， 相對軟體來講， 能夠提高數倍 SSL的計算速度。 僅在 SSL處理時發揮 SSL加速器的功效， 以分擔負載。