维基百科

传输层安全性协议

用於保護傳輸中數據的密碼協議
（重定向自安全通訊協定）
“TLS”重定向至此。关于其他用法，请见“TLS (消歧义)”。

传输层安全性协议（英语：Transport Layer Security，缩写：TLS），前身称为安全套接层（英语：Secure Sockets Layer，缩写：SSL）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。

网景公司（Netscape）在1994年推出首版网页浏览器－网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。

IETF将SSL进行标准化，1999年公布TLS 1.0标准文件（RFC 2246）。随后又公布TLS 1.1（RFC 4346，2006年）、TLS 1.2（RFC 5246，2008年）和TLS 1.3（RFC 8446，2018年）。在浏览器、电子邮件、即时通信、VoIP、网络传真等应用程序中，广泛使用这个协议。许多网站，如Google、Facebook、Wikipedia等也以这个协议来建立安全连线，发送资料。目前已成为互联网上保密通信的工业标准。

SSL包含记录层（Record Layer）和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密匙作为会话密匙（Session key）。这个会谈密匙是用来将通信两方交换的资料做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。

概论

编辑

TLS协议采用主从式架构模型，用于在两个应用程序间透过网络建立起安全的连线，防止在交换资料时受到窃听及篡改。

TLS协议的优势是与高层的应用层协议（如HTTP、FTP、Telnet等）无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行建立加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。

TLS协议是可选的，必须配置客户端和服务器才能使用。主要有两种方式实现这一目标：一个是使用统一的TLS协议端口（例如：用于HTTPS的端口443）；另一个是客户端请求服务器连接到TLS时使用特定的协议机制（例如：电子邮件常用的STARTTLS）。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据[1]。通过握手，客户端和服务器协商各种参数用于建立安全连接：

  • 当客户端连接到支持TLS协议的服务器要求建立安全连接并列出了受支持的密码包（包括加密算法、散列算法等），握手开始。
  • 服务器从该列表中决定密码包，并通知客户端。
  • 服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构（CA）和服务器的公钥。
  • 客户端确认其颁发的证书的有效性。
  • 为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。
  • 利用随机数，双方生成用于加密和解密的对称密钥。这就是TLS协议的握手，握手完毕后的连接是安全的，直到连接（被）关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。

发展历史

编辑
协议 发布时间 状态
SSL 1.0 未公布 未公布
SSL 2.0 1995年 已于2011年弃用[2]
SSL 3.0 1996年 已于2015年弃用[3]
TLS 1.0 1999年 于2021年弃用[4]
TLS 1.1 2006年 于2021年弃用[4]
TLS 1.2 2008年
TLS 1.3 2018年

安全网络编程

编辑

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

SSL 1.0、2.0和3.0

编辑

SSL（Secure Sockets Layer）是网景公司（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]。

TLS 1.0

编辑

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

TLS 1.1

编辑

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

编辑

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

编辑
参见：来回通信延迟

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

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

身份验证和密钥交换协议列表
算法 SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 状态
RSA 是 是 是 是 是 否 RFC中TLS 1.2的定义
DH-RSA 否 是 是 是 是 否
DHE-RSA（具有前向安全性） 否 是 是 是 是 是
ECDH-RSA 否 否 是 是 是 否
ECDHE-RSA（具有前向安全性） 否 否 是 是 是 是
DH-DSS 否 是 是 是 是 否
DHE-DSS（具有前向安全性） 否 是 是 是 是 否[26]
DHE-ECDSA (具有前向安全性) 否 否 否 否 否 是
ECDH-ECDSA 否 否 是 是 是 否
ECDHE-ECDSA（具有前向安全性） 否 否 是 是 是 是
DHE-EdDSA (具有前向安全性) 否 否 否 否 否 是
ECDH-EdDSA 否 否 是 是 是 否
ECDHE-EdDSA (具有前向安全性)[27] 否 否 是 是 是 是
PSK 否 否 是 是 是 是
RSA-PSK（英语：Pre-shared key） 否 否 是 是 是 否
DHE-PSK（英语：Pre-shared key）（具有前向安全性） 否 否 是 是 是 是
ECDHE-PSK（英语：Pre-shared key）（具有前向安全性） 否 否 是 是 是 是
SRP 否 否 是 是 是 否
SRP-DSS 否 否 是 是 是 否
SRP-RSA 否 否 是 是 是 否
Kerberos 否 否 是 是 是 ?
DH-ANON（不安全） 否 是 是 是 是 否
ECDH-ANON（不安全） 否 否 是 是 是 否
GOST R 34.10-94 / 34.10-2001（英语：GOST）[28] 否 否 是 是 是 在RFC草案中提出
GOST R 34.10-2012（英语：GOST）[29] 否 否 否 否 是 是 RFC 9189 9367中TLS 1.2、1.3的定义

