SSL、TLS協議格式、HTTPS通訊過程、RDP SSL通訊過程
阿新 • • 發佈：2019-01-22
相關學習資料
http://www.360doc.com/content/10/0602/08/1466362_30787868.shtml http://www.gxu.edu.cn/college/hxhgxy/sec/COURSE/ch13/1.htm http://www.rfc-editor.org/rfc/rfc6101.txt http://3600.1kapp.com/?p=546 http://wiki.mbalib.com/wiki/SSL%E4%BF%AE%E6%94%B9%E5%AF%86%E6%96%87%E5%8D%8F%E8%AE%AE http://www.h3c.com.cn/Products___Technology/Technology/Security_Encrypt/Other_technology/Technology_book/200812/622834_30003_0.htmhttp://technet.microsoft.com/zh-cn/library/cc785811(v=ws.10).aspx http://www.rfc-editor.org/rfc/rfc2246.txt
以下文章非常詳細的介紹了SSL、TLS協議內容，貼上自： http://www.cnblogs.com/littlehann/p/3733469.html
目錄
1. SSL協議格式 2. TLS協議格式 3. HTTPS、SSL/TLS初始化協商過程 4. RDP SSL通訊過程
1. SSL協議格式
SSL(Secure socket Layer 安全套接層協議)指使用公鑰和私鑰技術組合的安全網路通訊協議。SSL協議是網景公司(Netscape)推出的基於WEB應用的安全協議，SSL協議指定了一種在應用程式協議(如Http、Telenet、NMTP和FTP等)和TCP/IP協議之間提供資料安全性分層的機制，它為TCP/IP連線提供資料加密、伺服器認證、訊息完整性以及可選的客戶機認證，主要用於提高應用程式之間資料的安全性，對傳送的資料進行加密和隱藏，確保資料在傳送中不被改變,即確保資料的完整性。
SSL 以對稱密碼技術和公開密碼技術相結合，可以實現如下三個通訊目標：
1. 祕密性: SSL客戶機和伺服器之間傳送的資料都經過了加密處理,網路中的非法竊聽者所獲取的資訊都將是無意義的密文資訊 2. 完整性: SSL利用密碼演算法和雜湊(HASH)函式,通過對傳輸資訊特徵值的提取來保證資訊的完整性,確保要傳輸的資訊全部到達目的地,可以避免伺服器和客戶機之間的資訊受到破壞。 3. 認證性:利用證書技術和可信的第三方認證，可以讓客戶機和伺服器相互識別對方的身份。為了驗證證書持有者是其合法使用者(而不是冒名使用者)，SSL要求證書持有者在握手時相互交換數字證 書，通過驗證來保證對方身份的合法性。
SSL協議位於TCP/IP協議模型的網路層和應用層之間，使用TCP來提供一種可靠的端到端的安全服務，它是客戶/伺服器應用之間的通訊不被攻擊竊聽，並且始終對伺服器進行認證，還可以選擇對客戶進行認證。
SSL協議應用層來說是透明的，我們在編寫基於SSL的HTTPS應用時，無論客戶端還是服務端都不需要考慮SSL的存在
SSL協議在應用層通訊之前就已經完成:
1) 加密演算法 2) 通訊金鑰的協商 3) 伺服器認證工作
在此之後,應用層協議所傳送的資料都被加密。SSL實際上是共同工作的兩層協議組成，如下圖所示
對於這張SSL的層次結構圖，我們需要牢記幾點:
1. 不管是TCP/IP的4層協議、還是ISO的7層協議，它們都是基於介面式的鬆耦合層次結構的協議，也就是說，只要遵循介面的格式，中間可以插入任意的協議層，這也是SSL能存在的理論依據 2. 所謂的高層次、低層次，本質上是一種"資料封裝"的概念，高層的資料封裝進底層的資料包，然後加上某些資料包的頭部，僅此而已 3. "SSL握手協議"、"SSL改變密碼格式協議"、"SSL警告協議"、"HTTP.."我們都可以看成是"SSL記錄協議"封裝的上層應用層資料，它們都基於下層的"SSL記錄協議"進行封裝，從而實現自己 的功能。至於為什麼會有這麼多的上層協議，也很容易理解，因為SSL是一種加密目的的協議，這類密碼學相關的協議在初始化(握手)的過程中普遍都需要一些列的互動過程，握手協議來支援
對總體的結構有了初步認識之後，我們接下來開始深入學習SSL的協議格式，在學習的過程中，我們應該時常回憶上面的這張整體結構圖，理解它們的層次關係
0x1: SSL記錄協議
我們知道，SSL記錄協議是用來封裝上層協議資料的協議，在SSL協議中，所有的傳輸資料都被封裝在記錄中。記錄是由:
1) 記錄頭 2) 長度不為0的記錄資料
組成的。"所有"的SSL通訊都使用SSL記錄層，記錄協議封裝上層的:
1) 握手協議 2) 警告協議 3) 改變密碼格式協議 4) 應用資料協議
SSL記錄協議定義了要傳輸資料的格式，它位於一些可靠的的傳輸協議之上(如TCP)，用於各種更高層協議的封裝，記錄協議主要完成:
1) 分組、組合 2) 壓縮、解壓縮 3) 以及訊息認證 4) 加密傳輸等
1. 分段 每個上層應用資料被分成2^14位元組或更小的資料塊 2. 壓縮 壓縮是可選的，並且是無失真壓縮，壓縮後內容長度的增加不能超過1024位元組。 3. 在壓縮資料上計算訊息認證MAC。 4. 對壓縮資料及MAC進行加密。 5. 增加SSL記錄頭(內容型別、主版本、次版本、壓縮長度)
最終經過封裝後的SSL記錄資料包格式如下
1. 內容型別(8位): 封裝的高層協議 1) 握手協議(handshake): 22 2) 警告協議(alert): 21 3) 改變密碼格式協議(change_cipher_spec): 20 4) 應用資料協議(application_data): 23 2. 主要版本(8位): 使用的SSL主要版本，目前的SSL版本是SSL v3，所以這個欄位的值只有3這個值 3. 次要版本(8位): 使用的SSL次要版本。對於SSL v3.0，值為0。 4. 資料包長度(16位): 1) 明文資料包: 這個欄位表示的是明文資料以位元組為單位的長度 2) 壓縮資料包 這個欄位表示的是壓縮資料以位元組為單位的長度 3) 加密資料包 這個欄位表示的是加密資料以位元組為單位的長度 5. 記錄資料 這個區塊封裝了上層協議的資料 1) 明文資料包: opaque fragment[SSLPlaintext.length]; 2) 壓縮資料包 opaque fragment[SSLCompressed.length]; 3) 加密資料包 3.1) 流式(stream)加密: GenericStreamCipher 3.1.1) opaque content[SSLCompressed.length]; 3.1.2) opaque MAC[CipherSpec.hash_size]; 3.2) 分組(block)加密: GenericBlockCipher 3.2.1) opaque content[SSLCompressed.length]; 3.2.2) opaque MAC[CipherSpec.hash_size]; 3.2.3) uint8 padding[GenericBlockCipher.padding_length]; 3.2.4) uint8 padding_length; 6. MAC(0、16、20位)
0x2: SSL握手協議
握手協議是客戶機和伺服器用SSL連線通訊時使用的"第一個"子協議，握手協議包括客戶機與伺服器之間的一系列訊息。
SSL握手協議被封裝在記錄協議中，該協議允許伺服器與客戶機在應用程式傳輸和接收資料之前互相認證、協商加密演算法和金鑰。在初次建立SSL連線時，伺服器與客戶機交換一系列訊息。
這些訊息交換能夠實現如下操作：
1. 客戶機認證伺服器 2. 協商客戶機與伺服器選擇雙方都支援的密碼演算法 3. 可選擇的伺服器認證客戶 4. 使用公鑰加密技術生成共享金鑰 5. 建立加密SSL連線
SSL握手協議報文格式如下
1. 型別(Type)(1位元組): 該欄位指明使用的SSL握手協議報文型別 1) hello_request: 2) client_hello: 3) server_hello: 4) certificate: 5) server_key_exchange: 6) certificate_request: 7) server_done: 8) certificate_verify: 9) client_key_exchange: 10) finished: 2. 長度(Length)(3位元組): 以位元組為單位的報文長度。 3. 內容(Content)(≥1位元組): 對應報文型別的的實際內容、引數 1) hello_request: 空 2) client_hello: 2.1) 版本(ProtocolVersion) 代表客戶端可以支援的SSL最高版本號 2.1.1) 主版本: 3 2.1.2) 次版本: 0 2.2) 隨機數(Random) 客戶端產生的一個用於生成主金鑰(master key)的32位元組的隨機數(主金鑰由客戶端和服務端的隨機數共同生成) 2.2.1) uint32 gmt_unix_time; 2.2.2) opaque random_bytes[28]; 4+28=32位元組 2.3) 會話ID: opaque SessionID<0..32>; 2.4) 密文族(加密套件): 一個客戶端可以支援的密碼套件列表。這個列表會根據使用優先順序排列，每個密碼套件都指定了"金鑰交換演算法(Deffie-Hellman金鑰交換演算法、基於RSA的金鑰交換和另一種實 現在Fortezza chip上的金鑰交換)"、"加密演算法(DES、RC4、RC2、3DES等)"、"認證演算法(MD5或SHA-1)"、"加密方式(流、分組)" 2.4.1) CipherSuite SSL_RSA_WITH_NULL_MD5 2.4.2) CipherSuite SSL_RSA_WITH_NULL_SHA 2.4.3) CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 2.4.4) CipherSuite SSL_RSA_WITH_RC4_128_MD5 2.4.5) CipherSuite SSL_RSA_WITH_RC4_128_SHA 2.4.6) CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 2.4.7) CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA 2.4.8) CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA 2.4.9) CipherSuite SSL_RSA_WITH_DES_CBC_SHA 2.4.10) CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA 2.4.11) CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA 2.4.12) CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA 2.4.13) CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA 2.4.14) CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA 2.4.15) CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA 2.4.16) CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA 2.4.17) CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 2.4.18) CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA 2.4.19) CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA 2.4.20) CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 2.4.21) CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA 2.4.22) CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA 2.4.23) CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 2.4.24) CipherSuite SSL_DH_anon_WITH_RC4_128_MD5 2.4.25) CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA 2.4.26) CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA 2.4.27) CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA 2.4.28) CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA 2.4.29) CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA 2.4.30) CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA 2.5) 壓縮方法 3) server_hello: 3.1) 版本(ProtocolVersion) 代表服務端"採納"的最高支援的SSL版本號 3.1.1) 主版本: 3 3.1.2) 次版本: 0 3.2) 隨機數(Random) 服務端產生的一個用於生成主金鑰(master key)的32位元組的隨機數(主金鑰由客戶端和服務端的隨機數共同生成) 3.2.1) uint32 gmt_unix_time; 3.2.2) opaque random_bytes[28]; 4+28=32位元組 3.3) 會話ID: opaque SessionID<0..32>; 3.4) 密文族(加密套件): 代表服務端採納的用於本次通訊的的加密套件 3.5) 壓縮方法: 代表服務端採納的用於本次通訊的的壓縮方法 總體來看，server_hello就是服務端對客戶端的的迴應，表示採納某個方案 4) certificate: SSL伺服器將自己的"服務端公鑰證書(注意，是公鑰整數)"傳送給SSL客戶端 ASN.1Cert certificate_list<1..2^24-1>; 5) server_key_exchange: 1) RSA 執行RSA金鑰協商過程 1.1) RSA引數(ServerRSAParams) 1.1.1) opaque RSA_modulus<1..2^16-1>; 1.1.2) opaque RSA_exponent<1..2^16-1>; 1.2) 簽名引數(Signature) 1.2.1) anonymous: null 1.2.2) rsa 1.2.2.1) opaque md5_hash[16]; 1.2.2.2) opaque sha_hash[20]; 1.2.3) dsa 1.2.3.1) opaque sha_hash[20]; 2) diffie_hellman 執行DH金鑰協商過程 2.1) DH引數(ServerDHParams) 2.1.1) opaque DH_p<1..2^16-1>; 2.1.2) opaque DH_g<1..2^16-1>; 2.1.3) opaque DH_Ys<1..2^16-1>; 2.2) 簽名引數(Signature) 2.2.1) anonymous: null 2.2.2) rsa 2.2.2.1) opaque md5_hash[16]; 2.2.2.2) opaque sha_hash[20]; 2.2.3) dsa 2.2.3.1) opaque sha_hash[20]; 3) fortezza_kea 執行fortezza_kea金鑰協商過程 3.1) opaque r_s [128] 6) certificate_request: 6.1) 證書型別(CertificateType) 6.1.1) RSA_sign 6.1.2) DSS_sign 6.1.3) RSA_fixed_DH 6.1.4) DSS_fixed_DH 6.1.5) RSA_ephemeral_DH 6.1.6) DSS_ephemeral_DH 6.1.7) FORTEZZA_MISSI 6.2) 唯一名稱(DistinguishedName) certificate_authorities<3..2^16-1>; 7) server_done: 伺服器總是傳送server_hello_done報文，指示伺服器的hello階段結束 struct { } ServerHelloDone; 8) certificate_verify: 簽名引數(Signature) 8.1) anonymous: null 8.2) rsa 8.2.1) opaque md5_hash[16]; 8.2.2) opaque sha_hash[20]; 8.3) dsa 8.3.1) opaque sha_hash[20]; 9) client_key_exchange: 9.1) RSA 9.1.1) PreMasterSecret 9.1.1.1) ProtocolVersion 9.1.1.2) opaque random[46]; 9.2) diffie_hellman: opaque DH_Yc<1..2^16-1>; 9.3) fortezza_kea 9.3.1) opaque y_c<0..128>; 9.3.2) opaque r_c[128]; 9.3.3) opaque y_signature[40]; 9.3.4) opaque wrapped_client_write_key[12]; 9.3.5) opaque wrapped_server_write_key[12]; 9.3.6) opaque client_write_iv[24]; 9.3.7) opaque server_write_iv[24]; 9.3.8) opaque master_secret_iv[24]; 9.3.9) opaque encrypted_preMasterSecret[48]; 10) finished: 10.1) opaque md5_hash[16]; 10.2) opaque sha_hash[20];
0x3: SSL改變密碼協議
SSL修改密文協議的報文由值為1的單一位元組組成，只有一個"1"值
SSL修改密文協議的設計目的是為了保障SSL傳輸過程的安全性，因為SSL協議要求客戶端或伺服器端每隔一段時間必須改變其加解密引數。當某一方要改變其加解密引數時，就傳送一個簡單的訊息通知對方下一個要傳送的資料將採用新的加解密引數，也就是要求對方改變原來的安全引數。
0x4: SSL警告協議
SSL警告協議亦稱SSL告警協議、SSL報警協議，是用來為對等實體傳遞SSL的相關警告。如果在通訊過程中某一方發現任何異常，就需要給對方傳送一條警示訊息通告。
SSL報警協議報文由嚴重級別和警告程式碼兩部分組成
1. 嚴重級別(AlertLevel ) 1) Fatal Fatal級報警即致命級報警，它要求通訊雙方都要採取緊急措施，並終止會話，同時消除自己緩衝區相應的會話記錄 2) Waming Warning級報警即警告級報警的處理，通常是通訊雙方都只進行日誌記錄，它對通訊過程不造成影響 2. 警告程式碼 1) bad_record_mac：收到了不正確的MAC 2) unexpected_message：接收了不合適的報文 3) decompression_failure：解壓縮函式收到不適當的輸入。 4) illegal_parameter：握手報文中的一個欄位超出範圍或與其他欄位不相容。 5) certificate_revoked：證書已經被廢棄。 6) bad_certificate：收到的證書是錯誤的。 7) certificate_expired：證書已經過期。 8) handshake_failer：握手過程失敗。 9) no_certificate: 未提供證書 10) unsupported_certificate: 未支援的證書格式 11) certificate_unknown: 未知證書
2. TLS協議格式
TLS並不是一個新協議，它是SSL(準確的說是SSL v3)的強化版，在整個協議格式上，和SSL類似
http://www.rfc-editor.org/rfc/rfc2246.txt
1．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還補充定義了很多報警程式碼，如 1) 解密失敗(decryption_failed) 2) 記錄溢位(record_overflow) 3) 未知CA(unknown_ca) 4) 拒絕訪問(access_denied)等。 5. 密文族和客戶證書：SSLv3.0和TLS存在少量差別，即TLS"不支援": 1) Fortezza金鑰交換 2) 加密演算法 3) 客戶證書。 6. certificate_verify和finished訊息：SSLv3.0和TLS在用certificate_verify和finished訊息計算MD5和SHA-1雜湊碼時，計算的輸入有少許差別，但安全性相當。 7. 加密計算：TLS與SSLv3.0在計算主密值(master secret)時採用的方式不同。但都是以客戶端和服務端各自產生的隨機數Ramdom作為輸入 8. 填充：使用者資料加密之前需要增加的填充位元組。在SSL中，填充後的資料長度要達到密文塊長度的最小整數倍。而在TLS中，填充後的資料長度可以是密文塊長度的任意整數倍 (但填充的最大長度為255位元組)，這種方式可以防止基於對報文長度進行分析的攻擊。
2．TLS的主要增強內容
TLS的主要目標是使SSL更安全，並使協議的規範更精確和完善。TLS 在SSL v3.0 的基礎上，提供了以下增強內容：
1. 更安全的MAC演算法 2. 更嚴密的警報 3. "灰色區域"規範的更明確的定義
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還對何時應該傳送某些警報進行記錄。
3. HTTPS、SSL/TLS初始化協商過程
SSL通過握手過程在客戶端和伺服器之間協商會話引數，並建立會話。會話包含的主要引數有會話ID、對方的證書、加密套件（金鑰交換演算法、資料加密演算法和MAC演算法等）以及主金鑰（master secret）。通過SSL會話傳輸的資料，都將採用該會話的主金鑰和加密套件進行加密、計算MAC等處理。
不同情況下，SSL握手過程存在差異。下面將分別描述以下三種情況下的握手過程：
1. 只驗證伺服器的SSL握手過程 2. 驗證伺服器和客戶端的SSL握手過程 3. 恢復原有會話的SSL握手過程
1. 只驗證伺服器的SSL握手過程
1. Client Hello SSL客戶端通過Client Hello訊息向SSL服務端傳送: 1) 支援的SSL版本 2) 客戶端生成的一個用於生成主金鑰(master key)的32位元組的隨機數(主金鑰由客戶端和服務端的隨機數共同生成) 3) 會話ID 3) 加密套件 3.1) 加密演算法 3.2) 金鑰交換演算法 3.3) MAC演算法 3.4) 加密方式(流、分組) 4) 壓縮演算法(如果支援壓縮的話) 2. Server Hello SSL伺服器確定本次通訊採用的SSL版本和加密套件，並通過Server Hello訊息通知給SSL客戶端。如果SSL伺服器允許SSL客戶端在以後的通訊中重用本次會話，則SSL伺服器會為本次會話分配會 話ID，並通過Server Hello訊息傳送給SSL客戶端。 1) 服務端採納的本次通訊的SSL版本 2) 服務端生成的一個用於生成主金鑰(master key)的32位元組的隨機數(主金鑰由客戶端和服務端的隨機數共同生成) 3) 會話ID 3) 服務端採納的用於本次通訊的加密套件(從客戶端傳送的加密套件列表中選出了一個) 3.1) 加密演算法 3.2) 金鑰交換演算法 3.3) MAC演算法 3.4) 加密方式(流、分組) 4) 壓縮演算法(如果支援壓縮的話) 3. Certificate SSL伺服器將"攜帶自己公鑰資訊的數字證書"和到根CA整個鏈發給客戶端通過Certificate訊息傳送給SSL客戶端(整個公鑰檔案都發送過去)，客戶端使用這個公鑰完成以下任務: 1) 客戶端可以使用該公鑰來驗證服務端的身份，因為只有服務端有對應的私鑰能解密它的公鑰加密的資料 2) 用於對"premaster secret"進行加密，這個"premaster secret"就是用客戶端和服務端生成的Ramdom隨機數來生成的，客戶端用服務端的公鑰對其進行了加密後傳送給服務端 4. Server Key Exchange 金鑰交換階段(可選步驟)，之所以說是可選步驟，是因為只有在下列場景下這個步驟才會發生 1) 協商採用了RSA加密，但是服務端的證書沒有提供RSA公鑰 2) 協商採用了DH加密，但是服務端的證書沒有提供DH引數 3) 協商採用了fortezza_kea加密，但是服務端的證書沒有提供引數 總結來說，"Server Key Exchange"這個步驟是對上一步"Certificate"的一個補充，為了讓整個SSL握手過程能正常進行 5. Server Hello Done SSL伺服器傳送Server Hello Done訊息，通知SSL客戶端版本和加密套件協商結束 6. Client Key Exchange SSL客戶端驗證SSL伺服器的證書合法後，利用證書中的公鑰加密SSL客戶端隨機生成的"premaster secret"(通過之前客戶端、服務端分別生成的隨機數生成的)，並通過 Client Key Exchange訊息傳送給SSL伺服器。 注意，這一步完成後，客戶端和服務端都已經儲存了"主金鑰"(之所以這裡叫預備主金鑰，是因為還沒有投入使用)。這個"主金鑰"會用於之後的SSL通訊資料的加密 7. Change Cipher Spec SSL客戶端傳送Change Cipher Spec訊息，通知SSL伺服器後續報文將採用協商好的"主金鑰"和加密套件進行加密和MAC計算。 8. Finished SSL客戶端計算已互動的握手訊息(除Change Cipher Spec訊息外所有已互動的訊息)的Hash值，利用協商好的金鑰和加密套件處理Hash值(計算並新增MAC值、加密等)，並通過Finished訊息 傳送給SSL伺服器。SSL伺服器利用同樣的方法計算已互動的握手訊息的Hash值，並與Finished訊息的解密結果比較，如果二者相同，且MAC值驗證成功，則證明金鑰和加密套件協商成功。 9. Change Cipher Spec 同樣地，SSL伺服器傳送Change Cipher Spec訊息，通知SSL客戶端後續報文將採用協商好的金鑰和加密套件進行加密和MAC計算。 10. Finished SSL伺服器計算已互動的握手訊息的Hash值，利用協商好的金鑰和加密套件處理Hash值(計算並新增MAC值、加密等)，並通過Finished訊息傳送給SSL客戶端。SSL客戶端利用同樣的方法計算已 互動的握手訊息的Hash值，並與Finished訊息的解密結果比較，如果二者相同，且MAC值驗證成功，則證明金鑰和加密套件協商成功。 SSL客戶端接收到SSL伺服器傳送的Finished訊息後，如果解密成功，則可以判斷SSL伺服器是數字證書的擁有者，即SSL伺服器身份驗證成功，因為只有擁有私鑰的SSL伺服器才能從 Client Key Exchange訊息中解密得到premaster secret，從而間接地實現了SSL客戶端對SSL伺服器的身份驗證。
2. 驗證伺服器和客戶端的SSL握手過程
"驗證伺服器和客戶端的SSL握手過程"和"只驗證伺服器的SSL握手過程"整體過程類似，只是多了服務端向客戶端要求傳送證明客戶端身份的證書、以及客戶端傳送證書的過程
1. Client Hello SSL客戶端通過Client Hello訊息向SSL服務端傳送: 1) 支援的SSL版本 2) 客戶端生成的一個用於生成主金鑰(master key)的32位元組的隨機數(主金鑰由客戶端和服務端的隨機數共同生成) 3) 會話ID 3) 加密套件 3.1) 加密演算法 3.2) 金鑰交換演算法 3.3) MAC演算法 3.4) 加密方式(流、分組) 4) 壓縮演算法(如果支援壓縮的話) 2. Server Hello SSL伺服器確定本次通訊採用的SSL版本和加密套件，並通過Server Hello訊息通知給SSL客戶端。如果SSL伺服器允許SSL客戶端在以後的通訊中重用本次會話，則SSL伺服器會為本次會話分配 會話ID，並通過Server Hello訊息傳送給SSL客戶端。 1) 服務端採納的本次通訊的SSL版本 2) 服務端生成的一個用於生成主金鑰(master key)的32位元組的隨機數(主金鑰由客戶端和服務端的隨機數共同生成) 3) 會話ID 3) 服務端採納的用於本次通訊的加密套件(從客戶端傳送的加密套件列表中選出了一個) 3.1) 加密演算法 3.2) 金鑰交換演算法 3.3) MAC演算法 3.4) 加密方式(流、分組) 4) 壓縮演算法(如果支援壓縮的話) 3. Certificate SSL伺服器將"攜帶自己公鑰資訊的數字證書"和到根CA整個鏈發給客戶端通過Certificate訊息傳送給SSL客戶端(整個公鑰檔案都發送過去)，客戶端使用這個公鑰完成以下任務: 1) 客戶端可以使用該公鑰來驗證服務端的身份，因為只有服務端有對應的私鑰能解密它的公鑰加密的資料 2) 用於對"premaster secret"進行加密，這個"premaster secret"就是用客戶端和服務端生成的Ramdom隨機數來生成的，客戶端用服務端的公鑰對其進行了加密後傳送給服務端 4. Server Key Exchange 金鑰交換階段(可選步驟)，之所以說是可選步驟，是因為只有在下列場景下這個步驟才會發生 1) 協商採用了RSA加密，但是服務端的證書沒有提供RSA公鑰 2) 協商採用了DH加密，但是服務端的證書沒有提供DH引數 3) 協商採用了fortezza_kea加密，但是服務端的證書沒有提供引數 總結來說，"Server Key Exchange"這個步驟是對上一步"Certificate"的一個補充，為了讓整個SSL握手過程能正常進行 5. Client Certificate Request 伺服器可以向客戶傳送certificate_request請求證書，即服務端需要客戶端證明自己的身份 6. Server Hello Done SSL伺服器傳送Server Hello Done訊息，通知SSL客戶端版本和加密套件協商結束 7. Client Certificate 客戶端(瀏覽器)向伺服器傳送自己的客戶端證書，以證明自己的身份 8. Client Key Exchange SSL客戶端驗證SSL伺服器的證書合法後，利用證書中的公鑰加密SSL客戶端隨機生成的"premaster secret"(通過之前客戶端、服務端分別生成的隨機數生成的)，並通過 Client Key Exchange訊息傳送給SSL伺服器。 注意，這一步完成後，客戶端和服務端都已經儲存了"主金鑰"(之所以這裡叫預備主金鑰，是因為還沒有投入使用)。這個"主金鑰"會用於之後的SSL通訊資料的加密 9. Certificate Verify 客戶可能傳送client_verify報文來校驗客戶端傳送的證書 10. Change Cipher Spec SSL客戶端傳送Change Cipher Spec訊息，通知SSL伺服器後續報文將採用協商好的"主金鑰"和加密套件進行加密和MAC計算。 11. Finished SSL客戶端計算已互動的握手訊息(除Change Cipher Spec訊息外所有已互動的訊息)的Hash值，利用協商好的金鑰和加密套件處理Hash值(計算並新增MAC值、加密等)，並通過Finished 訊息傳送給SSL伺服器。SSL伺服器利用同樣的方法計算已互動的握手訊息的Hash值，並與Finished訊息的解密結果比較，如果二者相同，且MAC值驗證成功，則證明金鑰和加密套件協商成功。 12. Change Cipher Spec 同樣地，SSL伺服器傳送Change Cipher Spec訊息，通知SSL客戶端後續報文將採用協商好的金鑰和加密套件進行加密和MAC計算。 13. Finished SSL伺服器計算已互動的握手訊息的Hash值，利用協商好的金鑰和加密套件處理Hash值(計算並新增MAC值、加密等)，並通過Finished訊息傳送給SSL客戶端。SSL客戶端利用同樣的方法計算已 互動的握手訊息的Hash值，並與Finished訊息的解密結果比較，如果二者相同，且MAC值驗證成功，則證明金鑰和加密套件協商成功。 SSL客戶端接收到SSL伺服器傳送的Finished訊息後，如果解密成功，則可以判斷SSL伺服器是數字證書的擁有者，即SSL伺服器身份驗證成功，因為只有擁有私鑰的SSL伺服器才能從 Client Key Exchange訊息中解密得到premaster secret，從而間接地實現了SSL客戶端對SSL伺服器的身份驗證。
3. 只驗證服務端的TLS握手過程
SSL握手階段1: Clien Hello
SSL握手階段2: Server Hello、Certificate、Server Key Exchange、Server Hello Done
可以看到，正如我們在學習協議格式的時候看到的，SSL/TLS的高層協議資料都被封裝在了下層的"記錄協議資料包"中，統一封裝傳送給客戶端
Server Hello
重點注意幾點，服務端生成了一個和客戶端不同的隨機數，同時，服務端在客戶端提供的加密套件列表中選擇了一個加密套件
Certificate
服務端將根證書全部發送給了客戶端
Server Key Exchange
服務端向客戶端傳送了DH過程所需要的引數(因為這個引數證書中沒有提供，所以需要"Server Key Exchange"來發送)
Server Hello Done
服務端傳送"Server Hello Done"訊息，標誌著握手階段2結束
SSL握手階段3: Client Key Exchange、Change Cipher Spec
Client Key Exchange
客戶端和服務端共同完成DH過程(上以階段中Serer Key Excha