HTTP和HTTPS協議 （精華篇）

一、前言：

 

先來觀察這兩張圖，第一張訪問域名http://www.12306.cn，谷歌瀏覽器提示不安全鏈接，第二張是https://kyfw.12306.cn/otn/regist/init，瀏覽器顯示安全，爲什麼會這樣子呢？

 

2017年1月發佈的Chrome 56瀏覽器開始把收集密碼或信用卡數據的HTTP頁面標記爲“不安全”，

若用戶使用2017年10月推出的Chrome 62，帶有輸入數據的HTTP頁面和所有以無痕模式瀏覽的HTTP頁面都會被標記爲“不安全”，

此外，蘋果公司強制所有iOS App在2017年1月1日前使用HTTPS加密。

 

二、HTTP和HTTPS發展歷史

什麼是HTTP?

超文本傳輸協議，是一個基於請求與響應，無狀態的，應用層的協議，常基於TCP/IP協議傳輸數據，互聯網上應用最爲廣泛的一種網絡協議,所有的WWW文件都必須遵守這個標準。設計HTTP的初衷是爲了提供一種發佈和接收HTML頁面的方法。

 

發展歷史：

 

 

這個Akamai公司建立的一個官方的演示，使用HTTP/1.1和HTTP/2同時請求379張圖片，觀察請求的時間，明顯看出HTTP/2性能佔優勢。

HTTP/1.1 和HTTP/2 圖示對比

 

多路複用：通過單一的HTTP/2連接請求發起多重的請求-響應消息，多個請求stream共享一個TCP連接，實現多留並行而不是依賴建立多個TCP連接。

 

HTTP報文格式

 

 

什麼是HTTPS？

《圖解HTTP》這本書中曾提過HTTPS是身披SSL外殼的HTTP。HTTPS是一種通過計算機網絡進行安全通信的傳輸協議，經由HTTP進行通信，利用SSL/TLS建立全信道，加密數據包。HTTPS使用的主要目的是提供對網站服務器的身份認證，同時保護交換數據的隱私與完整性。

 

PS:TLS是傳輸層加密協議，前身是SSL協議，由網景公司1995年發佈，有時候兩者不區分。

 

參考連接：

1.https://kamranahmed.info/blog/2016/08/13/http-in-depth/

 

2.https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

 

3.https://tools.ietf.org/html/rfc1945

 

4.https://http2.github.io/http2-spec/

 

5.https://www.zhihu.com/question/34074946

 

三、HTTP VS HTTPS

HTTP特點：

1. 無狀態：協議對客戶端沒有狀態存儲，對事物處理沒有“記憶”能力，比如訪問一個網站需要反覆進行登錄操作
2. 無連接：HTTP/1.1之前，由於無狀態特點，每次請求需要通過TCP三次握手四次揮手，和服務器重新建立連接。比如某個客戶機在短時間多次請求同一個資源，服務器並不能區別是否已經響應過用戶的請求，所以每次需要重新響應請求，需要耗費不必要的時間和流量。
3. 基於請求和響應：基本的特性，由客戶端發起請求，服務端響應
4. 簡單快速、靈活
5. 通信使用明文、請求和響應不會對通信方進行確認、無法保護數據的完整性

 

下面通過一個簡單的抓包實驗觀察使用HTTP請求傳輸的數據：

 

 

 

結果分析：HTTP協議傳輸數據以明文形式顯示

針對無狀態的一些解決策略：

場景：逛電商商場用戶需要使用的時間比較長，需要對用戶一段時間的HTTP通信狀態進行保存，比如執行一次登陸操作，在30分鐘內所有的請求都不需要再次登陸。

 

1. 通過Cookie/Session技術
2. HTTP/1.1持久連接（HTTP keep-alive）方法，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態，在請求首部字段中的Connection: keep-alive即爲表明使用了持久連接

 

HTTPS特點：

基於HTTP協議，通過SSL或TLS提供加密處理數據、驗證對方身份以及數據完整性保護

 

 

