SSL/TLS原理詳解

本文大部分整理自網絡，相關文章請見文後參考。

SSL/TLS作為一種網際網路安全加密技術，原理較為複雜，枯燥而無味，我也是試圖了解之後重新整理，盡量做到層次清晰。正文開始。

1. SSL/TLS概覽

1.1 整體結構

SSL是一個介于HTTP協定與TCP之間的一個可選層，其位置大緻如下:

• SSL：（Secure Socket Layer，安全套接字層），為Netscape所研發，用以保障在Internet上資料傳輸之安全，利用資料加密(Encryption)技術，可確定資料在網絡上之傳輸過程中不會被截取。目前版本為3.0。它已被廣泛地用于Web浏覽器與伺服器之間的身份認證和加密資料傳輸。

  SSL協定位于TCP/IP協定與各種應用層協定之間，為資料通訊提供安全支援。SSL協定可分為兩層： SSL記錄協定（SSL Record Protocol）：它建立在可靠的傳輸協定（如TCP）之上，為高層協定提供資料封裝、壓縮、加密等基本功能的支援。 SSL握手協定（SSL Handshake Protocol）：它建立在SSL記錄協定之上，用于在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。

• TLS：(Transport Layer Security，傳輸層安全協定)，用于兩個應用程式之間提供保密性和資料完整性。

  TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務組）制定的一種新的協定，它建立在SSL 3.0協定規範之上，是SSL 3.0的後續版本，可以了解為SSL 3.1，它是寫入了 RFC 的。該協定由兩層組成： TLS 記錄協定（TLS Record）和 TLS 握手協定（TLS Handshake）。較低的層為 TLS 記錄協定，位于某個可靠的傳輸協定（例如 TCP）上面。

SSL/TLS協定提供的服務主要有：

1. 認證使用者和伺服器，確定資料發送到正确的客戶機和伺服器；
2. 加密資料以防止資料中途被竊取；
3. 維護資料的完整性，確定資料在傳輸過程中不被改變。

1.2 TLS與SSL的差異

1. 版本号：TLS記錄格式與SSL記錄格式相同，但版本号的值不同，TLS的版本1.0使用的版本号為SSLv3.1。
2. 封包驗證碼：SSLv3.0和TLS的MAC算法及MAC計算的範圍不同。TLS使用了RFC-2104定義的HMAC算法。SSLv3.0使用了相似的算法，兩者差别在于SSLv3.0中，填充位元組與密鑰之間采用的是連接配接運算，而HMAC算法采用的是異或運算。但是兩者的安全程度是相同的。
3. 僞随機函數：TLS使用了稱為PRF的僞随機函數來将密鑰擴充成資料塊，是更安全的方式。
4. 報警代碼：TLS支援幾乎所有的SSLv3.0報警代碼，而且TLS還補充定義了很多報警代碼，如解密失敗（decryption_failed）、記錄溢出（record_overflow）、未知CA（unknown_ca）、拒絕通路（access_denied）等。
5. 密文族和客戶證書：SSLv3.0和TLS存在少量差别，即TLS不支援Fortezza密鑰交換、加密算法和客戶證書。
6. certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息計算MD5和SHA-1散列碼時，計算的輸入有少許差别，但安全性相當。
7. 加密計算：TLS與SSLv3.0在計算主密值（master secret）時采用的方式不同。
8. 填充：使用者資料加密之前需要增加的填充位元組。在SSL中，填充後的資料長度要達到密文塊長度的最小整數倍。而在TLS中，填充後的資料長度可以是密文塊長度的任意整數倍（但填充的最大長度為255位元組），這種方式可以防止基于對封包長度進行分析的攻擊。

TLS的主要增強内容

TLS的主要目标是使SSL更安全，并使協定的規範更精确和完善。TLS 在SSL v3.0 的基礎上，提供了以下增強内容：

1. 更安全的MAC算法
2. 更嚴密的警報
3. “灰色區域”規範的更明确的定義

TLS對于安全性的改進

1. 對于消息認證使用密鑰散列法：TLS 使用“消息認證代碼的密鑰散列法”（HMAC），當記錄在開放的網絡（如網際網路）上傳送時，該代碼確定記錄不會被變更。SSLv3.0還提供鍵控消息認證，但HMAC比SSLv3.0使用的（消息認證代碼）MAC 功能更安全。
2. 增強的僞随機功能（PRF）：PRF生成密鑰資料。在TLS中，HMAC定義PRF。PRF使用兩種雜湊演算法保證其安全性。如果任一算法暴露了，隻要第二種算法未暴露，則資料仍然是安全的。
3. 改進的已完成消息驗證：TLS和SSLv3.0都對兩個端點提供已完成的消息，該消息認證交換的消息沒有被變更。然而，TLS将此已完成消息基于PRF和HMAC值之上，這也比SSLv3.0更安全。
4. 一緻證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實作交換的證書類型。
5. 特定警報消息：TLS提供更多的特定和附加警報，以訓示任一會話端點檢測到的問題。TLS還對何時應該發送某些警報進行記錄。

