圖解 HTTP 筆記（七）——HTTPS

本章主要講解 HTTPS 的基本原理，以及如何利用 HTTPS 防範 HTTP 通訊過程當中存在的假裝、竊聽、篡改等問題

1、HTTP 的缺點

HTTP 在通訊過程當中會面臨如下三種安全問題：

• 通訊使用明文（不加密），內容可能會被竊聽。
• 不驗證通訊方的身份，可能會遭遇假裝。
• 沒法驗證報文的完整性，可能已經被篡改。

1.1 竊聽

HTTP 自己不具有加密功能，因此傳輸過程當中都是以明文方式發送。

因爲在網絡的傳輸過程當中，咱們所發送的信息要通過許多的網絡節點和設備，在這個過程當中這些設備是可能會攔截咱們的信息而且進行竊聽的，直接經過一些經常使用的抓包工具就能夠竊聽未加密的網絡傳輸信息。

經過加密防止竊聽

（一）通訊的加密：爲了防止傳輸內容被竊聽，咱們採起的方式之一就是通訊加密，HTTP 自己沒有加密機制，可是咱們能夠經過將 HTTP 和 SSL（Secure Socket Layer 安全套接層）或者 TLS（Transport Layer Security 安全傳輸協議）組合使用來加密 HTTP 傳輸內容。

用 SSL 創建安全通訊線路之後，就能夠在這條線路上進行 HTTP 通訊了。與 SSL 組合使用的 HTTP 被稱爲 HTTPS（HTTP Secure）。

（二）內容的加密：還有一種方式就是將參與通訊的內容自己進行加密。這樣的話就須要客戶端對 HTTP 報文加密後再進行請求發送。因爲該方式不一樣於 HTTPS 將整個通訊線路加密的方式，因此內容仍然會有被篡改的風險。

1.2 假裝

HTTP 協議自己並不會對通訊的另外一方進行身份驗證，因此任何人都能對服務器發起請求。

不驗證通訊方可能就會存在各類安全隱患：

• 客戶端沒法確認本身的請求是否發送到了目標服務器或者返回響應的服務器是不是目標服務器，有多是假裝了的服務器。
• 服務器沒法確認向本身發起請求的客戶端以及本身返回響應的客戶端是不是目標中的客戶端。
• 沒法確認通訊方是否具有訪問權限，由於某些服務器只想給特定的用戶訪問。
• 即便是無心義的請求也會照單全收，使得服務器可能遭受到 DDoS 攻擊。

經過查明對方證書來防止假裝

SSL 不只提供加密處理，並且使用了一種稱爲證書的手段，可用於確認對方身份。

證書由第三方機構頒發，用以證實服務器和客戶端是實際存在的。

經過使用證書能夠證實通訊方就是意料中的服務器。對使用者而言，也減小了我的信息泄露的風險。

另外，客戶端持有證書便可完成我的身份的認證，也可用於對網站的認證環節。

1.3 篡改

HTTP 協議一般沒法確認信息的完整性，一旦傳輸的信息被篡改，那麼信息就失去了準確性，致使信息有誤。好比你想在某個網站下載一個資源，而你的網絡傳輸已經被別人所劫持，在你發起下載請求的時候，你所接收到的資源正在被人修改，因此你下載到的資源就不是你想要的那個了。

像這樣，請求或者響應在傳輸途中遭攻擊者攔截並篡改內容的攻擊稱爲中間人攻擊（Man-in-the-Middle attack, MITM）。

如何防止篡改

以前的章節有提到過 Content-MD5 實體首部字段可用於確認實體內容是否完整，可是因爲 Content-MD5 自己的值也可能被篡改，因此這個字段並不可靠，因此須要其餘方法來確保傳輸的內容不被篡改。

經過其餘散列算法來計算傳輸內容是否完整也不可靠，那麼咱們最終仍是須要 HTTPS 來幫咱們解決這個問題。SSL 提供認證和加密處理以及摘要功能。

2、HTTPS

HTTPS = HTTP + 加密 + 認證 + 摘要
複製代碼

2.1 HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 並不是是應用層的一種新協議。只是 HTTP 通訊接口部分用 SSL 和 TLS 協議代替而已。

一般，HTTP 直接和 TCP 通訊。當使用 SSL 的時候，就先和 SSL 通訊，再由 SSL 和 TCP 通訊了。因此簡而言之，HTTPS 就是身披 SSL 外殼的 HTTP 協議。

在採用 SSL 之後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護功能了。

SSL 協議是獨立於 HTTP 的協議，因此其餘協議也能夠採用 SSL 協議，它是當今世界上應用最普遍的網絡安全技術

2.2 相互交換密鑰的公開密鑰加密技術

在講 SSL 以前能夠先了解一下加密方法，SSL 採用一種叫作公開密鑰加密（Public-key Cryptography）的加密處理技術。

