文章分享

開放、平等、協(xié)作、快速、分享

當(dāng)前位置:首頁>文章分享

圖解SSL/TLS協(xié)議

摘錄:HCTech 無錫和控電子   時間:2020-08-07   訪問量:3221

作者: 阮一峰

日期: 2014年9月20日

本周,CloudFlare宣布,開始提供Keyless服務(wù),即你把網(wǎng)站放到它們的CDN上,不用提供自己的私鑰,也能使用SSL加密鏈接。

CloudFlare

我看了CloudFlare的說明(這里這里),突然意識到這是絕好的例子,可以用來說明SSL/TLS協(xié)議的運(yùn)行機(jī)制。它配有插圖,很容易看懂。

下面,我就用這些圖片作為例子,配合我半年前寫的《SSL/TLS協(xié)議運(yùn)行機(jī)制的概述》,來解釋SSL協(xié)議。

一、SSL協(xié)議的握手過程

開始加密通信之前,客戶端和服務(wù)器首先必須建立連接和交換參數(shù),這個過程叫做握手(handshake)。

假定客戶端叫做愛麗絲,服務(wù)器叫做鮑勃,整個握手過程可以用下圖說明(點(diǎn)擊看大圖)。

握手階段分成五步。

第一步,愛麗絲給出協(xié)議版本號、一個客戶端生成的隨機(jī)數(shù)(Client random),以及客戶端支持的加密方法。

第二步,鮑勃確認(rèn)雙方使用的加密方法,并給出數(shù)字證書、以及一個服務(wù)器生成的隨機(jī)數(shù)(Server random)。

第三步,愛麗絲確認(rèn)數(shù)字證書有效,然后生成一個新的隨機(jī)數(shù)(Premaster secret),并使用數(shù)字證書中的公鑰,加密這個隨機(jī)數(shù),發(fā)給鮑勃。

第四步,鮑勃使用自己的私鑰,獲取愛麗絲發(fā)來的隨機(jī)數(shù)(即Premaster secret)。

第五步,愛麗絲和鮑勃根據(jù)約定的加密方法,使用前面的三個隨機(jī)數(shù),生成"對話密鑰"(session key),用來加密接下來的整個對話過程。

上面的五步,畫成一張圖,就是下面這樣。

二、私鑰的作用

握手階段有三點(diǎn)需要注意。

(1)生成對話密鑰一共需要三個隨機(jī)數(shù)。

(2)握手之后的對話使用"對話密鑰"加密(對稱加密),服務(wù)器的公鑰和私鑰只用于加密和解密"對話密鑰"(非對稱加密),無其他作用。

(3)服務(wù)器公鑰放在服務(wù)器的數(shù)字證書之中。

從上面第二點(diǎn)可知,整個對話過程中(握手階段和其后的對話),服務(wù)器的公鑰和私鑰只需要用到一次。這就是CloudFlare能夠提供Keyless服務(wù)的根本原因。

某些客戶(比如銀行)想要使用外部CDN,加快自家網(wǎng)站的訪問速度,但是出于安全考慮,不能把私鑰交給CDN服務(wù)商。這時,完全可以把私鑰留在自家服務(wù)器,只用來解密對話密鑰,其他步驟都讓CDN服務(wù)商去完成。

上圖中,銀行的服務(wù)器只參與第四步,后面的對話都不再會用到私鑰了。

三、DH算法的握手階段

整個握手階段都不加密(也沒法加密),都是明文的。因此,如果有人竊聽通信,他可以知道雙方選擇的加密方法,以及三個隨機(jī)數(shù)中的兩個。整個通話的安全,只取決于第三個隨機(jī)數(shù)(Premaster secret)能不能被破解。

雖然理論上,只要服務(wù)器的公鑰足夠長(比如2048位),那么Premaster secret可以保證不被破解。但是為了足夠安全,我們可以考慮把握手階段的算法從默認(rèn)的RSA算法,改為 Diffie-Hellman算法(簡稱DH算法)。

采用DH算法后,Premaster secret不需要傳遞,雙方只要交換各自的參數(shù),就可以算出這個隨機(jī)數(shù)。

上圖中,第三步和第四步由傳遞Premaster secret變成了傳遞DH算法所需的參數(shù),然后雙方各自算出Premaster secret。這樣就提高了安全性。

四、session的恢復(fù)

握手階段用來建立SSL連接。如果出于某種原因,對話中斷,就需要重新握手。

這時有兩種方法可以恢復(fù)原來的session:一種叫做session ID,另一種叫做session ticket。

session ID的思想很簡單,就是每一次對話都有一個編號(session ID)。如果對話中斷,下次重連的時候,只要客戶端給出這個編號,且服務(wù)器有這個編號的記錄,雙方就可以重新使用已有的"對話密鑰",而不必重新生成一把。

上圖中,客戶端給出session ID,服務(wù)器確認(rèn)該編號存在,雙方就不再進(jìn)行握手階段剩余的步驟,而直接用已有的對話密鑰進(jìn)行加密通信。

session ID是目前所有瀏覽器都支持的方法,但是它的缺點(diǎn)在于session ID往往只保留在一臺服務(wù)器上。所以,如果客戶端的請求發(fā)到另一臺服務(wù)器,就無法恢復(fù)對話。session ticket就是為了解決這個問題而誕生的,目前只有Firefox和Chrome瀏覽器支持。

上圖中,客戶端不再發(fā)送session ID,而是發(fā)送一個服務(wù)器在上一次對話中發(fā)送過來的session ticket。這個session ticket是加密的,只有服務(wù)器才能解密,其中包括本次對話的主要信息,比如對話密鑰和加密方法。當(dāng)服務(wù)器收到session ticket以后,解密后就不必重新生成對話密鑰了。

(完)


上一篇:抓包分析SSL/TLS連接建立過程【總結(jié)】

下一篇:https建立連接過程

在線咨詢

點(diǎn)擊這里給我發(fā)消息 售前咨詢專員

點(diǎn)擊這里給我發(fā)消息 售后服務(wù)專員

在線咨詢

免費(fèi)通話

24小時免費(fèi)咨詢

請輸入您的聯(lián)系電話,座機(jī)請加區(qū)號

免費(fèi)通話

微信掃一掃

微信聯(lián)系
返回頂部