加密密码

编辑
参见：分组密码工作模式
针对公开可行的攻击的密码安全性
密码 协议版本 状态
类型 算法 长度（bits） SSL 2.0 SSL 3.0
[n 1][n 2][n 3][n 4] 		TLS 1.0
[n 1][n 3] 		TLS 1.1
[n 1] 		TLS 1.2
[n 1] 		TLS 1.3
分组密码及其加密方式 AES GCM[30][n 5] 256, 128 不适用 不适用 不适用 不适用 安全 安全 RFC中TLS 1.2的定义
AES CCM[31][n 5] 不适用 不适用 不适用 不适用 安全 安全
AES CBC[n 6] 不适用 不安全 依赖于后期添加的措施 依赖于后期添加的措施 依赖于后期添加的措施 不适用
Camellia GCM[32][n 5] 256, 128 不适用 不适用 不适用 不适用 安全 不适用
Camellia CBC[33][n 6] 不适用 不安全 依赖于后期添加的措施 依赖于后期添加的措施 依赖于后期添加的措施 不适用
ARIA加密算法（英语：ARIA_(cipher)） GCM[34][n 5] 256, 128 不适用 不适用 不适用 不适用 安全 不适用
ARIA加密算法（英语：ARIA_(cipher)） CBC[34][n 6] 不适用 不适用 依赖于后期添加的措施 依赖于后期添加的措施 依赖于后期添加的措施 不适用
SEED加密算法（英语：SEED (cipher)） CBC[35][n 6] 128 不适用 不安全 依赖于后期添加的措施 依赖于后期添加的措施 依赖于后期添加的措施 不适用
3DES EDE CBC[n 6][n 7] 112[n 8] 不安全 不安全 不安全 不安全 不安全 不适用
GOST 28147-89（英语：GOST_(block_cipher)） CNT[28][n 7] 256 不适用 不适用 不安全 不安全 不安全 不适用 定义于RFC 4357
GOST R 34.12-2015 Magma（英语：GOST_(block_cipher)） CTR[29][n 7] 256 不适用 不适用 不安全 不安全 不安全 不适用 定义于RFC 4357 9189
GOST R 34.12-2015 Kuznyechik（英语：Kuznyechik） CTR[29] 256 不适用 不适用 不适用 不适用 安全 不适用 定义于RFC 9189
GOST R 34.12-2015 Magma（英语：GOST_(block_cipher)） MGM[29][n 5][n 7] 256 不适用 不适用 不适用 不适用 不适用 不安全 定义于RFC 9367
GOST R 34.12-2015 Kuznyechik（英语：Kuznyechik） MGM[29][n 5] 256 不适用 不适用 不适用 不适用 不适用 安全 定义于RFC 9367
IDEA CBC[n 6][n 7][n 9] 128 不安全 不安全 不安全 不安全 不适用 不适用 从TLS 1.2标准中移除
DES CBC[n 6][n 7][n 9] 056 不安全 不安全 不安全 不安全 不适用 不适用
040[n 10] 不安全 不安全 不安全 不适用 不适用 不适用 在TLS 1.1及之后版本禁止
RC2（英语：RC2） CBC[n 6][n 7] 040[n 10] 不安全 不安全 不安全 不适用 不适用 不适用
流加密 ChaCha20-Poly1305[40][n 5] 256 不适用 不适用 不适用 不适用 安全 安全 RFC中TLS 1.2的定义
RC4[n 11] 128 不安全 不安全 不安全 不安全 不安全 不适用 由RFC 7465定义所有版本TLS禁止
040[n 10] 不安全 不安全 不安全 不适用 不适用 不适用
None Null[n 12] – 不安全 不安全 不安全 不安全 不安全 不适用 RFC中TLS 1.2的定义
标注
  1. ^ 1.0 1.1 1.2 1.3 RFC 5746 must be implemented to fix a renegotiation flaw that would otherwise break this protocol.
  2. ^ If libraries implement fixes listed in RFC 5746, this violates the SSL 3.0 specification, which the IETF cannot change unlike TLS. Fortunately, most current libraries implement the fix and disregard the violation that this causes.
  3. ^ 3.0 3.1 The BEAST attack breaks all block ciphers (CBC ciphers) used in SSL 3.0 and TLS 1.0 unless mitigated by the client and/or the server. See § Web browsers.
  4. ^ The POODLE attack breaks all block ciphers (CBC ciphers) used in SSL 3.0 unless mitigated by the client and/or the server. See § Web browsers.
  5. ^ 5.0 5.1 5.2 5.3 5.4 5.5 5.6 认证加密 (倒如GCM和CCM) 只适用于TLS 1.2或以上版本。
  6. ^ 6.0 6.1 6.2 6.3 6.4 6.5 6.6 6.7 如该加密系统并未移除所有计时旁路，幸运十三攻击能破解CBC加密。
  7. ^ 7.0 7.1 7.2 7.3 7.4 7.5 7.6 Sweet32攻击能破解分组长度为64位的分组密码。[36]
  8. ^ 尽各3DES的密钥长度为168位, 它的有效安全性仅为112位，[37] 远低于建议的最少128位。[38]
  9. ^ 9.0 9.1 TLS 1.2已移除IDEA和DES。[39]
  10. ^ 10.0 10.1 10.2 此等密钥长度只有40比特的密码包为降级版本，以符合（于2000年被大幅放宽）美国对某些高强度加密技术的出口管制。自TLS 1.1起，它们均被禁用。
  11. ^ Use of RC4 in all versions of TLS is prohibited by RFC 7465 (because RC4 attacks weaken or break RC4 used in SSL/TLS).
  12. ^ Authentication only, no encryption.

