查漏補缺之HTTP及HTTPS

HTTP定義

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

HTTP報文格式

HTTPS定義

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

PS:TLS是傳輸層加密協議，前身是SSL協議，由網景公司1995年發佈，有時候二者不區分。 簡單來講，HTTPS就是HTTP+SSL，加強了安全性。

HTTP 與 HTTPS 特色分析

HTTP特色：

• 無狀態：協議對客戶端沒有狀態存儲，對事物處理沒有「記憶」能力，好比訪問一個網站須要反覆進行登陸操做

• 無鏈接：HTTP/1.1以前，因爲無狀態特色，每次請求須要經過TCP三次握手四次揮手，和服務器從新創建鏈接。好比某個客戶機在短期屢次請求同一個資源，服務器並不能區別是否已經響應過用戶的請求，因此每次須要從新響應請求，須要耗費沒必要要的時間和流量。

• 基於請求和響應：基本的特性，由客戶端發起請求，服務端響應

• 簡單快速、靈活

• 通訊使用明文、請求和響應不會對通訊方進行確認、沒法保護數據的完整性

HTTPS特色：

• 內容加密：採用混合加密技術，中間者沒法直接查看明文內容

• 驗證身份：經過證書認證客戶端訪問的是本身的服務器

• 保護數據完整性：防止傳輸的內容被中間人冒充或者篡改

HTTP通訊原理

客戶端輸入URL回車，DNS解析域名獲得服務器的IP地址，服務器在80端口監聽客戶端請求，端口經過TCP/IP協議（能夠經過Socket實現）創建鏈接。HTTP屬於TCP/IP模型中的運用層協議，因此通訊的過程實際上是對應數據的入棧和出棧。

TCP三次握手及四次揮手

先解釋一下各個碼的含義

序列號seq：佔4個字節，用來標記數據段的順序，TCP把鏈接中發送的全部數據字節都編上一個序號，第一個字節的編號由本地隨機產生；給字節編上序號後，就給每個報文段指派一個序號；序列號seq就是這個報文段中的第一個字節的數據編號。

確認號ack：佔4個字節，期待收到對方下一個報文段的第一個數據字節的序號；序列號表示報文段攜帶數據的第一個字節的編號；而確認號指的是指望接收到下一個字節的編號；所以當前報文段最後一個字節的編號+1即爲確認號。

確認ACK：佔1位，僅當ACK=1時，確認號字段纔有效。ACK=0時，確認號無效

同步SYN：鏈接創建時用於同步序號。當SYN=1，ACK=0時表示：這是一個鏈接請求報文段。若贊成鏈接，則在響應報文段中使得SYN=1，ACK=1。所以，SYN=1表示這是一個鏈接請求，或鏈接接受報文。SYN這個標誌位只有在TCP建產鏈接時纔會被置1，握手完成後SYN標誌位被置0。

終止FIN：用來釋放一個鏈接。FIN=1表示：此報文段的發送方的數據已經發送完畢，並要求釋放運輸鏈接

PS：ACK、SYN和FIN這些大寫的單詞表示標誌位，其值要麼是1，要麼是0；ack、seq小寫的單詞表示序號。

TCP三次握手

• 第一次握手：創建鏈接。客戶端發送鏈接請求同步SYN報文，SYN=1，seq=x。
• 第二次握手：服務器接收SYN報文，進行確認，設置ACK=1,表示確認。同時設置本身的SYN=1，設置seq=y,ack=x+1。其中seq爲服務器生成的序列號，ack爲第一次握手的seq序號加一。
• 第三次握手：客戶端接收SYN+ACK報文，設置ACK=1，表示確認收到。同時設置seq=x+1,ack=y+1。其中seq爲客戶端生成的下一個序列號，ack爲第二次握手的seq序號加一。

TCP四次揮手

• 客戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。
• 服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
• 客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這以前還須要接受服務器發送的最後的數據）。
• 服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
• 客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP鏈接尚未釋放，必須通過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
• 服務器只要收到了客戶端發出的確認，當即進入CLOSED狀態。一樣，撤銷TCB後，就結束了此次的TCP鏈接。能夠看到，服務器結束TCP鏈接的時間要比客戶端早一些。

HTTPS原理

在正式講解HTTPS協議以前，咱們首先要知道一些密碼學的知識。

