HTTPS協議說明


HTTPS協議說明

基本現在最安全的網絡連接就是使用https了,http協議有幾個不安全的地方:

  • 傳輸信息是明文的。 -- http的傳輸信息是明文的,基本網絡劫持下就束手就擒了。
  • 不能防止篡改。 -- 在網絡傳輸層面是無法防止第三方截取請求,篡改請求,再發送給服務器的。

其實從互聯網已開始,網絡傳輸的加密協議就有人在研究了。

基本想法就是把通信雙方的傳輸信息使用加密算法加密起來。這樣就可以保證兩邊的通信可以得到保護。

這里的加密方法基本有兩種,對稱加密或者非對稱加密。如果使用非對稱加密算法,客戶端每次請求之前先去服務端請求一對公鑰,服務端生成一個私鑰,然后使用公鑰加密數據,服務端使用私鑰揭秘數據。但是往往非對稱加密的加密和解密的過程計算量很大,非常耗時。所以這個方法不可行。

那么就使用對稱加密算法,客戶端每次請求獲取一個秘鑰,這個秘鑰是用來后續進行信息交互的時候加密信息的。這個秘鑰可以不是服務端一次生成的,而是通過幾次交互雙方獲得的秘鑰一起組合而成。

TLS算法就是通過證書的方式和非對稱加密的方式讓雙方生成3個隨機秘鑰,從而組合得到一個安全的內容對稱秘鑰。

另外,首先有個前提要先說在前面,HTTPS算法也是基於TCP的,那么這個所謂的TLS算法的握手步驟是在TCP握手完成之后才進行安全握手的。

TLS算法

HandShake Protocol

這個圖就是非常經典的客戶端和服務端進行安全握手的請求過程。

簡要來說,這四個過程最主要做了下面幾個事情:

  • Client Hello(客戶端向服務端請求安全握手,並帶給服務端第一個隨機數)
  • Server Hello(服務端返回包含公鑰的證書和第二個隨機數)
  • Client Key Exchange(客戶端看到證書后確認服務端身份,並獲取證書中的公鑰,使用公鑰返回第三個隨機數)
  • Server Finish(服務端通知客戶端完成握手)

服務器和客戶端安全握手之后,這次的session兩邊都得到了三個隨機數,使用着三個隨機數,雙方使用事先約定的加密算法生成了“會話秘鑰”。后續的對話都是使用這個秘鑰進行加密的。

我們一個個步驟看。

Client Hello

客戶端向服務器端發送的信息有:

  • 支持的安全握手的協議版本,比如TLS1.2
  • 客戶端生成的隨機數
  • 客戶端支持的會話加密算法,比如DES加密
  • 支持的壓縮方法

Server Hello

這個過程,服務端了解到客戶端的信息了,服務端向客戶端發送的信息有:

  • 確認使用的安全握手的協議版本,比如TLS1.2
  • 確認使用的會話加密算法,比如DES加密
  • 服務端生成的隨機數
  • 服務器的證書

有人可能會問,這里如果直接發送服務器的公鑰給客戶端行不行,答案是不行,證書除了有公私鑰的信息之外,還有一個證書機構進行保證。所以,這個證書是不能偽造的。

Client Key Exchange

客戶端看到證書后,去頒發機構確認這個證書正確,然后從證書中獲取到公鑰。注意,這個公鑰只是用來加密第三個隨機數的。

  • 發送第三個隨機數(這個隨機數已經被公鑰加密,只有對應的服務器用私鑰才能打開)
  • 告知服務端,客戶端已經做好准備了,可以傳輸數據了。

這第三個隨機數有個名稱叫pre-master key。

客戶端使用TLS1.2規定的算法計算出會話秘鑰。

Server Finish

服務端使用私鑰獲取到第三個隨機數。並且使用TLS1.2規定的算法計算出會話秘鑰。並告知可以開始傳輸數據了。

數據傳輸階段

客戶端和服務端用會話秘鑰加上定義好的會話加密算法加密他們之間的所有對話請求。

至此,TLS的安全握手流程就結束了。

參考

Https(SSL/TLS)原理詳解
Htttps SSL/TLS Session Secret(Key)計算
圖解SSL/TLS協議
SSL/TLS協議運行機制的概述
HTTPS 詳解


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM