TLS 1.0協議

TLS1.0 協議發佈於1999年初。該協議可在Internet中提供給通訊雙方一條私有信道，即對通訊消息進行加密。該協議主要描述了通訊密鑰協商的方法與通訊格式的定義。分別由TLS Handshake Protocol 和 TLS Record Protocol兩個子協議進行描述。雖然TLS1.0已經退出了歷史舞臺，但其最初的TLS設計核心過程並沒有太大變化。所以有助於理解TLS協議的執行過程。

TCP協議爲TLS協議提供傳輸層服務， TLS Record Protocol在TCP協議層之上，向上提供兩種服務：

1. 通訊雙方的鏈接是私有的。通訊過程時的數據加密方式採用對稱加密。對於每一條鏈接來講，都有其惟一的對稱密鑰。用於加密數據的對稱密鑰是由TLS Handshake Protocol協商獲得的。在特殊狀況下，TLS Record Protocol層的數據也能夠不被加密。
2. 通訊雙方的鏈接是可靠的。消息在傳遞過程當中須要包含消息校驗碼（MAC），消息校驗碼採用Hash函數對消息進行摘要得出。

TLS Handshake Protocol提供密鑰協商服務，該協議容許服務器與客戶端相互驗證對方身份、協商對稱加密算法及對稱密鑰：

1. 使用公鑰加密體系對通訊雙方進行身份認證。身份認證過程的參與者是可選的，但至少對其中一方進行驗證。
2. 協商過程當中的共享祕密是安全的。協商祕密的過程當中，攻擊者難以經過截獲協商過程當中的數據，來推導出通訊雙方的共享祕密。
3. 協商過程是可信的。攻擊者不可能修改協商過程當中的數據

在TLS中，多數操做是須要消息MAC（消息認證碼）來驗證消息的真實性。傳統的消息認證碼，僅僅是對消息進行Hash得以獲取，所以易於攻擊者對其進行僞造。若經過對MAC生成過程當中添加私有祕密的方法來生成消息認證碼，僞造過程將十分困難（由於必需要猜出私有祕密）。使用HMAC做爲消息認證碼。HMAC的生成可使用多種不一樣的Hash算法。

TLS Record Protocol

TLS記錄協議將上層來的數據切成若干的數據塊，可選擇性地對這些數據塊進行壓縮，計算其MAC值，以及對數據進行加密，最後將通過加工後的數據放置在TCP協議中傳遞出去。一樣地，該協議會將接受到的TCP數據，進行解密、驗證、解壓、重組等過程，最後向上交付數據。

TLS Record Protocol包含四個子協議，分別爲:

1. handshake protocol
2. alert protocol
3. change cipher spec protocol
4. application data protocol

TLS Handshake Protocol

TLS握手協議包含三個字協議：

1. 選擇使用Record Protocol協商得到的加密參數
2. 驗證通訊雙方身份
3. 提供協商使用的加密參數，並報告錯誤

加密所需的參數由該協議協商得出，在客戶端與服務器開始通訊時，雙方須要一致協議版本、選擇加密算法，對通訊雙方進行身份認證，並使用公鑰加密體系生成共享祕密。該協議的規程以下：

1. Client首先發送一個ClientHello給Server，該報文中包含版本號、隨機數（Client Random）及支持的加密算法
2. Server返回包括 ServerHello、Certificate（可選，服務器的認證證書）、ServerKeyExchange （可選）、CertificateRequest（可選）、ServerHelloDone 做爲應答，返回給Client，該報文中包含隨機數（Server Random）
3. Client根據Server的ServerHello應答作出相應 Certificate（可選，當服務器應答中包含CertificateRequest時，須要提供客戶端認證證書）、ClientKeyExchange、CertificateVerify（可選）、[ChangeCipherSpec]、Finish。當且僅當Client掌握公鑰時，該報文中包含客戶端產生的新的隨機數，該隨機數使用服務器Certificate中的公鑰進行加密（Premaster secret）
4. 服務器返回 [ChangeCipherSpec] Finished，當且僅當Server掌握公鑰時，該報文中包含服務器產生的新的隨機數，該隨機數使用客戶端的Certificate中的公鑰進行加密（Premaster secret）。該過程，對方將使用三個隨機數產生session key（會話密鑰）

值得注意的是，整個握手階段是不加密的，所以攻擊者可獲取到雙方選擇的加密方法以及前兩個隨機數，整個會話的安全性依賴於第三個隨機數。至此完成TLS握手過程。