HTTP和HTTPS協議

大綱

 

 

 

1、前言

正好看到一篇介紹http和https的文章，想到之前面試的時候也被問過這個知識點以及https的加解密過程，因而就想總結一下。

 

2、HTTP和HTTPS發展

1.什麼是HTTP?

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

 

2.什麼是HTTPS?

 

HTTPS的全稱是Secure Hypertext Transfer Protocol（安全超文本傳輸協議），是在http協議基礎上增長了SSL加密傳送信息的協議。HTTPS協議經由HTTP進行通訊，利用SSL/TLS創建全信道，加密數據包。HTTPS使用的主要目的是提供對網站服務器的身份認證，同時保護交換數據的隱私與完整性。

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

 

3、HTTP VS HTTPS

1.HTTP特色

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

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

3.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

4.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

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

 

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

場景：逛電商商場用戶須要使用的時間比較長，須要對用戶一段時間的HTTP通訊狀態進行保存，好比執行一次登錄操做，在30分鐘內全部的請求都不須要再次登錄。

1.經過Cookie/Session技術

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

 

2.HTTPS特色

基於HTTP協議，經過SSL或TLS提供加密處理數據、驗證對方身份以及數據完整性保護。除了數據不是明文傳輸外，HTTPS還有以下特色：

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

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

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

 

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

 

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

 

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

• 收方可以證明發送方的真實身份；

• 發送方過後不可否認所發送過的報文；

• 收方或非法者不能僞造、篡改報文。

 

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

 

總結一下，HTTPS和HTTP的區別：

1.https協議須要到ca申請證書，通常免費證書不多，須要交費。

2.http是超文本傳輸協議，信息是明文傳輸，https 則是具備安全性的由ssl加密的傳輸協議。

3.http和https使用的端口不同，前者是80，後者是443。

4.http的鏈接很簡單，是無狀態的。

5.HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全。

 

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。