HTTP基礎與HTTPS加密過程

1、前言

這篇文章主要是對HTTP/HTTPS的部分總結，由HTTP協議基礎知識引入HTTP協議的缺陷，進而描述HTTPS是如何解決HTTP的缺陷以及HTTPS的工做原理。

2、HTTP基礎

一、HTTP協議請求響應模型：

HTTP協議永遠都是客戶端發起請求，服務器回送響應。

二、HTTP協議特色

• 支持客戶/服務器模式；
• 簡單快速；
• 無鏈接：無鏈接的含義是每一次HTTP請求都要經歷TCP的鏈接的創建和斷開；（爲解決TCP鏈接問題，HTTP/1.1提出了持久鏈接的方法）
• 無狀態：HTTP協議對請求處理沒有記憶能力，服務器不知道客戶端的狀態。即客戶端發送HTTP請求，服務器作出迴應，返回數據，可是服務器不作任何記錄；
  • 優勢：若是服務器不須要先前傳送的信息時，服務端應答就快；
  • 缺點：若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大；（能夠經過Session/Cookie技術解決）

HTTP協議無狀態的特色致使了：沒法實如今客戶端沒有發起請求的時候，服務器將消息推送給客戶端。 服務器之因此沒法主動發送消息，是由於HTTP協議是一個無狀態的協議，同一個客戶端的此次請求和上次請求是沒有對應關係。 這個缺陷能夠用WebSocket協議解決，但這不在本文討論範圍。

三、HTTP協議格式

(1) 請求部分

HTTP請求由三部分組成，分別是：請求行、請求頭部、請求正文。

• 請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本。如：GET /index.html HTTP/1.1；
• 請求頭部按照頭部字段名稱: 頭部字段值的格式每行一條；
• 請求正文與請求頭部之間存在一個空行；

(2) 響應部分

HTTP響應由三部分組成，分別是：響應行、響應頭部、響應正文。

• 響應行以HTTP協議版本、響應狀態碼、響應狀態描述三部分組成 如：HTTP/1.1 200 OK；
• 響應頭部格式同請求頭部，但字段名稱略有不一樣；
• 響應正文與響應頭部之間存在一個空行；

狀態碼歸類：

狀態碼	狀態描述
1xx	指示信息--表示請求已接收，繼續處理
2xx	成功--表示請求已被成功接收、理解、接受
3xx	重定向--要完成請求必須進行更進一步的操做
4xx	客戶端錯誤--請求有語法錯誤或請求沒法實現
5xx	服務器端錯誤--服務器未能實現合法的請求

經常使用狀態碼解釋：

狀態碼	狀態解釋
200 OK	客戶端請求成功
400 Bad Request	客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized	請求未經受權，這個狀態代碼必須和WWW-Authenticate頭部一塊兒使用
403 Forbidden	服務器收到請求，可是拒絕提供服務
404 Not Found	請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error	服務器發生不可預期的錯誤
503 Server Unavailable	服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

四、HTTP協議請求方法

目前使用最普遍的HTTP1.1版本，支持如下幾個請求方法：

五、HTTP缺點

1. 通訊使用明文，內容可能會被竊聽；
2. 沒法證實報文的完整性，有可能遭到篡改；
3. 不驗證通訊方的身份，有可能遭遇假裝；

以上這些問題不只是HTTP協議獨有，其餘未加密的明文傳輸協議一樣也會存在這類問題。

3、HTTPS基礎

HTTPS並不是是應用層的一種新協議。只是HTTP通訊接口部分用SSL(Secure Scket Layer)和TLS(Transport Layer Security)協議代替而已。HTTP直接和TCP通訊。當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊了。所謂HTTPS，其實就是身披SSL協議這層外殼的HTTP。

HTTPS 協議的主要功能基本都依賴於TLS/SSL協議，TLS/SSL的功能實現主要依賴於三類基本算法：非對稱加密、對稱加密和散列函數：

• 非對稱加密實現身份認證和密鑰協商；
• 對稱加密算法採用協商的密鑰對數據加密；
• 基於散列函數驗證信息的完整性。

一、對稱加密、非對稱加密、CA和證書

瞭解HTTPS工做原理以前，須要先有關於對稱加密、非對稱加密、CA和證書的知識。

(1) 對稱加密與非對稱加密

1. 對稱加密 這種方式加密和解密同用一個密鑰。加密和解密都會用到密鑰。沒有密鑰就沒法對密碼解密，反過來講，任何人只要持有密鑰就能解密了。

對稱加密有個明顯的缺陷就是祕鑰自己如何進行保密和安全傳輸呢？只要第三方竊取到祕鑰，則能夠輕易破解密文。解決辦法就是經過非對稱加密。

2. 非對稱加密 不一樣於對稱加密，非對稱加密有一對祕鑰，一個是保密的，稱爲私鑰，一個是公開的，稱爲公鑰。私鑰加密的數據只有公鑰才能解開，公鑰加密的數據只有私鑰才能解開，這個特性很是重要，由於不須要傳輸私鑰了，而公鑰是公開的，能夠隨便傳播。常見的算法實現包括：RSA、DSA等。

