http協議（十一）http與https

1、http的缺點

以前有介紹過http協議相關的一些知識，http是至關優秀和方便的，但它也有缺點，主要不足表如今以下幾個方面：

△ 通訊使用明文（不加密），內容可能會被竊聽

△ 不驗證通訊方的身份，所以可能遭遇假裝

△ 沒法證實報文的完整性，因此有可能已被篡改

其餘未加密的協議也存在這類問題

△ 某些特定web服務器和特定web瀏覽器存在安全漏洞

 

一、通訊使用明文可能被竊聽

http自己不具備加密功能，沒法作到對通訊總體（使用http協議通訊的請求和響應內容）進行加密，即：http報文使用明文（未經加密的報文）方式傳送

TCP/IP協議族的通訊機制：通訊內容在全部通訊線路上均可能被窺視

應對措施：對通訊進行加密處理防止被竊聽

加密對象：

①.通訊的加密

http協議沒有加密機制，能夠經過SSL（Secure Socket Layer:安全套接層）或TLS（Transport Layer Security:安全層傳輸協議）組合使用，

加密http的通訊內容，這就是常說的https（超文本傳輸安全協議）

②.內容的加密

http協議沒有加密機制，對傳輸的內容自己進行加密，即報文實體主體部分；客戶端對請求報文加密處理後傳輸，但前提是客戶端和服務器都具備加密和解密機制，

主要應用於WEB服務中（但仍然有被篡改的風險）

 

二、不驗證通訊方身份，可能遭遇假裝

http協議中請求和響應不會對通訊方進行確認，即存在「服務器是不是發送請求中URI真正指定的主機。返回的響應是否真的返回到實際提出請求的客戶端」等相似問題

任何人均可以發起請求，服務器只要接收到請求，無論對方是誰都會返回一個響應（僅限於發送端IP和端口號沒有被WEB服務器設定限制訪問的前提下）

http協議的隱患有如下幾點：

①.沒法肯定請求發送至目標的web服務器是不是按真實意圖返回響應的服務器；有多是已假裝的服務器

②.沒法肯定響應返回到的客戶端是不是按真實意圖接受響應的那個客戶端；有多是已假裝的客戶端

③.沒法肯定正在通訊的對方是否具有訪問權限；由於某些web服務器保存有重要信息，只發給特定用戶通訊的權限

④.沒法判斷請求來自何方

⑤.即便時無心義的請求也會接收，沒法阻止海量請求下的D0S攻擊（Denial of Service:拒絕服務攻擊）

 

三、沒法證實報文完整性，可能已遭篡改

完整性：指信息的準確度，若沒法證實其完整性，意味着沒法判斷信息是否正確

http協議沒法證實通訊的報文完整性，所以，請求或者響應在傳輸過程當中，若是遭到篡改，是沒法知道的；相似這種請求或響應傳輸中被攻擊者攔截篡改的攻擊

稱爲中間人攻擊（Man-in-the-Middle attack,MITM）

防止篡改：經常使用的方法有MD5和SHA-1等散列值校驗的方法，以及來確認文件的數字簽名方法

 

2、HTTP+加密+認證+完整性保護=HTTPS

一、一般把添加了加密和身份認證機制的http協議稱爲https（HTTP Secure）；證書可證實服務器或者客戶端的身份

 

二、https至關於身披SSL外殼的http

https並不是應用層的一種新協議，而是在http通訊接口部分用SSL（Secure Socket Layer：安全套接字層）和TLS（Transport Layer Security：安全層傳輸協議）協議代替

一般，http和TCP直接通訊，當使用SSL時，先由http和SSL通訊，再由SSL和TCP通訊

 

SSL是獨立於http的協議，其餘應用層的如SMTP何Telnet等協議均可以配合SSL進行使用

 

三、加密技術

SSL採用公開密鑰加密（Public-key cryptography）的加密處理方式，加密方法中加密算法是公開的，但密鑰是保密的，以保持加密方法的安全性（密鑰用來對已經加密的內容進行解密）

加密和解密通用一個密鑰的方式稱爲共享密鑰加密（Common key crypto system），也稱爲對稱密鑰加密