通過抓包可以看到數據不是明文傳輸，而且HTTPS有如下特點：

1. 內容加密：採用混合加密技術，中間者無法直接查看明文內容
2. 驗證身份：通過證書認證客戶端訪問的是自己的服務器
3. 保護數據完整性：防止傳輸的內容被中間人冒充或者篡改

 

**混合加密：**結合非對稱加密和對稱加密技術。

客戶端使用對稱加密生成密鑰對傳輸數據進行加密，然後使用非對稱加密的公鑰再對祕鑰進行加密，所以網絡上傳輸的數據是被祕鑰加密的密文和用公鑰加密後的祕密祕鑰，因此即使被黑客截取，由於沒有私鑰，無法獲取到加密明文的祕鑰，便無法獲取到明文數據。

 

 

**數字摘要：**通過單向hash函數對原文進行哈希，將需加密的明文“摘要”成一串固定長度(如128bit)的密文，不同的明文摘要成的密文其結果總是不相同，同樣的明文其摘要必定一致，並且即使知道了摘要也不能反推出明文。

 

 

**數字簽名技術：**數字簽名建立在公鑰加密體制基礎上，是公鑰加密技術的另一類應用。它把公鑰加密技術和數字摘要結合起來，形成了實用的數字簽名技術。

 

1. 收方能夠證實發送方的真實身份；
2. 發送方事後不能否認所發送過的報文；
3. 收方或非法者不能僞造、篡改報文。

 

 

非對稱加密過程需要用到公鑰進行加密，那麼公鑰從何而來？

其實公鑰就被包含在數字證書中，數字證書通常來說是由受信任的數字證書頒發機構CA，在驗證服務器身份後頒發，證書中包含了一個密鑰對（公鑰和私鑰）和所有者識別信息。

數字證書被放到服務端，具有服務器身份驗證和數據傳輸加密功能。

 

四、HTTP通信傳輸

 

客戶端輸入URL回車，DNS解析域名得到服務器的IP地址，服務器在80端口監聽客戶端請求，端口通過TCP/IP協議（可以通過Socket實現）建立連接。

 

HTTP屬於TCP/IP模型中的應用層協議，所以通信的過程其實是對應數據的入棧和出棧。

 

 

報文從應用層傳送到傳輸層，傳輸層通過TCP三次握手和服務器建立連接，四次揮手釋放連接。

 

 

爲什麼需要三次握手呢？

爲了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。

 

比如：client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間纔到達server。

本來這是一個早已失效的報文段，但是server收到此失效的連接請求報文段後，就誤認爲是client再次發出的一個新的連接請求，於是就向client發出確認報文段，同意建立連接。

假設不採用“三次握手”，那麼只要server發出確認，新的連接就建立了，由於client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據，但server卻以爲新的運輸連接已經建立，並一直等待client發來數據。

所以沒有采用“三次握手”，這種情況下server的很多資源就白白浪費掉了。

 

 

爲什麼需要四次揮手呢？

TCP是全雙工模式，當client發出FIN報文段時，只是表示client已經沒有數據要發送了，client告訴server，它的數據已經全部發送完畢了；

但是，這個時候client還是可以接受來server的數據；當server返回ACK報文段時，表示它已經知道client沒有數據發送了，但是server還是可以發送數據到client的；

當server也發送了FIN報文段時，這個時候就表示server也沒有數據要發送了，就會告訴client，我也沒有數據要發送了，如果收到client確認報文段，之後彼此就會愉快的中斷這次TCP連接。

 

五、HTTPS實現原理

SSL建立連接過程

 

 

