传输层安全性协定

传输层安全性协定（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协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手，客户端和服务器协商各种参数用于建立安全连接：

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

## 发展历史

协议｜发布时间｜状态

SSL 1.0｜未公布｜未公布

SSL 2.0｜1995年｜已于2011年弃用

SSL 3.0｜1996年｜已于2015年弃用

TLS 1.0｜1999年｜于2021年弃用

TLS 1.1｜2006年｜于2021年弃用

TLS 1.2｜2008年

TLS 1.3｜2018年

### 安全网络编程

早期的研究工作，为方便改造原有网络应用程序，在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日发布的Firefox 34中彻底禁用了SSL 3.0。微软同样发出了安全通告。

- 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。

### TLS 1.0

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

### TLS 1.1

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

- 隐式IV被替换成一个显式的IV。
- 更改分组密码模式中的填充错误。
- 支持IANA登记的参数。

微软、Google、苹果、Mozilla四家浏览器业者在2020年终止支援TLS 1.0及1.1版。2021年3月，RFC 8996标准弃用了TLS 1.0和TLS 1.1。

### TLS 1.2

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

- 增加SHA-2密码杂凑函数。
- 增加AEAD加密算法，如GCM模式。
- 添加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的主要区别包括：

- 将密钥交换算法（如ECDHE）和认证算法（如RSA）从密码套件中分离出来。
- 移除MD5、SHA1密码杂凑函数的支持。
- 请求数字签名。
- 集成HKDF和半短暂DH提议。
- 替换使用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）。

网络安全服务（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握手协议中被称为TLS_SRP）。

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

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

算法｜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（具有前向安全性）｜否｜是｜是｜是｜是｜否

DHE-ECDSA (具有前向安全性)｜否｜否｜否｜否｜否｜是

ECDH-ECDSA｜否｜否｜是｜是｜是｜否

ECDHE-ECDSA（具有前向安全性）｜否｜否｜是｜是｜是｜是

DHE-EdDSA (具有前向安全性)｜否｜否｜否｜否｜否｜是

ECDH-EdDSA｜否｜否｜是｜是｜是｜否

ECDHE-EdDSA (具有前向安全性)｜否｜否｜是｜是｜是｜是

PSK｜否｜否｜是｜是｜是｜是

RSA-PSK｜否｜否｜是｜是｜是｜否

DHE-PSK（具有前向安全性）｜否｜否｜是｜是｜是｜是

ECDHE-PSK（具有前向安全性）｜否｜否｜是｜是｜是｜是

SRP｜否｜否｜是｜是｜是｜否

SRP-DSS｜否｜否｜是｜是｜是｜否

SRP-RSA｜否｜否｜是｜是｜是｜否

Kerberos｜否｜否｜是｜是｜是｜?

DH-ANON（不安全）｜否｜是｜是｜是｜是｜否

ECDH-ANON（不安全）｜否｜否｜是｜是｜是｜否

GOST R 34.10-94 / 34.10-2001｜否｜否｜是｜是｜是｜在RFC草案中提出

GOST R 34.10-2012｜否｜否｜否｜否｜是｜是｜中TLS 1.2、1.3的定义

### 加密密码

密码｜协议版本｜状态

类型｜算法｜长度（bits）｜SSL 2.0｜SSL 3.0｜TLS 1.0｜TLS 1.1｜TLS 1.2｜TLS 1.3

分组密码及其加密方式｜AES GCM｜256, 128｜不适用｜不适用｜不适用｜不适用｜安全｜安全｜RFC中TLS 1.2的定义

AES CCM｜不适用｜不适用｜不适用｜不适用｜安全｜安全

AES CBC｜不适用｜不安全｜依赖于后期加入的措施｜依赖于后期加入的措施｜依赖于后期加入的措施｜不适用

Camellia GCM｜256, 128｜不适用｜不适用｜不适用｜不适用｜安全｜不适用

Camellia CBC｜不适用｜不安全｜依赖于后期加入的措施｜依赖于后期加入的措施｜依赖于后期加入的措施｜不适用

ARIA加密算法 GCM｜256, 128｜不适用｜不适用｜不适用｜不适用｜安全｜不适用

ARIA加密算法 CBC｜不适用｜不适用｜依赖于后期加入的措施｜依赖于后期加入的措施｜依赖于后期加入的措施｜不适用

SEED加密算法 CBC｜128｜不适用｜不安全｜依赖于后期加入的措施｜依赖于后期加入的措施｜依赖于后期加入的措施｜不适用

3DES EDE CBCSweet32攻击能破解分组长度为64位元的区块加密法。｜112尽各3DES的金钥长度为168位元, 它的有效安全性仅为112位元，远低于建议的最少128位元。｜不安全｜不安全｜不安全｜不安全｜不安全｜不适用

GOST加密算法 CNT｜256｜不适用｜不适用｜不安全｜不安全｜不安全｜不适用｜定义于

GOST加密算法 CTR｜256｜不适用｜不适用｜不安全｜不安全｜不安全｜不适用｜定义于

GOST R 34.12-2015 Kuznyechik CTR｜256｜不适用｜不适用｜不适用｜不适用｜安全｜不适用｜定义于

GOST加密算法 MGM｜256｜不适用｜不适用｜不适用｜不适用｜不适用｜不安全｜定义于

GOST R 34.12-2015 Kuznyechik MGM｜256｜不适用｜不适用｜不适用｜不适用｜不适用｜安全｜定义于

IDEA CBCTLS 1.2已移除IDEA和DES。｜128｜不安全｜不安全｜不安全｜不安全｜不适用｜不适用｜从TLS 1.2标准中移除

DES CBC｜56｜不安全｜不安全｜不安全｜不安全｜不适用｜不适用

40｜不安全｜不安全｜不安全｜不适用｜不适用｜不适用｜在TLS 1.1及之后版本禁止

RC2 CBC｜40｜不安全｜不安全｜不安全｜不适用｜不适用｜不适用

流加密｜ChaCha20-Poly1305｜256｜不适用｜不适用｜不适用｜不适用｜安全｜安全｜RFC中TLS 1.2的定义

RC4｜128｜不安全｜不安全｜不安全｜不安全｜不安全｜不适用｜由定义所有版本TLS禁止

40｜不安全｜不安全｜不安全｜不适用｜不适用｜不适用

Null｜不安全｜不安全｜不安全｜不安全｜不安全｜不适用｜RFC中TLS 1.2的定义

标注

### 数据完整性

讯息鉴别码（MAC）用于对数据完整性进行认证。HMAC用于CBC模式的块密码。AEAD例如GCM模式和CCM模式使用AEAD内建的讯息鉴别码，不使用HMAC。另外，在TLS握手过程中需要使用基于HMAC的伪随机函数（PRF），或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｜否｜否｜否｜否｜是｜否｜中TLS 1.2的定义

GOST R 34.11-94｜否｜否｜否｜否｜是｜//datatracker.ietf.org/doc/html/draft-chudov-cryptopro-cptls-04 RFC Draft中TLS 1.2的定义

GOST R 34.12-2015 AEAD｜否｜否｜否｜否｜否｜是｜中TLS 1.3的定义

## 过程

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

TLS包含几个基本阶段：

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

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

- 身份验证：RSA、DSA、ECDSA。
- 密钥交换：PSK、Diffie-Hellman、ECDH。
- 对称密钥加密：RC4、DES、3DES、AES、ChaCha20以及Camellia。
- 散列函数：MD5、SHA家族。

## 外部链接

- SSL/TLS/WTLS原理
- SSL配置指南
- SSL状态检查、格式转换、漏洞扫描工具