密碼學

明文： 明文指的是未被加密過的原始數據。

密文：明文被某種加密算法加密以後，會變成密文，從而確保原始數據的安全。密文也能夠被解密，獲得原始的明文。

密鑰：密鑰是一種參數，它是在明文轉換爲密文或將密文轉換爲明文的算法中輸入的參數。密鑰分爲對稱密鑰與非對稱密鑰，分別應用在對稱加密和非對稱加密上。

對稱加密：對稱加密又叫作私鑰加密，即信息的發送方和接收方使用同一個密鑰去加密和解密數據。對稱加密的特色是算法公開、加密和解密速度快，適合於對大數據量進行加密，常見的對稱加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。 其加密過程以下：明文 + 加密算法 + 私鑰 => 密文 解密過程以下：密文 + 解密算法 + 私鑰 => 明文 對稱加密中用到的密鑰叫作私鑰，私鑰表示我的私有的密鑰，即該密鑰不能被泄露。 其加密過程當中的私鑰與解密過程當中用到的私鑰是同一個密鑰，這也是稱加密之因此稱之爲「對稱」的緣由。因爲對稱加密的算法是公開的，因此一旦私鑰被泄露，那麼密文就很容易被破解，因此對稱加密的缺點是密鑰安全管理困難。

非對稱加密：非對稱加密也叫作公鑰加密。非對稱加密與對稱加密相比，其安全性更好。對稱加密的通訊雙方使用相同的密鑰，若是一方的密鑰遭泄露，那麼整個通訊就會被破解。而非對稱加密使用一對密鑰，即公鑰和私鑰，且兩者成對出現。私鑰被本身保存，不能對外泄露。公鑰指的是公共的密鑰，任何人均可以得到該密鑰。用公鑰或私鑰中的任何一個進行加密，用另外一個進行解密。 被公鑰加密過的密文只能被私鑰解密，過程以下： 明文 + 加密算法 + 公鑰 => 密文， 密文 + 解密算法 + 私鑰 => 明文 被私鑰加密過的密文只能被公鑰解密，過程以下： 明文 + 加密算法 + 私鑰 => 密文， 密文 + 解密算法 + 公鑰 => 明文 因爲加密和解密使用了兩個不一樣的密鑰，這就是非對稱加密「非對稱」的緣由。 非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少許數據進行加密。 在非對稱加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（橢圓曲線加密算法）等。

HTTPS通訊過程

HTTPS協議 = HTTP協議 + SSL/TLS協議，在HTTPS數據傳輸的過程當中，須要用SSL/TLS對數據進行加密和解密，須要用HTTP對加密後的數據進行傳輸，由此能夠看出HTTPS是由HTTP和SSL/TLS一塊兒合做完成的。

SSL的全稱是Secure Sockets Layer，即安全套接層協議，是爲網絡通訊提供安全及數據完整性的一種安全協議。

TLS的全稱是Transport Layer Security，即安全傳輸層協議，，它創建在SSL 3.0協議規範之上，是SSL 3.0的後續版本。在TLS與SSL3.0之間存在着顯著的差異，主要是它們所支持的加密算法不一樣，因此TLS與SSL3.0不能互操做。雖然TLS與SSL3.0在加密算法上不一樣，可是在咱們理解HTTPS的過程當中，咱們能夠把SSL和TLS看作是同一個協議。

HTTPS在傳輸的過程當中會涉及到三個密鑰：

• 服務器端的公鑰和私鑰，用來進行非對稱加密，

• 客戶端生成的隨機密鑰，用來進行對稱加密

一個HTTPS請求實際上包含了兩次HTTP傳輸，能夠細分爲9步。

1.客戶端向服務器發起HTTPS請求，鏈接到服務器的443端口，發送的信息主要是隨機值1和客戶端支持的加密算法。

2.服務器端有一個密鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，服務器端保存着私鑰，不能將其泄露，公鑰能夠發送給任何人。

3.服務器生成隨機值2和匹配好的協商加密算法（這個加密算法必定是client發送給server加密算法的子集）發送給客戶端

4.服務器將本身的公鑰發送給客戶端。

