【轉】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協議，只不過用"工作階段金鑰"加密內容。

五、參考連結

• MicroSoft TechNet, SSL/TLS in Detail
• Jeff Moser, The First Few Milliseconds of an HTTPS Connection
• Wikipedia, Transport Layer Security
• StackExchange, How does SSL work?

（完）

 

轉載至：http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

【轉】SSL/TLS協議運行機制的概述