1. client向server發送請求https://baidu.com，然後連接到server的443端口，發送的信息主要是隨機值1和客戶端支持的加密算法。
2. server接收到信息之後給予client響應握手信息，包括隨機值2和匹配好的協商加密算法，這個加密算法一定是client發送給server加密算法的子集。
3. 隨即server給client發送第二個響應報文是數字證書。服務端必須要有一套數字證書，可以自己製作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，纔可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面，這套證書其實就是一對公鑰和私鑰。傳送證書，這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發機構，過期時間、服務端的公鑰，第三方證書認證機構(CA)的簽名，服務端的域名信息等內容。
4. 客戶端解析證書，這部分工作是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨即值（預主祕鑰）。
5. 客戶端認證證書通過之後，接下來是通過隨機值1、隨機值2和預主祕鑰組裝會話祕鑰。然後通過證書的公鑰加密會話祕鑰。
6. 傳送加密信息，這部分傳送的是用證書加密後的會話祕鑰，目的就是讓服務端使用祕鑰解密得到隨機值1、隨機值2和預主祕鑰。
7. 服務端解密得到隨機值1、隨機值2和預主祕鑰，然後組裝會話祕鑰，跟客戶端會話祕鑰相同。
8. 客戶端通過會話祕鑰加密一條消息發送給服務端，主要驗證服務端是否正常接受客戶端加密的消息。
9. 同樣服務端也會通過會話祕鑰加密一條消息回傳給客戶端，如果客戶端能夠正常接受的話表明SSL層連接建立完成了。

問題：

1. 怎麼保證保證服務器給客戶端下發的公鑰是真正的公鑰，而不是中間人僞造的公鑰呢？

 

 

 

1. 證書如何安全傳輸，被掉包了怎麼辦？

 

 

數字證書內容

包括了加密後服務器的公鑰、權威機構的信息、服務器域名，還有經過CA私鑰簽名之後的證書內容（經過先通過Hash函數計算得到證書數字摘要，然後用權威機構私鑰加密數字摘要得到數字簽名)，簽名計算方法以及證書對應的域名。

 

驗證證書安全性過程

 

1. 當客戶端收到這個證書之後，使用本地配置的權威機構的公鑰對證書進行解密得到服務端的公鑰和證書的數字簽名，數字簽名經過CA公鑰解密得到證書信息摘要。
2. 然後證書籤名的方法計算一下當前證書的信息摘要，與收到的信息摘要作對比，如果一樣，表示證書一定是服務器下發的，沒有被中間人篡改過。因爲中間人雖然有權威機構的公鑰，能夠解析證書內容並篡改，但是篡改完成之後中間人需要將證書重新加密，但是中間人沒有權威機構的私鑰，無法加密，強行加密只會導致客戶端無法解密，如果中間人強行亂修改證書，就會導致證書內容和證書籤名不匹配。

那第三方攻擊者能否讓自己的證書顯示出來的信息也是服務端呢？（僞裝服務端一樣的配置）顯然這個是不行的，因爲當第三方攻擊者去CA那邊尋求認證的時候CA會要求其提供例如域名的whois信息、域名管理郵箱等證明你是服務端域名的擁有者，而第三方攻擊者是無法提供這些信息所以他就是無法騙CA他擁有屬於服務端的域名。

 

六、運用與總結

安全性考慮：

1. HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼作用
2. SSL證書的信用鏈體系並不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行

 

中間人攻擊（MITM攻擊）是指，黑客攔截並篡改網絡中的通信數據。又分爲被動MITM和主動MITM，被動MITM只竊取通信數據而不修改，而主動MITM不但能竊取數據，還會篡改通信數據。最常見的中間人攻擊常常發生在公共wifi或者公共路由上。

 

成本考慮：

1. SSL證書需要購買申請，功能越強大的證書費用越高
2. SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、操作系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。
3. 根據ACM CoNEXT數據顯示，使用HTTPS協議會使頁面的加載時間延長近50%，增加10%到20%的耗電。
4. HTTPS連接緩存不如HTTP高效，流量成本高。
5. HTTPS連接服務器端資源佔用高很多，支持訪客多的網站需要投入更大的成本。
6. HTTPS協議握手階段比較費時，對網站的響應速度有影響，影響用戶體驗。比較好的方式是採用分而治之，類似12306網站的主頁使用HTTP協議，有關於用戶信息等方面使用HTTPS。