HTTP和HTTPS協議，看一篇就夠了

2018年07月19日 14:25:57 不同 閱讀數 42932

 

版權聲明：專屬於不同的博客，轉發請附上博客出處 https://blog.csdn.net/xiaoming100001/article/details/81109617

大綱

1、前言：

先來觀察這兩張圖，第一張訪問域名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加密。

2、HTTP和HTTPS發展歷史

什麼是HTTP?

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

發展歷史：

版本	產生時間	內容	發展示狀
HTTP/0.9	1991年	不涉及數據包傳輸，規定客戶端和服務器之間通訊格式，只能GET請求	沒有做爲正式的標準
HTTP/1.0	1996年	傳輸內容格式不限制，增長PUT、PATCH、HEAD、 OPTIONS、DELETE命令	正式做爲標準
HTTP/1.1	1997年	持久鏈接(長鏈接)、節約帶寬、HOST域、管道機制、分塊傳輸編碼	2015年前使用最普遍
HTTP/2	2015年	多路複用、服務器推送、頭信息壓縮、二進制協議等	逐漸覆蓋市場

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

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

什麼是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

3、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)的密文，不一樣的明文摘要成的密文其結果老是不相同，一樣的明文其摘要一定一致，而且即便知道了摘要也不能反推出明文。

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

• 收方可以證明發送方的真實身份；
• 發送方過後不可否認所發送過的報文；
• 收方或非法者不能僞造、篡改報文。

非對稱加密過程須要用到公鑰進行加密，那麼公鑰從何而來？其實公鑰就被包含在數字證書中，數字證書一般來講是由受信任的數字證書頒發機構CA，在驗證服務器身份後頒發，證書中包含了一個密鑰對（公鑰和私鑰）和全部者識別信息。數字證書被放到服務端，具備服務器身份驗證和數據傳輸加密功能。

4、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鏈接。

5、HTTPS實現原理

1. client向server發送請求https://baidu.com，而後鏈接到server的443端口。

2. 服務端必需要有一套數字證書，能夠本身製做，也能夠向組織申請。區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面，這套證書其實就是一對公鑰和私鑰。

3. 傳送證書
   這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構，過時時間、服務端的公鑰，第三方證書認證機構(CA)的簽名，服務端的域名信息等內容。

4. 客戶端解析證書
   這部分工做是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，好比頒發機構，過時時間等等，若是發現異常，則會彈出一個警告框，提示證書存在問題。若是證書沒有問題，那麼就生成一個隨即值（祕鑰）。而後用證書對該隨機值進行加密。

5. 傳送加密信息
   這部分傳送的是用證書加密後的祕鑰，目的就是讓服務端獲得這個祕鑰，之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。

6. 服務段加密信息
   服務端用私鑰解密祕密祕鑰，獲得了客戶端傳過來的私鑰，而後把內容經過該值進行對稱加密。

7. 傳輸加密後的信息
   這部分信息是服務端用私鑰加密後的信息，能夠在客戶端被還原。

8. 客戶端解密信息
   客戶端用以前生成的私鑰解密服務端傳過來的信息，因而獲取瞭解密後的內容。

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

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

• 數字證書包括了加密後服務器的公鑰、權威機構的信息、服務器域名，還有通過CA私鑰簽名以後的證書內容（通過先經過Hash函數計算獲得證書數字摘要，而後用權威機構私鑰加密數字摘要獲得數字簽名)，簽名計算方法以及證書對應的域名。當客戶端收到這個證書以後，使用本地配置的權威機構的公鑰對證書進行解密獲得服務端的公鑰和證書的數字簽名，數字簽名通過CA公鑰解密獲得證書信息摘要，而後根據證書上描述的計算證書的方法計算一下當前證書的信息摘要，與收到的信息摘要做對比，若是同樣，表示證書必定是服務器下發的，沒有被中間人篡改過。由於中間人雖然有權威機構的公鑰，可以解析證書內容並篡改，可是篡改完成以後中間人須要將證書從新加密，可是中間人沒有權威機構的私鑰，沒法加密，強行加密只會致使客戶端沒法解密，若是中間人強行亂修改證書，就會致使證書內容和證書籤名不匹配。
• 那第三方攻擊者可否讓本身的證書顯示出來的信息也是服務端呢？（假裝服務端同樣的配置）顯然這個是不行的，由於當第三方攻擊者去CA那邊尋求認證的時候CA會要求其提供例如域名的whois信息、域名管理郵箱等證實你是服務端域名的擁有者，而第三方攻擊者是沒法提供這些信息因此他就是沒法騙CA他擁有屬於服務端的域名

6、運用與總結

安全性考慮：

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。