非對稱加密有個重大缺陷就是計算速度遠慢於對稱加密。

(2) CA和證書

CA是Certificate Authority的縮寫，也叫「證書受權中心」。它是負責管理和簽發證書的第三方機構。

能夠經過如下方式查看證書內的內容：

證書內至少包含 數字簽名、 簽名算法、 公鑰、 有效時間等信息；

二、HTTPS如何解決HTTP存在的缺點

(1) 如何防止竊聽

HTTP的一個缺陷就是明文傳輸，數據包被別人捕獲以後就可獲取其中的信息。但通過HTTPS傳輸的數據是通過加密的，而解密用的祕鑰是通過雙方協商的一次性祕鑰，只有通訊雙方持有。因此其餘人即便抓到了HTTPS數據包，也沒法看到其中的內容，從而起到防止竊聽的做用。

(2) 如何防止假裝

非對稱加密方式存在的問題：就是沒法證實公開密鑰自己就是貨真價實的公開密鑰。HTTPS經過數字證書認證的方式防止假裝。

(3) 如何識別內容已被篡改

網絡傳輸過程當中須要通過不少中間節點，雖然數據沒法被解密，但可能被篡改。HTTPS經過校驗數字簽名來識別內容是否被篡改。

所謂數字簽名，就是對報文進行散列算出的數字摘要。即： 明文 -> 散列運算 -> 摘要 -> 私鑰加密 -> 數字簽名

服務器在發送報文以前作了3件的事：

• 用哈希算法對報文提取定長摘要；
• 用私鑰對摘要進行加密，做爲數字簽名；
• 將數字簽名附加到報文末尾發送給客戶端；

客戶端接收到報文後：

• 用公鑰對服務器的數字簽名進行解密；
• 用一樣的算法從新計算出報文的數字簽名；
• 比較解密後的簽名與本身計算的簽名是否一致，若是不一致，說明數據被篡改過；

一樣，客戶端發送數據時，經過公鑰加密報文摘要，服務器用私鑰解密，用一樣的方法校驗數據的完整性。

三、SSL/TLS 握手

SSL/TLS 握手：經過⾮對稱加密協商出一次性對稱加密的密鑰，握手完成之後就經過協商出的對稱加密的祕鑰加密傳輸數據。因此HTTPS採用非對稱加密和對稱加密並用的混合加密機制。

之因此這樣作，是出於對速度和安全性的折中考慮：

1. 非對稱加密速度遠遠慢與對稱加密，沒法在以後的整個通訊中使用非對稱加密；
2. 若是使用服務器中保存的公鑰和私有進行非對稱加密，由於若是客戶端使用公鑰加密，只有服務端私有才可解密；若是在服務端使用私鑰加密，則任何擁有公鑰的人均可解密，沒有安全可言。

方法	結構圖	描述	優缺點
方案1		採⽤用對稱加密來交換密鑰	缺點： 1.若是不公開祕鑰，對方沒法解密； 2.若是公開祕鑰，全部人均可以解密，沒有安全可言；
方案2		單純採⽤用⾮非對稱加密算法	缺點： 1.沒有認證過程，容易出現中間人攻擊；
方案3		基於CA 和⾮非對稱加密算法	優勢： 1.由於校驗證書的存在，防止了中間人攻擊； 2.使用證書中的公鑰完成非對稱加密，保證數據安全；
方案4		基於⽅方案3，增長session key複雜度	缺點： 1.客戶端與服務器在加密算法選擇、算法實現等選擇上，兼容性很差；
方案5		基於⽅方案4，增長加密算法協商，增長兼容性	優勢： 1.防止中間人攻擊； 2.非對稱加密協商出對稱加密的祕鑰，既達到加密傳輸的目的，也保證了雙方祕鑰的惟一性； 3.協商過程當中的加密算法、版本號、加密套件等參數增長了兼容性；

一次完整的協商過程：

參考 這篇文章

從Server Hello到Server Done，有些服務端的實現是每條單獨發送，有服務端實現是合併到一塊兒發送。Sever Hello和Server Done都是隻有頭沒有內容的數據。

4、有了HTTPS，爲何有些網站仍是HTTP？

上面的內容解釋了HTTPS是怎麼解決HTTP缺點的，既然HTTPS是安全可靠的，爲何不是全部的Web網站全都使用HTTPS呢？緣由至少有：

1. 由於須要握手協商祕鑰等信息，頁面加載時間比使用HTTP要長；
2. 加密和解密會消耗更多的CPU和內存資源；
3. 購買HTTPS所需證書也是一項開銷；

因此，僅僅在包含我的信息等敏感數據時，纔會使用HTTPS，尤爲是企業提供的對外服務。若是是內網通訊時，HTTP會是更好的選擇。