2. 密鑰協商過程——TLS握手

SSL協定分為兩部分：Handshake Protocol和Record Protocol。其中Handshake Protocol用來協商密鑰，協定的大部分内容就是通信雙方如何利用它來安全的協商出一份密鑰。 Record Protocol則定義了傳輸的格式。

由于非對稱加密的速度比較慢，是以它一般用于密鑰交換，雙方通過公鑰算法協商出一份密鑰，然後通過對稱加密來通信，當然，為了保證資料的完整性，在加密前要先經過HMAC的處理。

SSL預設隻進行server端的認證，用戶端的認證是可選的。以下是其流程圖（摘自TLS協定）。

2.1 用戶端送出請求（ClientHello）

由于用戶端(如浏覽器)對一些加解密算法的支援程度不一樣，但是在TLS協定傳輸過程中必須使用同一套加解密算法才能保證資料能夠正常的加解密。在TLS握手階段，用戶端首先要告知服務端，自己支援哪些加密算法，是以用戶端需要将本地支援的加密套件(Cipher Suite)的清單傳送給服務端。除此之外，用戶端還要産生一個随機數，這個随機數一方面需要在用戶端儲存，另一方面需要傳送給服務端，用戶端的随機數需要跟服務端産生的随機數結合起來産生後面要講到的 Master Secret 。

綜上，在這一步，用戶端主要向伺服器提供以下資訊：

1. 支援的協定版本，比如TLS 1.0版
2. 一個用戶端生成的随機數，稍後用于生成"對話密鑰"
3. 支援的加密方法，比如RSA公鑰加密
4. 支援的壓縮方法

2.2 伺服器回應（SeverHello)

上圖中，從Server Hello到Server Done，有些服務端的實作是每條單獨發送，有服務端實作是合并到一起發送。Sever Hello和Server Done都是隻有頭沒有内容的資料。

服務端在接收到用戶端的Client Hello之後，服務端需要将自己的證書發送給用戶端。這個證書是對于服務端的一種認證。例如，用戶端收到了一個來自于稱自己是www.alipay.com的資料，但是如何證明對方是合法的alipay支付寶呢？這就是證書的作用，支付寶的證書可以證明它是alipay，而不是财付通。證書是需要申請，并由專門的數字證書認證機構(CA)通過非常嚴格的稽核之後頒發的電子證書。頒發證書的同時會産生一個私鑰和公鑰。私鑰由服務端自己儲存，不可洩漏。公鑰則是附帶在證書的資訊中，可以公開的。證書本身也附帶一個證書電子簽名，這個簽名用來驗證證書的完整性和真實性，可以防止證書被串改。另外，證書還有個有效期。

在服務端向用戶端發送的證書中沒有提供足夠的資訊（證書公鑰）的時候，還可以向用戶端發送一個 Server Key Exchange，

此外，對于非常重要的保密資料，服務端還需要對用戶端進行驗證，以保證資料傳送給了安全的合法的用戶端。服務端可以向用戶端發出 Cerficate Request 消息，要求用戶端發送證書對用戶端的合法性進行驗證。比如，金融機構往往隻允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，裡面就包含了一張用戶端證書。

跟用戶端一樣，服務端也需要産生一個随機數發送給用戶端。用戶端和服務端都需要使用這兩個随機數來産生Master Secret。

最後服務端會發送一個Server Hello Done消息給用戶端，表示Server Hello消息結束了。

綜上，在這一步，伺服器的回應包含以下内容：

1. 确認使用的加密通信協定版本，比如TLS 1.0版本。如果浏覽器與伺服器支援的版本不一緻，伺服器關閉加密通信
2. 一個伺服器生成的随機數，稍後用于生成"對話密鑰"
3. 确認使用的加密方法，比如RSA公鑰加密
4. 伺服器證書

2.3 用戶端回應（Certificate Verify）

Client Key Exchange

如果服務端需要對用戶端進行驗證，在用戶端收到服務端的 Server Hello 消息之後，首先需要向服務端發送用戶端的證書，讓服務端來驗證用戶端的合法性。

Certificate Verify

接着，用戶端需要對服務端的證書進行檢查，如果證書不是可信機構頒布、或者證書中的域名與實際域名不一緻、或者證書已經過期，就會向通路者顯示一個警告，由其選擇是否還要繼續通信。如果證書沒有問題，用戶端就會從伺服器證書中取出伺服器的公鑰。然後，向伺服器發送下面三項資訊：