近代的加密方法中，加密算法是公開的，可是密鑰是保密的。加密和解密都會用到密鑰。沒有密鑰就沒法對密鑰進行解密。反過來講，任何人只要拿到了密鑰就能夠解密信息。若是密鑰被攻擊者得到，那加密也就失去了意義。

2.2.1 共享密鑰加密的困境

加密和解密使用同一個密鑰的方式稱爲共享密鑰加密（Common key crypto system），也被叫作對稱密鑰加密。

採用共享密鑰加密方式加密時，須要將密鑰一塊兒發送給通訊方，因此有須要考慮密鑰傳輸的安全性，須要設法安全地保管密鑰，這即是共享密鑰加密方式的困擾。

2.2.2 使用兩把密鑰加密的公開密鑰加密方式

公開密鑰加密方式很好的解決了共享密鑰加密方式的困擾。

公開密鑰加密使用一對非對稱的密鑰。一把叫作私有密鑰（private key），另外一把叫作公開密鑰（public key）。顧名思義，私有密鑰不能被其餘任何人知道，而公開密鑰則能夠仁任意傳播，任何人均可以拿到。

使用公開密鑰加密方式（非對稱加密），發送密文的一方使用公鑰進行加密處理，而接收方拿到被加密後的信息以後再使用本身的私鑰進行解密。利用這種方式進行傳輸，就不須要發送密鑰，也就不用擔憂密鑰被攻擊者拿走了。

2.2.3 HTTPS 採用混合加密機制

HTTPS 採用共享密鑰加密方式和公開密鑰加密方式混用的加密方式。

若是密鑰能夠被安全傳輸，則 HTTPS 會考慮採用共享密鑰加密方式，不然將採用公開密鑰加密方式。這是由於公開密鑰加密方式的速度比共享密鑰加密方式要慢。HTTPS 充分地利用了二者的優勢，將多種方法組合起來用於通訊。在使用公開密鑰加密方式交換密鑰以後，以後的信息傳輸使用共享密鑰加密方式。

2.3 證實公開密鑰正確性的證書

遺憾的是公開密鑰加密方式自己也是有缺陷的，那就是沒法證實公開的密鑰自己是貨真價實的。

爲了解決上面說到的問題，可使用由數字證書認證機構（CA，Certificate Authority）和其相關機構頒發的公開密鑰證書。

數字證書認證機構處於客戶端與服務端雙方都信賴的第三方機構的立場上，威瑞新（VeriSign）就是其中一家很是有名的數字證書認證機構。

下面講解一下數字證書認證機構的業務流程：

首先，服務器的運營人員會向數字機構提出公開密鑰申請，CA 在認證申請者的身份信息以後，會對已申請的公開密鑰進行數字簽名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書以後綁定在一塊兒。

服務器會將這份 CA 頒發的公鑰證書發送給客戶端，以進行公鑰加密方式通訊，公鑰證書也可叫作數字證書或者直接稱爲證書。

接到證書的客戶端可以使用 CA 的公鑰對證書的數字簽名進行認證，一旦驗證經過，客戶端即可確認兩件事：

• 認證服務器公鑰的機構是真實有效的 CA 機構
• 服務器的公鑰是值得信任的

因而這就達到了確認公鑰真實有效性的目的。

安全地轉交 CA 機構的密鑰給客戶端是一件困難的事，所以多數瀏覽器會在內部植入經常使用認證機構的公鑰。

2.3.1 可證實組織真實性的 EV SSL 證書

證書的一個做用是證實做爲通訊一方的服務器是否符合規範，另外一個做用是確認服務器運營商企業是否真實存在。可以證實企業真實性的正式就是 EV SSL 證書（Extended Validation SSL Certificate）。

該證書的目的是爲了防止釣魚攻擊（Phishing）。

2.3.2 用以確認客戶端的客戶端證書

HTTPS 中還可使用客戶端證書對客戶端進行認證。

3、Session 管理及 Cookie 應用

第八章要講的內容很少，因此把最重要的一點挪到了這一篇筆記。

關於用戶身份的認證，如今多數是採用表單認證，通常會採用 Cookie 來管理 Session（會話）。

大體流程以下：

具體步驟以下：

• 客戶端把用戶的 ID 密碼等登陸信息放入報文的實體部分，一般用 POST 方法發送至服務器端。
• 服務器生成併發放用來識別客戶的 Session ID，這個 Session ID 同時會在服務器端保存，而後經過 Set-Cookie 字段綁定到客戶端。順即可以使用 httponly 屬性來禁止 JavaScript 修改 Cookie，防止跨站腳本攻擊。
• 客戶端把 Session ID 保存在本地 Cookie，下次訪問時再帶上。服務器端經過驗證接收到的 Session ID 來識別用戶，從數據庫中能夠順便取到與用戶相關的一系列信息。