公開密鑰加密方式：

公開密鑰加密使用一對非對稱密鑰，一把叫作私有密鑰（private key），一把叫作公開密鑰（public key）

過程：發送密文的一方使用對方公開的密鑰進行加密，對方收到被加密信息後，使用本身的私有密鑰進行解密（要想根據密文和公開密鑰解密，理論上能夠，但實際操做起來，很是困難）

HTTPS採用混合加密機制

https採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。若密鑰可實現安全交換，則可能僅使用公開密鑰加密（公開密鑰加密相比共享密鑰加密，速度較慢）

實際運用中應該合理運用兩種加密機制的優點，組合起來進行通訊（交換密鑰環節利用公開密鑰加密方式，創建通訊交換報文階段使用共享加密機制）

 

四、證書

由數字證書認證機構（CA:Certificate Authority）和其餘相關機關頒發的公開密鑰證書

處於客戶端和服務器雙方均可信賴的第三方機構立場，對經過申請的服務器公開密鑰作數字簽名，分配該公開密鑰，將其與共鑰證書綁定，而後服務器傳給客戶端，以進行公開密鑰加密方式通訊；

收到證書的客戶端使用數字證書認證機構的公開密鑰，對服務器證書的數字簽名進行認證，而後明確2點：

①.認證服務器的公開密鑰是真實有效的數字證書認證機構

②.服務器的公開密鑰是指的信賴的

做用：

①.證實通訊方的服務器是否規範

②.確認對方服務器背後運營的企業是否真實存在（擁有該功能的證書就是EV SSL證書：Extended Validation SSL Cetificate ）；特色：瀏覽器背景色是綠色的

 

五、HTTPS安全通訊機制

HTTPS通訊過程：

①.客戶端發送Client Hello報文開始通訊，報文中包含客戶端支持的SSL指定版本、加密組件、列表等

②.服務器接收到請求報文時，在響應報文中包含SSL版本以及加密組件發送Server Hello（加密組件內容從接收到的客戶端加密組件中篩選出來）

   而後服務器發送Certificate報文，其中包含公開密鑰證書

   最後服務器發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束

③.第一次握手結束，客戶端Client Key Exchange報文迴應，報文中包含通訊加密中使用的一種名爲Pre-master sercet的隨機密碼串（該報文已用上一步驟的公開密鑰進行加密）

   接着客戶端你繼續發送Change Cipher Spec報文，該報文提示服務器，在此報文以後的通訊採用Pre-master sercet密鑰加密

   最後客戶端發送Finished報文；該報文包含通訊鏈接至今所有報文的總體校驗值（此次握手可否成功，以服務器是否能夠正確解密報文爲判斷標準）

④.服務器一樣發送Change Cipher Spec報文

   服務器一樣發送Finisher報文

⑤.服務器和客戶端Finished報文交換完成後，SSL鏈接完成，通訊收到SSL保護，

⑥.應用層協議開始通訊，即HTTP請求

⑦.最後由客戶端斷開鏈接；斷開鏈接時，發送close_notify報文，而後發送TCP FIN報文關閉與TCP的通訊

上面的通訊過程當中，應用層發送數據時會附加MAC（Message Authentication Code）報文摘要，MAC可查詢報文是否遭受篡改，保護報文完整性

通訊流程圖（服務器公開密鑰證書創建HTTPS的過程）

HTTPS使用SSL（Secure Socket Layer：安全套接字層）和TLS（Transport Layer Security：安全層傳輸協議）這兩種協議

△ ：使用SSL時，處理速度回變慢

①.通訊慢：通訊時候大量消耗CPU及內存資源，相比較HTTP而已，網絡負載可能變慢2-100倍（通訊量增長）

②.加密處理：在服務器和客戶端都要進行加密和解密，更多的消耗了服務器和客戶端硬件資源，致使負載加強

改善方案：使用SSL加速器（專用服務器），爲SSL通訊專硬件，能夠提升數倍SSL計算你速度，僅在SSL通訊處理時發揮做用，以分擔負載。

擴展閱讀：美圖HTTPS優化探索與實踐