数据完整性

编辑

消息认证码（MAC）用于对数据完整性进行认证。HMAC用于CBC模式的块密码。AEAD例如GCM模式和CCM模式使用AEAD内置的消息鉴别码，不使用HMAC[41]。另外，在TLS握手过程中需要使用基于HMAC的伪随机函数（PRF），或HKDF（英语：HKDF）。

数据的完整性
算法 SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 状态
HMAC-MD5 是 是 是 是 是 否 RFC中TLS 1.2的定义
HMAC-SHA1 否 是 是 是 是 否
HMAC-SHA256/384 否 否 否 否 是 否
AEAD 否 否 否 否 是 是
GOST 28147-89 IMIT（英语：GOST (hash function)） 否 否 否 否 是 否 RFC 9189中TLS 1.2的定义
GOST R 34.11-94（英语：GOST (hash function)） 否 否 否 否 是 RFC Draft中TLS 1.2的定义
GOST R 34.12-2015（英语：GOST (hash function)） AEAD 否 否 否 否 否 是 RFC 9367中TLS 1.3的定义

过程

编辑

TLS在互联网上为HTTP等应用程序提供身份验证、加密、完整性，其基础是公钥基础设施。这是因为公钥基础设施普遍商业运营。TLS协议的设计在某种程度上能够使主从架构应用程序通讯预防窃听、干扰和消息伪造。

TLS包含几个基本阶段：

  1. 对等协商支持的TLS版本，和支持的密码包。
  2. 基于非对称密钥的身份认证，通常是基于PKI证书的身份认证。服务器将其X.509证书发送给客户端，由客户端验证服务器的身份。如果服务器要验证客户端的证书，则客户端可能会将客户端证书发送给服务器。通常仅验证服务器，不验证客户端。
  3. 基于对称密钥的数据加密。客户端生成随机数作为会话密钥，并使用服务器公钥（服务器公钥在服务器证书中）加密会话密钥，最后将已加密的会话密钥发送给服务器。由服务器的私钥解密出会话密钥。最后使用此会话密钥加密数据。TLS也可以使用预共享密钥（PSK）作为对称密钥。

在第一阶段，客户端与服务器协商所用密码算法。当前广泛实现的算法选择如下：

参考文献

