傳輸層安全性協定

早期的研究工作，为方便改造原有网络应用程序，在1993年已经有了相似的Berkeley套接字安全传输层API方法[5]。

SSL（）是网景公司（Netscape）设计的主要用于Web的安全传输协议，这种协议在Web上获得了广泛的应用[6]。

基础算法由作为网景公司的首席科学家塔希爾·蓋莫爾（Taher Elgamal）编写，所以他被人称为“SSL之父”。[7][8]

2014年10月，Google發布在SSL 3.0中發現設計缺陷，建議禁用此一協議。攻擊者可以向TLS發送虛假錯誤提示，然後將安全連接強行降級到过时且不安全的SSL 3.0，然後就可以利用其中的設計漏洞竊取敏感信息。Google在自己公司相關產品中陸續禁止回溯相容，強制使用TLS協議。Mozilla也在11月25日發布的Firefox 34中徹底禁用了SSL 3.0。微軟同樣發出了安全通告[9]。

• 1.0版本从未公开过，因为存在严重的安全漏洞。
• 2.0版本在1995年2月发布。2011年，RFC 6176 標準棄用了SSL 2.0。
• 3.0版本在1996年发布，是由網景工程師保罗·科切、Phil Karlton和Alan Freier完全重新设计的。2015年，RFC 7568 標準棄用了SSL 3.0。

IETF将SSL标准化，即 RFC 2246 ，并将其称为TLS（）。

TLS 1.1在 RFC 4346 中定义，于2006年4月发表[10]，它是TLS 1.0的更新。在此版本中的差异包括：

• 添加对CBC攻击的保护：
  • 隐式IV被替换成一个显式的IV。
  • 更改分组密码模式中的填充错误。
• 支持IANA登记的参数。[11]^:2

微軟、Google、蘋果、Mozilla四家瀏覽器業者將在2020年終止支援TLS 1.0及1.1版[12]。2021年3月，RFC 8996标准弃用了TLS 1.0和TLS 1.1[4]。

TLS 1.2在 RFC 5246 中定义，于2008年8月发表。它基于更早的TLS 1.1规范。主要区别包括：

• 增加SHA-2密碼雜湊函數。
• 增加AEAD加密算法，如GCM模式。
• 添加TLS扩展定义和AES密码组合[11]^:2。所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容，这样TLS会话将永远无法协商使用的SSL 2.0以避免安全问题。

TLS 1.3在 RFC 8446 中定义，于2018年8月发表。[13]它与TLS 1.2的主要区别包括：

• 将密鑰交換算法（如ECDHE）和認證算法（如RSA）从密码套件中分离出来。
• 移除MD5、SHA1密碼雜湊函數的支持。
• 请求数字签名。
• 集成HKDF和半短暂DH提议。
• 替换使用PSK和票据的恢复。
• 支持1-RTT握手并初步支持0-RTT。
• 通过在密鑰協商期间使用临时密钥来保证完善的前向安全性。
• 放弃许多不安全或过时特性的支持，包括数据压缩、重新协商、非AEAD加密算法、静态RSA和静态DH密钥交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息，以及长度字段AD输入到AEAD密码本。
• 較TLS 1.2速度更快，效能更好。
• 移除RC4加密演算法的支援。
• 集成会话散列的使用。
• 弃用记录层版本号和冻结数以改进向后兼容性。
• 将一些安全相关的算法细节从附录移动到标准，并将ClientKeyShare降级到附录。
• 支援Ed25519和Ed448数字签名算法。
• 支援X25519密鑰交換。
• 支援帶Poly1305訊息驗證碼的ChaCha20加密演算法。
• 支持加密服务器名称指示（, ESNI）。[14]

网络安全服务（NSS）是由Mozilla开发并由其网络浏览器Firefox使用的加密库，自2017年2月起便默认启用TLS 1.3。[15]随后TLS 1.3被添加到2017年3月发布的Firefox 52.0中，但它由于某些用户的兼容性问题，默认情况下禁用。[16]直到Firefox 60.0才正式默认启用。[17]

Google Chrome曾在2017年短时间将TLS 1.3设为默认，然而由于类似Blue Coat Systems等不兼容组件而被取消。[18]

wolfSSL在2017年5月发布的3.11.1版本中启用了TLS 1.3。[19]作为第一款支持TLS 1.3部署，wolfSSL 3.11.1 支持 TLS 1.3 Draft 18（现已支持到Draft 28），[20]同时官方也发布了一系列关于TLS 1.2和TLS 1.3性能差距的博客。[21]

在客户端和服务器开始交换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）[22]、预共享密钥（在TLS握手协议中被称为TLS_PSK）[23]和安全远程密码（在TLS握手协议中被称为TLS_SRP）。[24]

TLS_DH_anon和TLS_ECDH_anon的密钥协商协议不能验证服务器或用户，因为易受中间人攻击因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。

在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同，因而提供的強健性的安全。2013年7月，Google宣布向其用户提供的TLS加密将不再使用1024位公钥并切换到至少2048位，以提高安全性。[25]

标注

訊息鑑別碼（MAC）用于对数据完整性进行认证。HMAC用于CBC模式的块密码。AEAD例如GCM模式和CCM模式使用AEAD內建的訊息鑒別碼，不使用HMAC[41]。另外，在TLS握手過程中需要使用基於HMAC的偽隨機函數（PRF），或HKDF。