簡介
傳輸層安全性協議（英語：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）。這個會談密鑰是用來将通信兩方交換的數據做加密，保證兩個應用間通信的保密性和可靠性，使客戶與服務器應用之間的通信不被攻擊者竊聽。
概論
TLS協議采用主從式架構模型，用于在兩個應用程序間透過網絡創建起安全的連接，防止在交換數據時受到竊聽及篡改。
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
SSL（Secure Sockets Layer）是網景公司（Netscape）設計的主要用于Web的安全傳輸協議，這種協議在Web上獲得了廣泛的應用。
基礎算法由作為網景公司的首席科學家塔希爾·蓋莫爾（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攻擊的保護：
隐式IV被替換成一個顯式的IV。
更改分組密碼模式中的填充錯誤。
支持IANA登記的參數。
TLS 1.2
TLS 1.2在RFC 5246中定義，于2008年8月發表。它基于更早的TLS 1.1規範。主要區别包括：
可使用密碼組合選項指定僞随機函數使用SHA-256替換MD5-SHA-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
參見：來回通信延遲
TLS 1.3在RFC 8446中定義，于2018年8月發表。它基于更早的TLS 1.2規範，與TLS 1.2的主要區别包括：
将密鑰協商和認證算法從密碼包中分離出來。
移除脆弱和較少使用的命名橢圓曲線支持（參見橢圓曲線密碼學）。
移除MD5和SHA-224密碼散列函數的支持。
請求數字簽名，即便使用之前的配置。
集成HKDF和半短暫DH提議。
替換使用PSK和票據的恢複。
支持1-RTT握手并初步支持0-RTT。
通過在(EC)DH密鑰協議期間使用臨時密鑰來保證完善的前向安全性。
放棄許多不安全或過時特性的支持，包括數據壓縮、重新協商、非AEAD密碼本、靜态RSA和靜态DH密鑰交換、自定義DHE分組、點格式協商、更改密碼本規範的協議、UNIX時間的Hello消息，以及長度字段AD輸入到AEAD密碼本。
禁止用于向後兼容性的SSL和RC4協商。
集成會話散列的使用。
棄用記錄層版本号和凍結數以改進向後兼容性。
将一些安全相關的算法細節從附錄移動到标準，并将ClientKeyShare降級到附錄。
添加帶有Poly1305消息驗證碼的ChaCha20流加密。
添加Ed25519和Ed448數字簽名算法。
添加x25519和x448密鑰交換協議。
将支持加密服務器名稱指示（EncryptedServerNameIndication, ESNI）。
網絡安全服務（NSS）是由Mozilla開發并由其網絡浏覽器Firefox使用的加密庫，自2017年2月起便默認啟用TLS 1.3。随後TLS 1.3被添加到2017年3月發布的Firefox 52.0中，但它由于某些用戶的兼容性問題，默認情況下禁用。直到Firefox 60.0才正式默認啟用。
Google Chrome曾在2017年短時間将TLS 1.3設為默認，然而由于類似Blue Coat Systems等不兼容組件而被取消。
wolfSSL在2017年5月發布的3.11.1版本中啟用了TLS 1.3。作為第一款支持TLS 1.3部署，wolfSSL 3.11.1 支持 TLS 1.3 Draft 18（ 現已支持到Draft 28），同時官方也發布了一系列關于TLS 1.2和TLS 1.3性能差距的博客。
算法
主條目：密碼包
密鑰交換和密鑰協商
在客戶端和服務器開始交換TLS所保護的加密信息之前，他們必須安全地交換或協定加密密鑰和加密數據時要使用的密碼。用于密鑰交換的方法包括：使用RSA算法生成公鑰和私鑰（在TLS握手協議中被稱為TLS_RSA），Diffie-Hellman（在TLS握手協議中被稱為TLS_DH），臨時Diffie-Hellman（在TLS握手協議中被稱為TLS_DHE），橢圓曲線迪菲-赫爾曼（在TLS握手協議中被稱為TLS_ECDH），臨時橢圓曲線Diffie-Hellman（在TLS握手協議中被稱為TLS_ECDHE），匿名Diffie-Hellman（在TLS握手協議中被稱為TLS_DH_anon）和預共享密鑰（在TLS握手協議中被稱為TLS_PSK）。
TLS_DH_anon和TLS_ECDH_anon的密鑰協商協議不能驗證服務器或用戶，因為易受中間人攻擊因此很少使用。隻有TLS_DHE和TLS_ECDHE提供前向保密能力。
在交換過程中使用的公鑰/私鑰加密密鑰的長度和在交換協議過程中使用的公鑰證書也各不相同，因而提供的強健性的安全。2013年7月，Google宣布向其用戶提供的TLS加密将不再使用1024位公鑰并切換到2048位，以提高安全性。
參見
應用層協議協商
SSL加速
擴展驗證證書