5.客戶端收到服務器端的公鑰以後，會對公鑰進行檢查，驗證其合法性，若是發現發現公鑰有問題，那麼HTTPS傳輸就沒法繼續。嚴格的說，這裏應該是驗證服務器發送的數字證書的合法性，關於客戶端如何驗證數字證書的合法性，下文會進行說明。若是公鑰合格，那麼客戶端會生成一個隨機值，這個隨機值就是用於進行對稱加密的密鑰，咱們將該密鑰稱之爲client key，即客戶端密鑰，這樣在概念上和服務器端的密鑰容易進行區分。而後用服務器的公鑰對客戶端密鑰進行非對稱加密，這樣客戶端密鑰就變成密文了，至此，HTTPS中的第一次HTTP請求結束。

6.客戶端會發起HTTPS中的第二個HTTP請求，將加密以後的客戶端密鑰（造成新的密文）發送給服務器。

7.服務器接收到客戶端發來的密文以後，會用本身的私鑰對其進行非對稱解密，解密以後的明文就是客戶端密鑰，而後用客戶端密鑰對數據進行對稱加密，這樣數據就變成了密文。

8.而後服務器將加密後的密文發送給客戶端。

9.客戶端收到服務器發送來的密文，用客戶端密鑰對其進行對稱解密，獲得服務器發送的數據。這樣HTTPS中的第二個HTTP請求結束，整個HTTPS傳輸完成。

在通訊過程當中，怎麼保證保證服務器給客戶端下發的公鑰是真正的公鑰，而不是中間人僞造的公鑰呢？

答案：數字證書

數字證書

經過觀察HTTPS的傳輸過程，咱們知道，當服務器接收到客戶端發來的請求時，會向客戶端發送服務器本身的公鑰，可是黑客有可能中途篡改公鑰，將其改爲黑客本身的，因此有個問題，客戶端怎麼信賴這個公鑰是本身想要訪問的服務器的公鑰而不是黑客的呢？ 這時候就須要用到數字證書。

在講數字證書以前，先說一個小例子。假設一個鎮裏面有兩我的A和B，A是個富豪，B想向A借錢，可是A和B不熟，怕B借了錢以後不還。這時候B找到了鎮長，鎮長給B做擔保，告訴A說：「B人品不錯，不會欠錢不還的，你就放心借給他吧。」 A聽了這話後，內心想：「鎮長是全鎮最德高望重的了，他說B沒問題的話那就沒事了，我就放心了」。 因而A相信B的爲人，把錢借給了B。

與此類似的，要想讓客戶端信賴公鑰，公鑰也要找一個擔保人，並且這個擔保人的身份必須德高望重，不然沒有說服力。這個擔保人的就是證書認證中心（Certificate Authority），簡稱CA。 也就是說CA是專門對公鑰進行認證，進行擔保的，也就是專門給公鑰作擔保的擔保公司。 全球知名的CA也就100多個，這些CA都是全球都承認的，好比VeriSign、GlobalSign等，國內知名的CA有WoSign。

那CA怎麼對公鑰作擔保認證呢？CA自己也有一對公鑰和私鑰，CA會用CA本身的私鑰對要進行認證的公鑰進行非對稱加密，此處待認證的公鑰就至關因而明文，加密完以後，獲得的密文再加上證書的過時時間、頒發給、頒發者等信息，就組成了數字證書。

不論什麼平臺，設備的操做系統中都會內置100多個全球公認的CA，說具體點就是設備中存儲了這些知名CA的公鑰。當客戶端接收到服務器的數字證書的時候，會進行以下驗證：

首先客戶端會用設備中內置的CA的公鑰嘗試解密數字證書，若是全部內置的CA的公鑰都沒法解密該數字證書，說明該數字證書不是由一個全球知名的CA簽發的，這樣客戶端就沒法信任該服務器的數字證書。

若是有一個CA的公鑰可以成功解密該數字證書，說明該數字證書就是由該CA的私鑰簽發的，由於被私鑰加密的密文只能被與其成對的公鑰解密。

除此以外，還須要檢查客戶端當前訪問的服務器的域名是與數字證書中提供的「頒發給」這一項吻合，還要檢查數字證書是否過時等。

參考資料

blog.csdn.net/xiaoming100…

www.cnblogs.com/bj-mr-li/p/…

blog.csdn.net/iispring/ar…

www.jianshu.com/p/7158568e4…