1. 一個随機數。該随機數用伺服器公鑰加密，防止被竊聽
2. 編碼改變通知，表示随後的資訊都将用雙方商定的加密方法和密鑰發送
3. 用戶端握手結束通知，表示用戶端的握手階段已經結束。這一項同時也是前面發送的所有内容的hash值，用來供伺服器校驗

上面第一項的随機數，是整個握手階段出現的第三個随機數，它是用戶端使用一些加密算法(例如：RSA, Diffie-Hellman)産生一個48個位元組的Key，這個Key叫 PreMaster Secret，很多材料上也被稱作 PreMaster Key。

ChangeCipherSpec

ChangeCipherSpec是一個獨立的協定，展現在資料包中就是一個位元組的資料，用于告知服務端，用戶端已經切換到之前協商好的加密套件（Cipher Suite）的狀态，準備使用之前協商好的加密套件加密資料并傳輸了。

在ChangecipherSpec傳輸完畢之後，用戶端會使用之前協商好的加密套件和Session Secret加密一段 Finish 的資料傳送給服務端，此資料是為了在正式傳輸應用資料之前對剛剛握手建立起來的加解密通道進行驗證。

2.4 伺服器的最後回應（Server Finish）

服務端在接收到用戶端傳過來的 PreMaster 加密資料之後，使用私鑰對這段加密資料進行解密，并對資料進行驗證，也會使用跟用戶端同樣的方式生成 Session Secret，一切準備好之後，會給用戶端發送一個 ChangeCipherSpec，告知用戶端已經切換到協商過的加密套件狀态，準備使用加密套件和 Session Secret加密資料了。之後，服務端也會使用 Session Secret 加密一段 Finish 消息發送給用戶端，以驗證之前通過握手建立起來的加解密通道是否成功。

根據之前的握手資訊，如果用戶端和服務端都能對Finish資訊進行正常加解密且消息正确的被驗證，則說明握手通道已經建立成功，接下來，雙方可以使用上面産生的Session Secret對資料進行加密傳輸了。

2.5 幾個secret

Secret Keys

上面的分析和講解主要是為了突出握手的過程，是以PreMaster secret，Master secret，session secret都是一代而過，但是對于Https，SSL/TLS深入的了解和掌握，這些Secret Keys是非常重要的部分。是以，準備把這些Secret Keys抽出來單獨分析和講解。

我們先來看看這些Secret Keys的生成過程以及作用流程圖：

PreMaster secret

PreMaster Secret是在用戶端使用RSA或者Diffie-Hellman等加密算法生成的。它将用來跟服務端和用戶端在Hello階段産生的随機數結合在一起生成 Master Secret。在用戶端使用服務端的公鑰對PreMaster Secret進行加密之後傳送給服務端，服務端将使用私鑰進行解密得到PreMaster secret。也就是說服務端和用戶端都有一份相同的PreMaster secret和随機數。

PreMaster secret前兩個位元組是TLS的版本号，這是一個比較重要的用來核對握手資料的版本号，因為在Client Hello階段，用戶端會發送一份加密套件清單和目前支援的SSL/TLS的版本号給服務端，而且是使用明文傳送的，如果握手的資料包被破解之後，攻擊者很有可能串改資料包，選擇一個安全性較低的加密套件和版本給服務端，進而對資料進行破解。是以，服務端需要對密文中解密出來對的PreMaster版本号跟之前Client Hello階段的版本号進行對比，如果版本号變低，則說明被串改，則立即停止發送任何消息。

關于PreMaster Secret(Key)的計算請參考 Https SSL/TLS PreMaster/Master Secret(Key)計算。

Master secret

上面已經提到，由于服務端和用戶端都有一份相同的PreMaster secret和随機數，這個随機數将作為後面産生Master secret的種子，結合PreMaster secret，用戶端和服務端将計算出同樣的Master secret。

Master secret是有系列的hash值組成的，它将作為資料加解密相關的secret的 Key Material 的一部分。Key Material最終解析出來的資料如下：

其中，write MAC key，就是session secret或者說是session key。Client write MAC key是用戶端發資料的session secret，Server write MAC secret是服務端發送資料的session key。MAC(Message Authentication Code)，是一個數字簽名，用來驗證資料的完整性，可以檢測到資料是否被串改。

關于Session Secret(Key)的計算請參考 Https SSL/TLS Session Secret(Key)計算。

2.6 應用資料傳輸

在所有的握手階段都完成之後，就可以開始傳送應用資料了。應用資料在傳輸之前，首先要附加上MAC secret，然後再對這個資料包使用write encryption key進行加密。在服務端收到密文之後，使用Client write encryption key進行解密，用戶端收到服務端的資料之後使用Server write encryption key進行解密，然後使用各自的write MAC key對資料的完整性包括是否被串改進行驗證。

