网络编程-HTTPS协议的实现原理
HTTP傳輸協議缺點
- 之前幾篇文章中詳細講解了TCP/IP協議棧中的幾個協議,其中個就有對HTTP做了一個比較詳細的講解。HTTP是基于TCP進行傳輸的,其中傳輸的內容都是明文報文數據,如果我是一個黑客,我會想辦法獲取這個HTTP消息體,那我可以直接肉眼就能看出消息中的所有內容。這其實是存在很大風險的,如果HTTP消息被劫持,那么整個傳輸過程將存在風險,正因為存在以下三種風險,HTTP變成了一種不安全的協議
- 第一,竊聽風險(eavesdropping):第三方可以竊取通信內容
- 第二,篡改風險(tampering):第三方可以修改通信內容
- 第三,冒充風險(pretending):第三方可以冒充他人身份參與通信
加密協議SSL/TLS
- 互聯網中加密通信協議是通互聯網共同發展的一門技術。
- 1994年,NetScape公司設計了SSL協議(Secure Sockets Layer)的1.0版,但是未發布。
- 1995年,NetScape公司發布SSL 2.0版,很快發現有嚴重漏洞。
- 1996年,SSL 3.0版問世,得到大規模應用。
- 1999年,互聯網標準化組織ISOC接替NetScape公司,發布了SSL的升級版TLS 1.0版。
- 2006年和2008年,TLS進行了兩次升級,分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。
- 目前應用最廣的是TLS1.0,接下來是SSL 3.0。但是,主流瀏覽器都已經實現了TLS1.2 的支持。
- TLS1.0通常被標記為SSL3.1,TLS1.1為SSL3.2,TLS1.2為SSL3.3
更加安全的HTTPS
加密算法
-
加密算法有歷史悠久的發展,在一戰二戰中,都有廣泛使用,所以密碼學在社會發展種有廣泛的用途
-
第一對稱加密:有流式,分組兩種,加密和解密都是使用的同一個秘鑰,例如DES,AES-GCM,ChaCha20-Poly1305等
-
第二非對稱加密:加密使用的秘鑰和解密使用的秘鑰是不同的,分別稱為:公鑰,私鑰,公鑰和算法都是公開的,私鑰是保密的。非對稱加密性能較低,但是安全性超強,由于加密特性,非對稱加密算法能加密的數據長度也是有限的。例如:RSA,DSA,ECDSA,ECDHE
-
第三哈希算法:將任意長度的信息轉換為較為固定的長度的值,通常其長度要比信息小得多,且算法不可逆。例如:MD5,SHA-1,SHA-2,SHA-256
-
第四數字簽名:簽名就是在信息的后面加上一段內容(信息經過hash后的值),經過hash后的值,可以證明信息沒有被修改過。hash值一般都會加密后(也就是簽名)再和信息一起發送,以保證這個hash值不被修改。
對HTTP消息體對稱加密
-
如上圖中,展示了HTTP客戶端發出的請求很容易被黑客接貨,如果此時黑客冒充服務器,或者黑客竊取信息,則其可以放回任意信息給客戶端,而且不被客戶端察覺,所以我們經常會聽到“劫持”這個詞
-
如上圖是一個簡單HTTPS經過TCP 的三次握手后,客戶端與服務器建立連接,如果對后續雙方傳輸的內容進行對稱加密,那么理論上我們在本次傳輸中防止了內容的裸奔。缺點在于:
- 但是由于對稱加密使用的秘鑰兩端是一樣的,要維持每一個客戶端的秘鑰不一致,整套加密才有意義(比如我是黑客偽造的客戶端,如果秘鑰一致,那么黑客還是能拿到秘鑰,那沒有任何意義)。但是遇到的問題是產生n個不同的秘鑰,N=客戶端數量,維護困難。
- 另外,因為對稱加密需要雙方協商一致,一般提前約定,或者使用前傳輸秘鑰,不管哪一種方式,很容易秘鑰泄露。只要黑客拿到秘鑰,那么所謂加密傳輸也就失去意義。
對HTTP消息體進行非對稱加密
- 如下圖我們使用非對稱加密
- 上圖中客戶端用公鑰對請求內容加密,服務器使用私鑰對內容解密,反之亦然,但是上述過程也存在缺點:
- 公鑰是公開的(也就是黑客也會有公鑰),所以第4 步私鑰加密的信息如果被黑客接貨,就可以使用公鑰進行解密,獲取其中的內容。
- 非對稱加密不適用數量太大的報文,大數量的報文導致加密效率降低
對稱加密和非對稱加密結合使用
-
對稱加密的優勢:對稱加密如果能保證秘鑰不被黑客獲取,那么他是安全的,并且對稱加密的速度具有很大優勢
-
非對稱加密優勢:非對稱加密請求發起時候盡管使用的是公鑰加密,但是因為必須使用私鑰解密的特點,因此能夠保證消息體在想服務器發送過程中是安全的。
-
兩者結合做法:
- 使用對稱加密對消息體進行加密
- 對稱加密的算法和對稱秘鑰使用公鑰加密后,在ClientHello時發送給服務器
- 后續雙方的內容進行對稱加密
-
如上圖,我們之前說了秘鑰交換在第一步進行,一下幾個步驟意義如下:
- 第3 步時候,客戶端給服務器說:(之后回話用對稱秘鑰,這是對稱算法XXX,和對稱秘鑰XXX),這段話用公鑰進行加密,然后傳給服務器。
- 第4步時候,服務器收到信息后,用私鑰解密,提取出對稱加密算法和對稱秘鑰后,服務器回復:(好的)并用對稱秘鑰加密
- 后續兩者之間的信息傳輸就可以使用對稱加密的方式了。
-
使用這個方式時候,還有部分問題:
- 如何將公鑰給客戶端
- 客戶端在獲取一個公鑰后,如何確認公鑰是正確的服務端發出的而不是黑客偽裝的
-
如上圖的情況第一步中公鑰獲取是存在風險的,而且直接在某個地方下載公鑰也是不可靠的,因為黑客也可以在下載公鑰的時候劫持了請求,并偽造公鑰返回給客戶端。后續的請求都會被黑客欺騙。
-
解決方案是使用證書:
- 證書是一個經證書授權中心數字簽名的包含公開秘鑰擁有者信息以及公開秘鑰的文件,最簡單的證書包含:公開秘鑰,名稱,證書授權中心數字簽名。數字證書還有一個重要特征就是旨在特定時間段內有效
- 數字幀數是一種權威性的電子文檔,可以由權威工作的第三方機構,即CA(例如中國各地方的CA公司)中心簽發的證書,也可以由企業級別CA系統進行簽發。
-
如下證書模式HTTPS:
-
如上圖,2步驟時候服務器發送了一個SSL證書給客戶端,SSL證書中包含的具體內容有:
- 證書發布機構CA
- 證書有效期
- 公鑰
- 證書所有者
- 簽名
-
客戶端在接受服務器發來的SSL證書會對證書進行校驗,以瀏覽器為例說明如下:
- 首先瀏覽器讀取證書中的證書所有者,有效期信息進行校驗
- 瀏覽器開始查找操作系統中已內置的收信人的證書發布機構CA,與服務器發來的證書中的頒發者CA對比,用于校驗證書是否為合法機構頒發
- 如果找不到,瀏覽器報錯,說明服務器發來的證書是不可信的。
- 如果找到,瀏覽器會從操作系統中取出頒發者CA的公鑰,然后對服務器發來的證書里面的簽名進行解密
- 瀏覽器使用相同的hash算法計算出服務器發來的證書的hash值,將這個計算的hash值域證書中簽名做對比
- 對比結果一致,則證明服務器發來的證書核發,沒有被冒充。
- 此時瀏覽器就可以讀取證書中公鑰,用于后續加密了。
-
通過SSl證書的形式,即解決了公鑰獲取問題,又解決了黑客冒充問題,HTTPS加密過程也就此形成。所以對不HTTP,HTTPS傳輸更安全。
- 所有信息都加密傳播
- 具有校驗機制,一旦被篡改,通信雙方立刻會發現
- 配備身份證書,防止身份被冒充。
上一篇 網絡編程-TCP/IP協議棧-UDP/HTTP協議
總結
以上是生活随笔為你收集整理的网络编程-HTTPS协议的实现原理的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 中药泥灸可以敷脸祛斑吗
- 下一篇: Docker中数据管理