SSL、TLS協定格式、HTTPS通信過程、RDP SSL通信過程
相關學習資料
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.htm
http://technet.microsoft.com/zh-cn/library/cc785811(v=ws.10).aspx
http://www.rfc-editor.org/rfc/rfc2246.txt 目錄
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 Exchange已經發送了DH的一半參數)
Change Cipher Spec
用戶端發送"Change Cipher Spec"(密鑰改變協定)通知服務端密鑰已經協商好了，以後咱們都用這個密鑰進行通信資料的加密吧
使用HTTS加密通道發送WEB資料
此時，所有的HTTPS通信資料都是處于加密狀态了，即使中間人在網絡中嗅探，也無法簡單地擷取明文
4. RDP SSL通信過程
1. SSL: (Secure Socket Layer 安全套接字層)，為Netscape所研發，用以保障在Internet上資料傳輸之安全，利用資料加密(Encryption)技術，可確定資料在網絡上之傳輸過程中不會被截取。目前版本為3.0。它已被廣泛地用于Web浏覽器與伺服器之間的身份認證和加密資料傳輸
SSL協定位于TCP/IP協定與各種應用層協定之間，為資料通訊提供安全支援。SSL協定可分為兩層
1) SSL記錄協定(SSL Record Protocol): 它建立在可靠的傳輸協定(如TCP)之上，為高層協定提供資料封裝、壓縮、加密等基本功能的支援
2) SSL握手協定(SSL Handshake Protocol): 它建立在SSL記錄協定之上，用于在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等
2. TLS: (Transport Layer Security，傳輸層安全協定)，用于兩個應用程式之間提供保密性和資料完整性
TLS 1.0是IETF(Internet Engineering Task Force Internet工程任務組)制定的一種新的協定，它建立在SSL 3.0協定規範之上，是SSL 3.0的後續版本，可以了解為SSL 3.1，它是寫入了 RFC 的。該協定由兩層組成 \
1) TLS 記錄協定(TLS Record): 較低的層為 TLS 記錄協定，位于某個可靠的傳輸協定(例如 TCP)上面
2) TLS 握手協定(TLS Handshake) 0x1: 密鑰協商過程——TLS握手(HANDSHAKE)
Handshake Protocol用來協商密鑰，協定的大部分内容就是通信雙方如何利用它來安全的協商出一份密鑰，There are 10 handshake message types in the TLS specification
|
|
Record Layer | Handshake Layer
| |
| | ...more messages
+----+----+----+----+----+----+----+----+----+------ - - - -+--
| 22 |vers| | | | | | | | |
|0x16|sion| | | | | | | |message |
/ / | \ \----\-----\ |
/ / | \ \
type: 22 / | \ handshake message length
/ type
/
length: arbitrary (up to 16k)
1. Record Type Values
1) CHANGE_CIPHER_SPEC 20 0x14
2) ALERT 21 0x15
3) HANDSHAKE 22 0x16
4) APPLICATION_DATA 23 0x17
2. Version Values
1) SSL 3.0 3,0 0x0300
2) TLS 1.0 3,1 0x0301
3) TLS 1.1 3,2 0x0302
4) TLS 1.2 3,3 0x0303
3. length(2 bytes)
4. Handshake Type Values
1) HELLO_REQUEST 0 0x00
2) CLIENT_HELLO 1 0x01
3) SERVER_HELLO 2 0x02
4) CERTIFICATE 11 0x0b
5) SERVER_KEY_EXCHANGE 12 0x0c
6) CERTIFICATE_REQUEST 13 0x0d
7) SERVER_DONE 14 0x0e
8) CERTIFICATE_VERIFY 15 0x0f
9) CLIENT_KEY_EXCHANGE 16 0x10
10) FINISHED 20 0x14 1. CLIENT_HELLO
2. SERVER_HELLO
3. CLIENT_KEY_EXCHANGE
0x2: 密鑰協商過程——算法協商(CHANGE_CIPHER_SPEC)
0x3: APPLICATION_DATA
0x4: ALERT
|
|
|
Record Layer | Alert Layer
|
|
+----+----+----+----+----+----+----+
| 21 | | | | | | |
|0x15| | | 0 | 2 | | |
+----+----+----+----+----+----+----+
/ / |
/ / |
type: 21 / |
/
/
length: 2
Alert severity dec hex
----------------------------------------
WARNING 1 0x01
FATAL 2 0x02
TLS 1.0 Alert descriptions dec hex
----------------------------------------
CLOSE_NOTIFY 0 0x00
UNEXPECTED_MESSAGE 10 0x0A
BAD_RECORD_MAC 20 0x14
DECRYPTION_FAILED 21 0x15
RECORD_OVERFLOW 22 0x16
DECOMPRESSION_FAILURE 30 0x1E
HANDSHAKE_FAILURE 40 0x28
NO_CERTIFICATE 41 0x29
BAD_CERTIFICATE 42 0x2A
UNSUPPORTED_CERTIFICATE 43 0x2B
CERTIFICATE_REVOKED 44 0x2C
CERTIFICATE_EXPIRED 45 0x2D
CERTIFICATE_UNKNOWN 46 0x2E
ILLEGAL_PARAMETER 47 0x2F
UNKNOWN_CA 48 0x30
ACCESS_DENIED 49 0x31
DECODE_ERROR 50 0x32
DECRYPT_ERROR 51 0x33
EXPORT_RESTRICTION 60 0x3C
PROTOCOL_VERSION 70 0x46
INSUFFICIENT_SECURITY 71 0x47
INTERNAL_ERROR 80 0x50
USER_CANCELLED 90 0x5A
NO_RENEGOTIATION 100 0x64 在RDP TLS1.0模式下，當密碼錯誤認證失敗時(應用層認證)，Server會傳回ALERT包
Relevant Link:
https://wiki.wireshark.org/TPKT
https://segmentfault.com/a/1190000002554673
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
https://tools.ietf.org/html/rfc5878 Copyright (c) 2014 LittleHann All rights reserved