大綱
一、前言：
先來觀察這兩張圖，第一張訪問域名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頁面的方法。
發展歷史：
| 版本 | 產生時間 | 內容 | 發展現狀 |
|---|---|---|---|
| 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
三、HTTP VS HTTPS
HTTP特點：
- 無狀態：協議對客戶端沒有狀態存儲，對事物處理沒有“記憶”能力，比如訪問一個網站需要反復進行登錄操作
- 無連接：HTTP/1.1之前，由於無狀態特點，每次請求需要通過TCP三次握手四次揮手，和服務器重新建立連接。比如某個客戶機在短時間多次請求同一個資源，服務器並不能區別是否已經響應過用戶的請求，所以每次需要重新響應請求，需要耗費不必要的時間和流量。
- 基於請求和響應：基本的特性，由客戶端發起請求，服務端響應
- 簡單快速、靈活
- 通信使用明文、請求和響應不會對通信方進行確認、無法保護數據的完整性
下面通過一個簡單的抓包實驗觀察使用HTTP請求傳輸的數據：
結果分析：HTTP協議傳輸數據以明文形式顯示
針對無狀態的一些解決策略：
場景：逛電商商場用戶需要使用的時間比較長，需要對用戶一段時間的HTTP通信狀態進行保存，比如執行一次登陸操作，在30分鍾內所有的請求都不需要再次登陸。
- 通過Cookie/Session技術
- HTTP/1.1持久連接（HTTP keep-alive）方法，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態，在請求首部字段中的Connection: keep-alive即為表明使用了持久連接
HTTPS特點：
基於HTTP協議，通過SSL或TLS提供加密處理數據、驗證對方身份以及數據完整性保護
通過抓包可以看到數據不是明文傳輸，而且HTTPS有如下特點：
- 內容加密：采用混合加密技術，中間者無法直接查看明文內容
- 驗證身份：通過證書認證客戶端訪問的是自己的服務器
- 保護數據完整性：防止傳輸的內容被中間人冒充或者篡改
混合加密：結合非對稱加密和對稱加密技術。客戶端使用對稱加密生成密鑰對傳輸數據進行加密，然后使用非對稱加密的公鑰再對秘鑰進行加密，所以網絡上傳輸的數據是被秘鑰加密的密文和用公鑰加密后的秘密秘鑰，因此即使被黑客截取，由於沒有私鑰，無法獲取到加密明文的秘鑰，便無法獲取到明文數據。
數字摘要：通過單向hash函數對原文進行哈希，將需加密的明文“摘要”成一串固定長度(如128bit)的密文，不同的明文摘要成的密文其結果總是不相同，同樣的明文其摘要必定一致，並且即使知道了摘要也不能反推出明文。
數字簽名技術：數字簽名建立在公鑰加密體制基礎上，是公鑰加密技術的另一類應用。它把公鑰加密技術和數字摘要結合起來，形成了實用的數字簽名技術。
- 收方能夠證實發送方的真實身份；
- 發送方事后不能否認所發送過的報文；
- 收方或非法者不能偽造、篡改報文。
非對稱加密過程需要用到公鑰進行加密，那么公鑰從何而來？其實公鑰就被包含在數字證書中，數字證書通常來說是由受信任的數字證書頒發機構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實現原理
-
client向server發送請求https://baidu.com，然后連接到server的443端口。
-
服務端必須要有一套數字證書，可以自己制作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面，這套證書其實就是一對公鑰和私鑰。
-
傳送證書
這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發機構，過期時間、服務端的公鑰，第三方證書認證機構(CA)的簽名，服務端的域名信息等內容。 -
客戶端解析證書
這部分工作是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨即值（秘鑰）。然后用證書對該隨機值進行加密。 -
傳送加密信息
這部分傳送的是用證書加密后的秘鑰，目的就是讓服務端得到這個秘鑰，以后客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。 -
服務段加密信息
服務端用私鑰解密秘密秘鑰，得到了客戶端傳過來的私鑰，然后把內容通過該值進行對稱加密。 -
傳輸加密后的信息
這部分信息是服務端用私鑰加密后的信息，可以在客戶端被還原。 -
客戶端解密信息
客戶端用之前生成的私鑰解密服務端傳過來的信息，於是獲取了解密后的內容。
問題：
1.怎么保證保證服務器給客戶端下發的公鑰是真正的公鑰，而不是中間人偽造的公鑰呢？
2.證書如何安全傳輸，被掉包了怎么辦？
- 數字證書包括了加密后服務器的公鑰、權威機構的信息、服務器域名，還有經過CA私鑰簽名之后的證書內容（經過先通過Hash函數計算得到證書數字摘要，然后用權威機構私鑰加密數字摘要得到數字簽名)，簽名計算方法以及證書對應的域名。當客戶端收到這個證書之后，使用本地配置的權威機構的公鑰對證書進行解密得到服務端的公鑰和證書的數字簽名，數字簽名經過CA公鑰解密得到證書信息摘要，然后根據證書上描述的計算證書的方法計算一下當前證書的信息摘要，與收到的信息摘要作對比，如果一樣，表示證書一定是服務器下發的，沒有被中間人篡改過。因為中間人雖然有權威機構的公鑰，能夠解析證書內容並篡改，但是篡改完成之后中間人需要將證書重新加密，但是中間人沒有權威機構的私鑰，無法加密，強行加密只會導致客戶端無法解密，如果中間人強行亂修改證書，就會導致證書內容和證書簽名不匹配。
- 那第三方攻擊者能否讓自己的證書顯示出來的信息也是服務端呢？（偽裝服務端一樣的配置）顯然這個是不行的，因為當第三方攻擊者去CA那邊尋求認證的時候CA會要求其提供例如域名的whois信息、域名管理郵箱等證明你是服務端域名的擁有者，而第三方攻擊者是無法提供這些信息所以他就是無法騙CA他擁有屬於服務端的域名
六、運用與總結
安全性考慮：
- HTTPS協議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用
- SSL證書的信用鏈體系並不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行
中間人攻擊（MITM攻擊）是指，黑客攔截並篡改網絡中的通信數據。又分為被動MITM和主動MITM，被動MITM只竊取通信數據而不修改，而主動MITM不但能竊取數據，還會篡改通信數據。最常見的中間人攻擊常常發生在公共wifi或者公共路由上。
成本考慮：
- SSL證書需要購買申請，功能越強大的證書費用越高
- SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、操作系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。
- 根據ACM CoNEXT數據顯示，使用HTTPS協議會使頁面的加載時間延長近50%，增加10%到20%的耗電。
- HTTPS連接緩存不如HTTP高效，流量成本高。
- HTTPS連接服務器端資源占用高很多，支持訪客多的網站需要投入更大的成本。
- HTTPS協議握手階段比較費時，對網站的響應速度有影響，影響用戶體驗。比較好的方式是采用分而治之，類似12306網站的主頁使用HTTP協議，有關於用戶信息等方面使用HTTPS。