當前位置:首頁 > 知識 >

圖解HTTPS協議加密解密全過程?

HTTPS即加密的HTTP,HTTPS並不是一個新協議,而是HTTP+SSL(TLS)。原本HTTP先和TCP(假定傳輸層是TCP協議)直接通信,而加了SSL後,就變成HTTP先和SSL通信,再由SSL和TCP通信,相當於SSL被嵌在了HTTP和TCP之間。

我們首先了解幾個基本概念。

共享密鑰加密(對稱密鑰加密) :加密和解密同用一個密鑰。加密時就必須將密鑰傳送給對方,那麼如何安全的傳輸呢?

公開密鑰加密(非對稱密鑰加密) :公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰,一把叫做公開密鑰。私有密鑰不能讓其他任何人知道,而公開密鑰則可以隨意發布,任何人都可以獲得。使用此加密方式,發送密文的一方使用公開密鑰進行加密處理,對方收到被加密的信息後,再使用自己的私有密鑰進行解密。利用這種方式,不需要發送用來解密的私有密鑰,也不必擔心密鑰被攻擊者竊聽盜走。

但由於公開密鑰比共享密鑰要慢,所以我們就需要綜合一下他們兩者的優缺點,使他們共同使用,而這也是HTTPS采用的加密方式。 在交換密鑰階段使用公開密鑰加密方式,之後建立通信交換報文階段則使用共享密鑰加密方式。

這裏就有一個問題,如何證明公開密鑰本省是貨真價實的公開密鑰。如,正準備和某台服務器建立公開密鑰加密方式下的通信時,如何證明收到的公開密鑰就是原本預想的那台服務器發行的公開密鑰。或許在公開密鑰傳輸過程中,真正的公開密鑰已經被攻擊者替換掉了。為了解決這個問題,可以使用由數字證書認證機構(CA,Certificate Authority)和其他相關機關頒發的公開密鑰證書。

下圖是https通信步驟圖:

下麵是詳細步驟:

步驟 1: 客戶端通過發送 Client Hello 報文開始 SSL 通信。報文中包

含客戶端支持的 SSL 的指定版本、加密組件(Cipher Suite)列表(所

使用的加密算法及密鑰長度等)。

步驟 2: 服務器可進行 SSL 通信時,會以 Server Hello 報文作為應

答。和客戶端一樣,在報文中包含 SSL 版本以及加密組件。服務器的

加密組件內容是從接收到的客戶端加密組件內篩選出來的。

步驟 3: 之後服務器發送 Certificate 報文。報文中包含公開密鑰證

書。

步驟 4: 最後服務器發送 Server Hello Done 報文通知客戶端,最初階

段的 SSL 握手協商部分結束。

步驟 5: SSL 第一次握手結束之後,客戶端以 Client Key Exchange 報

文作為回應。報文中包含通信加密中使用的一種被稱為 Pre-master

secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。

步驟 6: 接著客戶端繼續發送 Change Cipher Spec 報文。該報文會提

示服務器,在此報文之後的通信會采用 Pre-master secret 密鑰加密。

步驟 7: 客戶端發送 Finished 報文。該報文包含連接至今全部報文的

整體校驗值。這次握手協商是否能夠成功,要以服務器是否能夠正確

解密該報文作為判定標準。

步驟 8: 服務器同樣發送 Change Cipher Spec 報文。

步驟 9: 服務器同樣發送 Finished 報文。

步驟 10: 服務器和客戶端的 Finished 報文交換完畢之後,SSL 連接

就算建立完成。當然,通信會受到 SSL 的保護。從此處開始進行應用

層協議的通信,即發送 HTTP 請求。

步驟 11: 應用層協議通信,即發送 HTTP 響應。

步驟 12: 最後由客戶端斷開連接。斷開連接時,發送 close_notify 報

文。上圖做了一些省略,這步之後再發送 TCP FIN 報文來關閉與 TCP

的通信。

在以上流程中,應用層發送數據時會附加一種叫做MAC(Message Authentication Cods)的報文摘要。MAC能夠查知報文是否遭到篡改從,從而保護報文的完整性。

猜你喜歡

微信二維碼

微信二維碼