2.7 總結

SSL用戶端（也是TCP的用戶端）在TCP連結建立之後，發出一個ClientHello來發起握手，這個消息裡面包含了自己可實作的算法清單和其它一些需要的消息，SSL的伺服器端會回應一個ServerHello，這裡面确定了這次通信所需要的算法，然後發過去自己的證書（裡面包含了身份和自己的公鑰）。Client在收到這個消息後會生成一個秘密消息，用SSL伺服器的公鑰加密後傳過去，SSL伺服器端用自己的私鑰解密後，會話密鑰協商成功，雙方可以用同一份會話密鑰來通信了。

3. 附：密鑰協商的形象化比喻

如果上面的說明不夠清晰，這裡我們用個形象的比喻，我們假設A與B通信，A是SSL用戶端，B是SSL伺服器端，加密後的消息放在方括号[]裡，以突出明文消息的差別。雙方的處理動作的說明用圓括号（）括起。

A：我想和你安全的通話，我這裡的對稱加密算法有DES,RC5,密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。

B：我們用DES－RSA－SHA這對組合好了。

這是我的證書，裡面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發給A）。

目前沒有别的可說的了。

A：（檢視證書上B的名字是否無誤，并通過手頭早已有的CA的證書驗證了B的證書的真實性，如果其中一項有誤，發出警告并斷開連接配接，這一步保證了B的公鑰的真實性）

（産生一份秘密消息，這份秘密消息處理後将用作加密密鑰，加密初始化向量（IV）和hmac的密鑰。将這份秘密消息-協定中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由于用了B的公鑰，保證了第三方無法竊聽）

我生成了一份秘密消息，并用你的公鑰加密了，給你（把ClientKeyExchange發給B）

注意，下面我就要用加密的辦法給你發消息了！

（将秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）

[我說完了]

B：（用自己的私鑰将ClientKeyExchange中的秘密消息解密出來，然後将秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時雙方已經安全的協商出一套加密辦法了）

注意，我也要開始用加密的辦法給你發消息了！

[我說完了]

A: [我的秘密是...]

B: [其它人不會聽到的...]

4. SSL安全性

SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨論， 目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以通過man in the middle攻擊來截獲https的消息。

從上面的原理可知，SSL的結構是嚴謹的，問題一般出現在實際不嚴謹的應用中。常見的攻擊就是middle in the middle攻擊，它是指在A和B通信的同時，有第三方C處于信道的中間，可以完全聽到A與B通信的消息，并可攔截，替換和添加這些消息。

1. SSL可以允許多種密鑰交換算法，而有些算法，如DH，沒有證書的概念，這樣A便無法驗證B的公鑰和身份的真實性，進而C可以輕易的冒充，用自己的密鑰與雙方通信，進而竊聽到别人談話的内容。

   而為了防止middle in the middle攻擊，應該采用有證書的密鑰交換算法。

2. 有了證書以後，如果C用自己的證書替換掉原有的證書之後，A的浏覽器會彈出一個警告框進行警告，但又有多少人會注意這個警告呢？
3. 由于美國密碼出口的限制，IE，netscape等浏覽器所支援的加密強度是很弱的，如果隻采用浏覽器自帶的加密功能的話，理論上存在被破解可能。

5. 代理

下面探讨一下SSL的代理是怎樣工作的

當在浏覽器裡設定了https的代理，而且裡輸入了

https://www.example.com

之後，浏覽器會與proxy建立tcp連結，然後向其發出這麼一段消息：

CONNECT server.example.com:443 HTTP/1.1
   Host: server.example.com:443
           

然後proxy會向webserver端建立tcp連接配接,之後，這個代理便完全成了個内容轉發裝置。浏覽器與web server會建立一個安全通道，是以這個安全通道是端到端的，盡管所有的資訊流過了proxy,但其内容proxy是無法解密和改動的（當然要由證書的支援，否則這個地友善是個man in the middle攻擊的好場所，見上面的安全部分）。

CA憑證以及如何使用OpenSSL自簽署，見文章OpenSSL自簽署證書 。

6. 參考

• Https(SSL/TLS)原理詳解
• SSL與TLS的差別以及介紹
• SSL/TLS協定運作機制的概述
• SSL/TLS/WTLS原理
• Transport Layer Security (TLS)
• 傳輸層安全協定
• Survival guides - TLS/SSL and SSL (X.509) Certificates

原文連結位址：http://seanlook.com/2015/01/07/tls-ssl-understand/

轉自：https://segmentfault.com/a/1190000002554673