编辑
  1. ^ "SSL/TLS in Detail （页面存档备份，存于互联网档案馆）". Microsoft TechNet. Updated July 31, 2003.
  2. ^ RFC 6176. [2020-05-22]. （原始内容存档于2016-12-06）. 
  3. ^ RFC 7568. [2020-05-22]. （原始内容存档于2018-03-28）. 
  4. ^ 4.0 4.1 4.2 RFC 8996. [2021-03-25]. （原始内容存档于2021-03-24）. 
  5. ^ Thomas Y. C. Woo, Raghuram Bindignavle, Shaowen Su and Simon S. Lam, SNP: An interface for secure network programming （页面存档备份，存于互联网档案馆） Proceedings USENIX Summer Technical Conference, June 1994
  6. ^ THE SSL PROTOCOL. Netscape Corporation. 2007 [2014-12-02]. （原始内容存档于1997-06-14）. 
  7. ^ Messmer, Ellen. Father of SSL, Dr. Taher Elgamal, Finds Fast-Moving IT Projects in the Middle East. Network World. [30 May 2014]. （原始内容存档于2014年5月31日）. 
  8. ^ Greene, Tim. Father of SSL says despite attacks, the security linchpin has lots of life left. Network World. [30 May 2014]. （原始内容存档于2014年5月31日）. 
  9. ^ POODLE: SSLv3 vulnerability (CVE-2014-3566). [21 October 2014]. （原始内容存档于2016-03-17）. 
  10. ^ Dierks, T. and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346. April 2006 [2014-12-02]. （原始内容存档于2017-12-24）. 
  11. ^ 11.0 11.1 Polk, Tim; McKay, Terry; Chokhani, Santosh. Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (PDF). National Institute of Standards and Technology: 67. April 2014 [2014-05-07]. （原始内容存档 (PDF)于2014-05-08）. 
  12. ^ 林妍溱. 微軟、蘋果、Google及Mozilla四大瀏覽器業者在2020年終止支援TLS 1.0、1.1. iThome. 2018-10-16 [2020-01-12]. （原始内容存档于2020-01-12）. 
  13. ^ Joseph A. Salowey; Sean Turner; Christopher A. Wood. TLS 1.3. IETF. 2018-08-10 [2018-08-11]. （原始内容存档于2018-08-11） （英语）. 
  14. ^ pigsrollaroundinthem. TLS 1.3 下的 SNI 将让审查变得更困难. Solidot. 2018-08-16 [2018-08-27]. （原始内容存档于2018-08-27）. 
  15. ^ NSS 3.29 release notes. Mozilla Developer Network. February 2017 [2018-08-11]. （原始内容存档于2017-02-22）. 
  16. ^ Enable TLS 1.3 by default. Bugzilla@Mozilla. 16 October 2016 [10 October 2017]. （原始内容存档于2018-08-12）. 
  17. ^ Firefox — Notes (60.0). Mozilla. [2018-05-10]. （原始内容存档于2018-05-09） （美国英语）. 
  18. ^ ProxySG, ASG and WSS will interrupt SSL connections when clients using TLS 1.3 access sites also using TLS 1.3. BlueTouch Online. 16 May 2017 [11 September 2017]. （原始内容存档于2017-09-12）. 
  19. ^ wolfSSL TLS 1.3 BETA Release Now Available. info@wolfssl.com. 11 May 2017 [11 May 2017]. （原始内容存档于2018-07-25）. 
  20. ^ TLS 1.3 PROTOCOL SUPPORT. info@wolfssl.com. （原始内容存档于2018-07-26）. 
  21. ^ TLS 1.3 Draft 28 Support in wolfSSL. info@wolfssl.com. 14 June 2018 [14 June 2018]. （原始内容存档于2018-07-25）. 
  22. ^ RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2. Internet Engineering Task Force. [9 September 2013]. （原始内容存档于2017-12-24）. 
  23. ^ P. Eronen, Ed. RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). Internet Engineering Task Force. [9 September 2013]. （原始内容存档于2013-09-05）. 
  24. ^ D. Taylor, Ed. Using the Secure Remote Password (SRP) Protocol for TLS Authentication. Internet Engineering Task Force. November 2007 [December 21, 2014]. RFC 5054  . doi:10.17487/RFC5054  . （原始内容存档于December 7, 2014）. 
  25. ^ Gothard, Peter. Google updates SSL certificates to 2048-bit encryption. Computing. Incisive Media. [9 September 2013]. （原始内容存档于2013-09-22）. 
  26. ^ Sean Turner. Consensus: remove DSA from TLS 1.3. September 17, 2015 [2018-01-28]. （原始内容存档于2015-10-03）. 
  27. ^ RFC 8422
  28. ^ RFC 5288 5289
  29. ^ RFC 6655 7251
  30. ^ RFC 6367
  31. ^ RFC 5932 6367
  32. ^ 34.0 34.1 RFC 6209
  33. ^ RFC 4162
  34. ^ On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN (PDF). 2016-10-28 [2017-06-08]. （原始内容存档 (PDF)于2017-04-24）. 
  35. ^ NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised) (PDF). 2007-03-08 [2014-07-03]. （原始内容 (PDF)存档于2014-06-06）. 
  36. ^ Qualys SSL Labs. SSL/TLS Deployment Best Practices. [2 June 2015]. （原始内容存档于2015-07-04）. 
  37. ^ RFC 5469
  38. ^ RFC 7905
  39. ^ AEAD Ciphers. [2014-12-02]. （原始内容存档于2017-12-24）. 

外部链接

编辑
 
维基共享资源上的相关多媒体资源：传输层安全性协议

参见

编辑
检索自“https://zh.wikipedia.org/w/index.php?title=傳輸層安全性協定&oldid=83520925”