傳輸層安全性協定（英語：Transport Layer Security，縮寫作 TLS），及其前身安全套接層（Secure Sockets Layer，縮寫作 SSL）是一種安全協定，目的是為網際網路通信，提供安全及數據完整性保障。網景公司（Netscape）在1994年推出首版網頁瀏覽器，網景導航者時，推出HTTPS協定，以SSL進行加密，這是SSL的起源。IETF將SSL進行標準化，1999年公布第一版TLS標準檔案。隨後又公布RFC 5246 （2008年8月）與 RFC 6176 （2011年3月）。在瀏覽器、電子郵件、即時通信、VoIP、網路傳真等應用程式中，廣泛支持這個協定。主要的網站，如Google、Facebook等也以這個協定來創建安全連線，傳送數據。目前已成為網際網路上保密通信的工業標準。
SSL包含記錄層（Record Layer）和傳輸層，記錄層協定確定傳輸層數據的封裝格式。傳輸層安全協定使用X.509認證，之後利用非對稱加密演算來對通信方做身份認證，之後交換對稱密鑰作為會談密鑰（Session key）。這個會談密鑰是用來將通信兩方交換的數據做加密，保證兩個套用間通信的保密性和可靠性，使客戶與伺服器套用之間的通信不被攻擊者竊聽。
基本介紹
- 中文名：傳輸層安全性協定
- 外文名：Transport Layer Security
- 縮寫：TLS
- 性質：安全協定
- 模型：主從式架構模型
- 領域：網路安全
概論,發展歷史,安全網路編程,SSL 1.0、2.0和3.0,TLS 1.0,TLS 1.1,TLS 1.2,TLS 1.3,過程,
概論
TLS協定的優勢是與高層的套用層協定（如HTTP、FTP、Telnet等）無耦合。套用層協定能透明地運行在TLS協定之上，由TLS協定進行創建加密通道需要的協商和認證。套用層協定傳送的數據在通過TLS協定時都會被加密，從而保證通信的私密性。
TLS協定是可選的，必須配置客戶端和伺服器才能使用。主要有兩種方式實現這一目標：一個是使用統一的TLS協定通信連線埠（例如：用於HTTPS的連線埠443）；另一個是客戶端請求伺服器連線到TLS時使用特定的協定機制（例如：郵件、新聞協定和STARTTLS）。一旦客戶端和伺服器都同意使用TLS協定，他們通過使用一個握手過程協商出一個有狀態的連線以傳輸數據。通過握手，客戶端和伺服器協商各種參數用於創建安全連線：
- 當客戶端連線到支持TLS協定的伺服器要求創建安全連線並列出了受支持的密碼組合（加密密碼算法和加密哈希函式放淚旋），握手開始。
- 伺服器從該列表中決定加密和散列函式，並通知客戶端。
- 伺服器發煉茅舉回其數字證書，此證書通常包含伺服器的名稱、受信任的證書頒發犁蜜良機構（CA）和伺服器的公鑰。
- 客戶端確認其頒發的證書的有效性。
- 為了生成會話密鑰用於安全連線，客戶端使用伺服器的公鑰加密隨機生成的密鑰，並將其傳送到伺服器，只有伺服器才能使用自己的私鑰解密。
- 利用隨機數，雙方生成用於加密和解密的對稱密鑰。這就是TLS協定的握手，握手完畢後的連線是安全的，直到連線（被）關閉。如果上述任何一個步驟失敗，TLS握手過程就戀朽試會失敗，並且斷開所有的連線。
發展歷史
安全網路編程
早期的研究工作，為方便改造原有網路應用程式，在1993年已經有了相似的Berkeley套接字安全傳輸層API方法。
SSL 1.0、2.0和3.0
基礎算法由作為網景公司的首席科學家塔希爾·蓋莫爾（Taher Elgamal）編寫，所以他被人稱為“SSL之父”頸抹達享。
2014年10月，Google發布在SSL 3.0中發現設計缺陷，建議禁用此一協定。攻擊者可以向TLS傳送虛假錯誤提示，然後將安全連線強行降級到過時且不安全的SSL 3.0，然後就可以利用其中的設計漏洞竊取敏感信息。Google在自己公司相關產品中陸續禁止向後兼容，強制使用TLS協定。Mozilla也在11月25日發布的Firefox34中徹底禁用了SSL 3.0。微軟同樣發出了安全通告。
- 1.0版本從未公開過，因為存在嚴重的安全漏洞。牛捆煉凶
- 2.0版本在1995年2月發布，但因為存在數個嚴重的安全漏洞而被3.0版本替代。
- 3.0版本在1996年發布，是由網景工程師Paul Kocher、Phil Karlton和Alan Freier完全重新設計的。較新版本的SSL/TLS基於SSL 3.0。SSL 3.0作為歷史項永文獻IETF通過RFC 6101發表。
TLS 1.0
IETF將SSL標準化，即RFC 2246，並將其稱為TLS（Transport Layer Security）。從技術上講，TLS 1.0與SSL 3.0的差異非常微小。但正如RFC所述"the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0"（本協定和SSL 3.0之間的差異並不是顯著，卻足以排除TLS 1.0和SSL 3.0之間的互操作性）。TLS 1.0包括可以降級到SSL 3.0的實現，這削弱了連線的安全性。
TLS 1.1
TLS 1.1在RFC 4346中定義，於2006年4月發表，它是TLS 1.0的更新。在此版本中的差異包括：
- 添加對CBC攻擊的保護：
- 更改分組密碼模式中的填充錯誤。
支持IANA登記的參數。
TLS 1.2
TLS 1.2在RFC 5246中定義，於2008年8月發表。它基於更早的TLS 1.1規範。主要區別包括：
- 可使用密碼組合選項指定在完成訊息的哈希認證中使用SHA-256替換MD5-SHA-1算法，但完成訊息中哈希值的長度仍然被截斷為96位。
- 在握手期間MD5-SHA-1組合的數字簽名被替換為使用單一Hash方法，默認為SHA-1。
- 增強伺服器和客戶端指定Hash和簽名算法的能力。
- 擴大經過身份驗證的加密密碼，主要用於GCM和CCM模式的AES加密的支持。
- 添加TLS擴展定義和AES密碼組合。所有TLS版本在2011年3月發布的RFC 6176中刪除了對SSL的兼容，這樣TLS會話將永遠無法協商使用的SSL 2.0以避免安全問題。
TLS 1.3
截至2018年3月21日，TLS 1.3是一個已經成為建議標準（Proposed Standard）的網際網路草案。它基於更早的TLS 1.2規範，與TLS 1.2的主要區別包括：
- 將密鑰協商和認證算法從密碼包中分離出來。
- 移除脆弱和較少使用的命名橢圓曲線支持（參見橢圓曲線密碼學）
- 移除MD5和SHA-224密碼散列函式的支持
- 請求數字簽名，即便使用之前的配置
- 集成HKDF和半短暫DH提議
- 替換使用PSK和票據的恢復
- 支持1-RTT握手並初步支持0-RTT
- 通過在(EC)DH密鑰協定期間使用臨時密鑰來保證完善的前向安全性。
- 禁止用於向後兼容性的SSL和RC4協商
- 集成會話散列的使用
- 棄用記錄層版本號和凍結數以改進向後兼容性
- 將一些安全相關的算法細節從附錄移動到標準，並將ClientKeyShare降級到附錄
- 添加帶有Poly1305訊息驗證碼的ChaCha20流加密
- 添加Ed25519和Ed448數字簽名算法
- 添加x25519和x448密鑰交換協定
過程
以下簡要介紹SSL協定的工作方式。客戶端要收發幾個握手信號：
- 傳送一個“ClientHello”訊息，內容包括：支持的協定版本，比如TLS1.0版，一個客戶端生成的隨機數（稍後用於生成“會話密鑰”），支持的加密算法（如RSA公鑰加密）和支持的壓縮算法。
- 然後收到一個“ServerHello”訊息，內容包括：確認使用的加密通信協定版本，比如TLS 1.0版本（如果瀏覽器與伺服器支持的版本不一致，伺服器關閉加密通信），一個伺服器生成的隨機數（稍後用於生成“對話密鑰”），確認使用的加密方法（如RSA公鑰加密），伺服器證書。
- 當雙方知道了連線參數，客戶端與伺服器交換證書（依靠被選擇的公鑰系統）。這些證書通常基於X.509，不過已有草案支持以OpenPGP為基礎的證書。
- 伺服器請求客戶端公鑰。客戶端有證書即雙向身份認證，沒證書時隨機生成公鑰。
- 客戶端與伺服器通過公鑰保密協商共同的主私鑰（雙方隨機協商），這通過精心謹慎設計的偽隨機數功能實現。結果可能使用Diffie-Hellman交換，或簡化的公鑰加密，雙方各自用私鑰解密。所有其他關鍵數據的加密均使用這個“主密鑰”。數據傳輸中記錄層（Record layer）用於封裝更高層的HTTP等協定。記錄層數據可以被隨意壓縮、加密，與訊息驗證碼壓縮在一起。每個記錄層包都有一個Content-Type段用以記錄更上層用的協定。
SSL 1.0、2.0和3.0
基礎算法由作為網景公司的首席科學家塔希爾·蓋莫爾（Taher Elgamal）編寫，所以他被人稱為“SSL之父”。
2014年10月，Google發布在SSL 3.0中發現設計缺陷，建議禁用此一協定。攻擊者可以向TLS傳送虛假錯誤提示，然後將安全連線強行降級到過時且不安全的SSL 3.0，然後就可以利用其中的設計漏洞竊取敏感信息。Google在自己公司相關產品中陸續禁止向後兼容，強制使用TLS協定。Mozilla也在11月25日發布的Firefox34中徹底禁用了SSL 3.0。微軟同樣發出了安全通告。
- 1.0版本從未公開過，因為存在嚴重的安全漏洞。
- 2.0版本在1995年2月發布，但因為存在數個嚴重的安全漏洞而被3.0版本替代。
- 3.0版本在1996年發布，是由網景工程師Paul Kocher、Phil Karlton和Alan Freier完全重新設計的。較新版本的SSL/TLS基於SSL 3.0。SSL 3.0作為歷史文獻IETF通過RFC 6101發表。
TLS 1.0
IETF將SSL標準化，即RFC 2246，並將其稱為TLS（Transport Layer Security）。從技術上講，TLS 1.0與SSL 3.0的差異非常微小。但正如RFC所述"the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0"（本協定和SSL 3.0之間的差異並不是顯著，卻足以排除TLS 1.0和SSL 3.0之間的互操作性）。TLS 1.0包括可以降級到SSL 3.0的實現，這削弱了連線的安全性。
TLS 1.1
TLS 1.1在RFC 4346中定義，於2006年4月發表，它是TLS 1.0的更新。在此版本中的差異包括：
- 添加對CBC攻擊的保護：
- 更改分組密碼模式中的填充錯誤。
支持IANA登記的參數。
TLS 1.2
TLS 1.2在RFC 5246中定義，於2008年8月發表。它基於更早的TLS 1.1規範。主要區別包括：
TLS 1.3
截至2018年3月21日，TLS 1.3是一個已經成為建議標準（Proposed Standard）的網際網路草案。它基於更早的TLS 1.2規範，與TLS 1.2的主要區別包括：
- 將密鑰協商和認證算法從密碼包中分離出來。
- 移除脆弱和較少使用的命名橢圓曲線支持（參見橢圓曲線密碼學）
- 移除MD5和SHA-224密碼散列函式的支持
- 請求數字簽名，即便使用之前的配置
- 集成HKDF和半短暫DH提議
- 替換使用PSK和票據的恢復
- 支持1-RTT握手並初步支持0-RTT
- 通過在(EC)DH密鑰協定期間使用臨時密鑰來保證完善的前向安全性。
- 禁止用於向後兼容性的SSL和RC4協商
- 集成會話散列的使用
- 棄用記錄層版本號和凍結數以改進向後兼容性
- 將一些安全相關的算法細節從附錄移動到標準，並將ClientKeyShare降級到附錄
- 添加帶有Poly1305訊息驗證碼的ChaCha20流加密
- 添加Ed25519和Ed448數字簽名算法
- 添加x25519和x448密鑰交換協定
過程
以下簡要介紹SSL協定的工作方式。客戶端要收發幾個握手信號：
- 傳送一個“ClientHello”訊息，內容包括：支持的協定版本，比如TLS1.0版，一個客戶端生成的隨機數（稍後用於生成“會話密鑰”），支持的加密算法（如RSA公鑰加密）和支持的壓縮算法。
- 然後收到一個“ServerHello”訊息，內容包括：確認使用的加密通信協定版本，比如TLS 1.0版本（如果瀏覽器與伺服器支持的版本不一致，伺服器關閉加密通信），一個伺服器生成的隨機數（稍後用於生成“對話密鑰”），確認使用的加密方法（如RSA公鑰加密），伺服器證書。
- 當雙方知道了連線參數，客戶端與伺服器交換證書（依靠被選擇的公鑰系統）。這些證書通常基於X.509，不過已有草案支持以OpenPGP為基礎的證書。
- 伺服器請求客戶端公鑰。客戶端有證書即雙向身份認證，沒證書時隨機生成公鑰。
- 客戶端與伺服器通過公鑰保密協商共同的主私鑰（雙方隨機協商），這通過精心謹慎設計的偽隨機數功能實現。結果可能使用Diffie-Hellman交換，或簡化的公鑰加密，雙方各自用私鑰解密。所有其他關鍵數據的加密均使用這個“主密鑰”。數據傳輸中記錄層（Record layer）用於封裝更高層的HTTP等協定。記錄層數據可以被隨意壓縮、加密，與訊息驗證碼壓縮在一起。每個記錄層包都有一個Content-Type段用以記錄更上層用的協定。
