1. 程式人生 > >SSL/TLS協議執行機制的概述

SSL/TLS協議執行機制的概述

網際網路的通訊安全,建立在SSL/TLS協議之上。

本文簡要介紹SSL/TLS協議的執行機制。文章的重點是設計思想和執行過程,不涉及具體的實現細節。如果想了解這方面的內容,請參閱RFC文件

一、作用

不使用SSL/TLS的HTTP通訊,就是不加密的通訊。所有資訊明文傳播,帶來了三大風險。

(1) 竊聽風險(eavesdropping):第三方可以獲知通訊內容。

(2) 篡改風險(tampering):第三方可以修改通訊內容。

(3) 冒充風險(pretending):第三方可以冒充他人身份參與通訊。

SSL/TLS協議是為了解決這三大風險而設計的,希望達到:

(1) 所有資訊都是加密傳播

,第三方無法竊聽。

(2) 具有校驗機制,一旦被篡改,通訊雙方會立刻發現。

(3) 配備身份證書,防止身份被冒充。

網際網路是開放環境,通訊雙方都是未知身份,這為協議的設計帶來了很大的難度。而且,協議還必須能夠經受所有匪夷所思的攻擊,這使得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的修訂版

目前,應用最廣泛的是TLS 1.0,接下來是SSL 3.0。但是,主流瀏覽器都已經實現了TLS 1.2的支援。

TLS 1.0通常被標示為SSL 3.1,TLS 1.1為SSL 3.2,TLS 1.2為SSL 3.3。

三、基本的執行過程

SSL/TLS協議的基本思路是採用公鑰加密法,也就是說,客戶端先向伺服器端索要公鑰,然後用公鑰加密資訊,伺服器收到密文後,用自己的私鑰解密。

但是,這裡有兩個問題。

(1)如何保證公鑰不被篡改?

解決方法:將公鑰放在

數字證書中。只要證書是可信的,公鑰就是可信的。

(2)公鑰加密計算量太大,如何減少耗用的時間?

解決方法:每一次對話(session),客戶端和伺服器端都生成一個"對話金鑰"(session key),用它來加密資訊。由於"對話金鑰"是對稱加密,所以運算速度非常快,而伺服器公鑰只用於加密"對話金鑰"本身,這樣就減少了加密運算的消耗時間。

因此,SSL/TLS協議的基本過程是這樣的:

(1) 客戶端向伺服器端索要並驗證公鑰。

(2) 雙方協商生成"對話金鑰"。

(3) 雙方採用"對話金鑰"進行加密通訊。

上面過程的前兩步,又稱為"握手階段"(handshake)。

四、握手階段的詳細過程

"握手階段"涉及四次通訊,我們一個個來看。需要注意的是,"握手階段"的所有通訊都是明文的。

4.1 客戶端發出請求(ClientHello)

首先,客戶端(通常是瀏覽器)先向伺服器發出加密通訊的請求,這被叫做ClientHello請求。

在這一步,客戶端主要向伺服器提供以下資訊。

(1) 支援的協議版本,比如TLS 1.0版。

(2) 一個客戶端生成的隨機數,稍後用於生成"對話金鑰"。

(3) 支援的加密方法,比如RSA公鑰加密。

(4) 支援的壓縮方法。

這裡需要注意的是,客戶端傳送的資訊之中不包括伺服器的域名。也就是說,理論上伺服器只能包含一個網站,否則會分不清應該向客戶端提供哪一個網站的數字證書。這就是為什麼通常一臺伺服器只能有一張數字證書的原因。

對於虛擬主機的使用者來說,這當然很不方便。2006年,TLS協議加入了一個Server Name Indication擴充套件,允許客戶端向伺服器提供它所請求的域名。

4.2 伺服器迴應(SeverHello)

伺服器收到客戶端請求後,向客戶端發出迴應,這叫做SeverHello。伺服器的迴應包含以下內容。

(1) 確認使用的加密通訊協議版本,比如TLS 1.0版本。如果瀏覽器與伺服器支援的版本不一致,伺服器關閉加密通訊。

(2) 一個伺服器生成的隨機數,稍後用於生成"對話金鑰"。

(3) 確認使用的加密方法,比如RSA公鑰加密。

(4) 伺服器證書。

除了上面這些資訊,如果伺服器需要確認客戶端的身份,就會再包含一項請求,要求客戶端提供"客戶端證書"。比如,金融機構往往只允許認證客戶連入自己的網路,就會向正式客戶提供USB金鑰,裡面就包含了一張客戶端證書。

4.3 客戶端迴應

客戶端收到伺服器迴應以後,首先驗證伺服器證書。如果證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已經過期,就會向訪問者顯示一個警告,由其選擇是否還要繼續通訊。

如果證書沒有問題,客戶端就會從證書中取出伺服器的公鑰。然後,向伺服器傳送下面三項資訊。

(1) 一個隨機數。該隨機數用伺服器公鑰加密,防止被竊聽。

(2) 編碼改變通知,表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。

(3) 客戶端握手結束通知,表示客戶端的握手階段已經結束。這一項同時也是前面傳送的所有內容的hash值,用來供伺服器校驗。

上面第一項的隨機數,是整個握手階段出現的第三個隨機數,又稱"pre-master key"。有了它以後,客戶端和伺服器就同時有了三個隨機數,接著雙方就用事先商定的加密方法,各自生成本次會話所用的同一把"會話金鑰"。

至於為什麼一定要用三個隨機數,來生成"會話金鑰",dog250解釋得很好:

"不管是客戶端還是伺服器,都需要隨機數,這樣生成的金鑰才不會每次都一樣。由於SSL協議中證書是靜態的,因此十分有必要引入一種隨機因素來保證協商出來的金鑰的隨機性。

對於RSA金鑰交換演算法來說,pre-master-key本身就是一個隨機數,再加上hello訊息中的隨機,三個隨機數通過一個金鑰匯出器最終匯出一個對稱金鑰。

pre master的存在在於SSL協議不信任每個主機都能產生完全隨機的隨機數,如果隨機數不隨機,那麼pre master secret就有可能被猜出來,那麼僅適用pre master secret作為金鑰就不合適了,因此必須引入新的隨機因素,那麼客戶端和伺服器加上pre master secret三個隨機數一同生成的金鑰就不容易被猜出了,一個偽隨機可能完全不隨機,可是是三個偽隨機就十分接近隨機了,每增加一個自由度,隨機性增加的可不是一。"

此外,如果前一步,伺服器要求客戶端證書,客戶端會在這一步傳送證書及相關資訊。

4.4 伺服器的最後迴應

伺服器收到客戶端的第三個隨機數pre-master key之後,計算生成本次會話所用的"會話金鑰"。然後,向客戶端最後傳送下面資訊。

(1)編碼改變通知,表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。

(2)伺服器握手結束通知,表示伺服器的握手階段已經結束。這一項同時也是前面傳送的所有內容的hash值,用來供客戶端校驗。

至此,整個握手階段全部結束。接下來,客戶端與伺服器進入加密通訊,就完全是使用普通的HTTP協議,只不過用"會話金鑰"加密內容。

五、參考連結

(完)