相關學習資料html
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協議格式segmentfault
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其實是共同工做的兩層協議組成，以下圖所示ruby
對於這張SSL的層次結構圖，咱們須要牢記幾點:服務器
1. 無論是TCP/IP的4層協議、仍是ISO的7層協議，它們都是基於接口式的鬆耦合層次結構的協議，也就是說，只要遵循接口的格式，中間能夠插入任意的協議層，這也是SSL能存在的理論依據 2. 所謂的高層次、低層次，本質上是一種"數據封裝"的概念，高層的數據封裝進底層的數據包，而後加上某些數據包的頭部，僅此而已 3. "SSL握手協議"、"SSL改變密碼格式協議"、"SSL警告協議"、"HTTP.."咱們均可以當作是"SSL記錄協議"封裝的上層應用層數據，它們都基於下層的"SSL記錄協議"進行封裝，從而實現本身
的功能。至於爲何會有這麼多的上層協議，也很容易理解，由於SSL是一種加密目的的協議，這類密碼學相關的協議在初始化(握手)的過程當中廣泛都須要一些列的交互過程，握手協議來支持
對整體的結構有了初步認識以後，咱們接下來開始深刻學習SSL的協議格式，在學習的過程當中，咱們應該時常回憶上面的這張總體結構圖，理解它們的層次關係網絡
0x1: SSL記錄協議app
咱們知道，SSL記錄協議是用來封裝上層協議數據的協議，在SSL協議中，全部的傳輸數據都被封裝在記錄中。記錄是由:dom
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、RC四、RC二、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)
1. CLIENT_HELLO
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