http協議基礎(十一)http與https
一、http的缺點
之前有介紹過http協議相關的一些知識,http是相當優秀和方便的,但它也有缺點,主要不足表現在如下幾個方面:
△ 通訊使用明文(不加密),內容可能會被竊聽
△ 不驗證通訊方的身份,因此可能遭遇偽裝
△ 無法證明報文的完整性,所以有可能已被篡改
其他未加密的協議也存在這類問題
△ 某些特定web伺服器和特定web瀏覽器存在安全漏洞
1、通訊使用明文可能被竊聽
http本身不具有加密功能,無法做到對通訊整體(使用http協議通訊的請求和響應內容)進行加密,即:http報文使用明文(未經加密的報文)方式傳送
TCP/IP協議族的通訊機制:通訊內容在所有通訊線路上都可能被窺視
應對措施:對通訊進行加密處理防止被竊聽
加密物件:
①.通訊的加密
http協議沒有加密機制,可以通過SSL(Secure Socket Layer:安全套接層)或TLS(Transport Layer Security:安全層傳輸協議)組合使用,
加密http的通訊內容,這就是常說的https(超文字傳輸安全協議)
②.內容的加密
http協議沒有加密機制,對傳輸的內容本身進行加密,即報文實體主體部分;客戶端對請求報文加密處理後傳輸,但前提是客戶端和伺服器都具有加密和解密機制,
主要應用於WEB服務中(但仍然有被篡改的風險)
2、不驗證通訊方身份,可能遭遇偽裝
http協議中請求和響應不會對通訊方進行確認,即存在“伺服器是否是傳送請求中URI真正指定的主機。返回的響應是否真的返回到實際提出請求的客戶端”等類似問題
任何人都可以發起請求,伺服器只要接收到請求,不管對方是誰都會返回一個響應(僅限於傳送端IP和埠號沒有被WEB伺服器設定限制訪問的前提下)
http協議的隱患有以下幾點:
①.無法確定請求傳送至目標的web伺服器是否是按真實意圖返回響應的伺服器;有可能是已偽裝的伺服器
②.無法確定響應返回到的客戶端是否是按真實意圖接受響應的那個客戶端;有可能是已偽裝的客戶端
③.無法確定正在通訊的對方是否具備訪問許可權;因為某些web伺服器儲存有重要資訊,只發給特定使用者通訊的許可權
④.無法判斷請求來自何方
⑤.即使時無意義的請求也會接收,無法阻止海量請求下的D0S攻擊(Denial of Service:拒絕服務攻擊)
3、無法證明報文完整性,可能已遭篡改
完整性:指資訊的準確度,若無法證明其完整性,意味著無法判斷資訊是否正確
http協議無法證明通訊的報文完整性,因此,請求或者響應在傳輸過程中,如果遭到篡改,是無法知道的;類似這種請求或響應傳輸中被攻擊者攔截篡改的攻擊
稱為中間人攻擊(Man-in-the-Middle attack,MITM)
防止篡改:常用的方法有MD5和SHA-1等雜湊值校驗的方法,以及來確認檔案的數字簽名方法
二、HTTP+加密+認證+完整性保護=HTTPS
1、通常把添加了加密和身份認證機制的http協議稱為https(HTTP Secure);證書可證明伺服器或者客戶端的身份
2、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進行使用
3、加密技術
SSL採用公開金鑰加密(Public-key cryptography)的加密處理方式,加密方法中加密演算法是公開的,但金鑰是保密的,以保持加密方法的安全性(金鑰用來對已經加密的內容進行解密)
加密和解密通用一個金鑰的方式稱為共享金鑰加密(Common key crypto system),也稱為對稱金鑰加密
公開金鑰加密方式:
公開金鑰加密使用一對非對稱金鑰,一把叫做私有金鑰(private key),一把叫做公開金鑰(public key)
過程:傳送密文的一方使用對方公開的金鑰進行加密,對方收到被加密資訊後,使用自己的私有金鑰進行解密(要想根據密文和公開金鑰解密,理論上可以,但實際操作起來,非常困難)
HTTPS採用混合加密機制
https採用共享金鑰加密和公開金鑰加密兩者並用的混合加密機制。若金鑰可實現安全交換,則可能僅使用公開金鑰加密(公開金鑰加密相比共享金鑰加密,速度較慢)
實際運用中應該合理運用兩種加密機制的優勢,組合起來進行通訊(交換金鑰環節利用公開金鑰加密方式,建立通訊交換報文階段使用共享加密機制)
4、證書
由數字證書認證機構(CA:Certificate Authority)和其他相關機關頒發的公開金鑰證書
處於客戶端和伺服器雙方都可信賴的第三方機構立場,對通過申請的伺服器公開金鑰做數字簽名,分配該公開金鑰,將其與共鑰證書繫結,然後伺服器傳給客戶端,以進行公開金鑰加密方式通訊;
收到證書的客戶端使用數字證書認證機構的公開金鑰,對伺服器證書的數字簽名進行認證,然後明確2點:
①.認證伺服器的公開金鑰是真實有效的數字證書認證機構
②.伺服器的公開金鑰是指的信賴的
作用:
①.證明通訊方的伺服器是否規範
②.確認對方伺服器背後運營的企業是否真實存在(擁有該功能的證書就是EV SSL證書:Extended Validation SSL Cetificate );特點:瀏覽器背景色是綠色的
5、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優化探索與實踐