这是我参与8月更文挑战的第1天，活动详情查看：8月更文挑战
| 8月份更文挑战主题：TLS1.3协议 |
|---|
| TLS1.3系列文章（1）：Why TLS1.3 ？ |
1.1 SSL/TLS协议的发展历程
SSL（Secure Socket Layer，安全套接层）v1.0最早于由网景公司（Netscape，以浏览器闻名，网景浏览器在90年代相当火爆，市场占有率高达90%，后来被美国在线收购）在1994年提出，该方案第一次解决了安全传输的问题。
1995年公开发布了SSLv2.0，该方案于2011年被弃用（RFC6176 - Prohibiting Secure Sockets Layer (SSL) Version 2.0）。
1996年发布了SSLv3.0（2011年才补充的RFC文档：RFC 6101 - The Secure Sockets Layer (SSL) Protocol Version 3.0），被大规模应用，于2015年弃用（RFC7568 - Deprecating Secure Sockets Layer Version 3.0）。
随着互联网的快速发展和普及，SSL应该被广泛应用于互联网上，称为事实上的标准。于是，在1999年，SSL被IETF纳入标准化（RFC2246 - The TLS Protocol Version 1.0），改名叫TLS（Transport Layer Security Protocol，安全传输层协议），和SSLv3.0相比几乎没有做什么改动。关于为何将SSL改名为TLS协议，微软公司和网景公司存在商业纠纷(网景称为SSL，微软在SSL基础上完善后称为PCT(Private Communication Technology)), IETF为了避免参与他们的纠纷，没有使用他们的各自的协议名称，而是采用将SSL3.0重新命名为TLS。
2006年提出了TLS v1.1（RFC4346 - The Transport Layer Security (TLS) Protocol Version 1.1），修复了一些bug，支持更多参数。
2008年提出了TLS v1.2（RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2）做了更多的扩展和算法改进，是目前（2019年）几乎所有新设备的标配。
TLS v1.3在2014年已经提出，2016年开始草案制定，然而由于TLS v1.2的广泛应用，必须要考虑到支持v1.2的网络设备能够兼容v1.3，因此反复修改直到第28个草案才于2018年正式纳入标准（The Transport Layer Security (TLS) Protocol Version 1.3）。TLSv1.3改善了握手流程，减少了时延，并采用完全前向安全的密钥交换算法。
SSL/TLS的现状如下： SSLv1.0~v3.0都已经不安全了，2015年SSLv3.0也被官方弃用，各大平台也都不推荐使用，像java从2015年1月20日开始JDK 8u31、JDK 7u75、JDK 6u91和更高版本将默认禁用SSLv3。TLSv1.0、TLSv1.1也都只是SSL的过渡版本，TLSv1.2是目前大多数终端、平台使用的标准协议。TLSv1.3是正在大力推广的协议，例如阿里云的服务器、又拍云的CDN、Chome和FireFox浏览器都已经支持TLSv1.3了。
| 协议 | 使用情况 |
|---|---|
| SSL3.0及以下 | 存在安全问题，已经被废弃；不推荐使用 |
| TLS1.0/TLS1.1 | 过度版本，不建议使用 |
| TLS1.2 | 广泛支持并采用 |
| TLS1.3 | 大力推广中 |
1.2 TLS版本间差异
TLS版本对应的RFC文档：
| TLS版本 | RFC文档编号 |
|---|---|
| TLS1.0 | rfc2246 |
| TLS1.1 | rfc4346 |
| TLS1.2 | rfc5246 |
| TLS1.3 | rfc8446 |
SSL 3.0
SSL3于1995年末发布，为了弥补先前协议版本的诸多弱点，SSL3从头开始设计了一套协议，并一直沿用到了最新版本的TLS。
TLS 1.0
TLS1.0于1999年1月发布，与SSL3相比，它有以下的区别：
🔱 这是定义基于标准HMAC的PRF的第一个版本。它将PRF以 HMAC-MD5和 HMAC-SHA的结合(XOR)实现；
🔱 生成主密钥使用PRF，而不是定制的构造方法；
🔱 verify_data的值基于PRF，而不是定制的构造方法；
🔱 使用官方HMAC作为完整性验证(MAC)。SSL3使用的是更早的、已被废弃的HMAC版本；
🔱 修改填充格式，使其更为可靠。2014年10月，被称为POODLE的攻击暴露了SSL3的填充机制不安全。
🔱 去掉了 FORTEZZA套件。
TLS 1.1
TLS1.1于2006年4月发布。与TLS1.0相比，它有以下的区别：
🔱 CBC加密使用包含在每个TLS记录中的显式Ⅳ。这弥补了Ⅳ可预测的弱点，不然这个弱点后面会被BEAST攻击所利用；
🔱 为了抵抗填充攻击，要求实现使用 bad_record_mac警报作为填充问题的响应。不再赞成使用decryption_failed警报。
🔱 这个版本引用包含了TLS扩展(RFC3546)
TLS 1.2
TLS1.2于2008年8月发布。与TLS1.1相比，它有以下的区别：
🔱添加已验证加密支持；
🔱添加对HMAC-SHA256密码套件的支持；
🔱删除IDEA和DES密码套件；
🔱虽然大部分扩展的实际文档还是在其他地方，但TLS将扩展和协议的主规格说明书进行了集成；
🔱客户端可以使用一种新的扩展( signature_algorithms)来通报它愿意接受的散列和签名算法。
🔱当使用TLS1.2套件或者以协商协议是TLS1.2为条件使用之前的套件时，在PRF中使用SHA256代替MD5/SHA1组合。
🔱允许密码套件定义其自身的PRF；
🔱使用单一散列代替用于数字签名的MD5/SHA1组合。默认使用SHA256，并且密码套件可以指定其自身使用的散列。签名散列算法以往是由协议强制指定，现在是散列函数式签名结构中的一部分，而且在实施启用中可以选择最佳算法。
🔱 密码套件可以显式指定 Finished消息中的 verify_data成员的长度。
TLS 1.3
TLS 1.3发布2018年，是时隔九年对 TLS 1.2 等之前版本的新升级，也是迄今为止改动最大的一次。针对目前已知的安全威胁，IETF（Internet Engineering Task Force，互联网工程任务组） 正在制定 TLS 1.3 的新标准，使其有望成为有史以来最安全，但也最复杂的 TLS 协议。TLS 1.3 与之前的协议有较大差异，主要在于：
🔱相比过去的的版本，引入了新的密钥协商机制 — PSK；
🔱支持 0-RTT 数据传输，在建立连接时节省了往返时间；
🔱废弃了 3DES、RC4、AES-CBC 等加密组件，废弃了 SHA1、MD5 等哈希算法；伪随机数函数由 PRF 升级为 HKDF（HMAC-based Extract-and-Expand Key Derivation Function）；废除不支持前向安全性的 RSA 和 DH 密钥交换算法；
🔱ServerHello 之后的所有握手消息采取了加密操作，可见明文大大减少；
🔱不再允许对加密报文进行压缩、不再允许双方发起重协商；
🔱DSA 证书不再允许在 TLS 1.3 中使用。
TLS 1.3改动细节表：
| 大项 | 具体 | TLS 1.3 | TLS 1.2 及 之前版本 | |
|---|---|---|---|---|
| 握手 | 握手流程 | 客户端在 ClientHello 的扩展中发送密钥交换相关信息 | 客户端在 Certificate 之后发送 ClientKeyExchange | 改 |
| 不使用 HelloRequest | HelloRequest | 删 | ||
| 使用 HelloRetryRequest | 增 | |||
| 握手设置 | 不使用压缩 | 删 | ||
| post-handshake | TLS 1.3 有 post-handshake 机制，使用 application traffic key 加密，可发送 NewSessionTicket Msg，验证，更新密钥 | TLS 1.2 在 Finished 之后更改密钥需要重新握手，即重协商，但是这个有安全问题 | 改 | |
| 版本表示 | 使用 supported_versions 扩展 | 使用 ClientHello.client_version / ServerHello.server_version | 改 | |
| ClientHello | 废弃使用 SessionID，使用一个随机数 | 使用 SessionID | 删 | |
| 不使用 PRF | cipher suites 要声明 PRF 算法 | 删 | ||
| ServerHello | ServerHello 之后消息全部加密 | 改 | ||
| Finished Msg | verify_data 长度取决于 HMAC 计算的结果 | verify_data 长度固定为12字节 | 改 | |
| 使用 HMAC | 使用 PRF | 改 | ||
| 0-RTT 模式 | 可以发送 EarlyData | 增 | ||
| 恢复 | 废弃 Session ID / Ticket 机制，改用 PSK (Pre-Shared Secret Key) | Session ID / Ticket | 改 | |
| resumption-PSK 也需要协商扩展，每一次握手都需要协商扩展 | 增 | |||
| 记录层 | nonce 计算 | 见 #5.2 | 使用明确的 nonce [p83，#5.3] | 改 |
| version | 废弃之前版本使用的 TLSPlaintext.lagacy_record_version / TLSCiphertext.lagacy_record_version，出于兼容性目的保留，但是并不使用 | 删 | ||
| TLSCiphertext.length | 长度限制为 2^14 + 255 | 长度限制为 2^14 + 2048 | 改 | |
| TLSCiphertext | encrypted_record -> AEAD 结果 | fragment -> 加密 + MAC | 改 | |
| 密钥计算 | 使用 HKDF；密钥的长度和哈希算法的输出长度保持一致；密钥计算与 TLS 1.2 不同 | 使用 PRF [p64，#8.1；p25，#6.3]；master secret 长度为48字节 [p17] | 改 | |
| 内容类型 | ChangeCipherSpec | 不使用，出于兼容性目的会发送和略过指定值 | 删 | |
| 算法 | 对称算法 | 仅保留 AEAD | 删 | |
| (EC)DHE | 根据指定位数填充高位位数不足的0 | 之前版本会去除高位的0 | 改 | |
| 废弃未验证的DH密码套 | 删 | |||
| KDF | 使用 HKDF | 使用 KDF | 改 | |
| ECC | 新算法 | 增 | ||
| ECC | 去除点格式协商，只能使用未压缩格式点 | 改 | ||
| RSA | 使用 RSASSA-PSS | 增 | ||
| 扩展 | supported_groups | 重命名为 supported_groups，签名算法独立协商，不一起协商 | 原名 elliptic_curves，且只包括椭圆曲线算法，并且同时用于协商 ECDSA 的曲线 | 改 |
| supported_groups | 删除不安全加密套，保留 AEAD | 删 | ||
| 算法套结构体 | 改名为 SignatureScheme。signature_algorithms 这一扩展有别的定义 | 枚举 SignatureAlgorithm | 改 | |
| SCT | SCT 信息作为扩展和 CertificateEntry 一起发送 | SCT 作为扩展和 ServerHello 一起发送 | 改 | |
| OCSP Status and SCT | OCSP 信息在 CertificateEntry 中附带，且 status_request 扩展必须保持 CertificateStatus 结构 | 扩展值为空来表示协商该扩展，并将 OSCP 信息放到 CertificateStatus Msg中 | 改 | |
| Exporters | 使用 HKDF 代替 PRF，且 context 为空或长度为0时，在 TLS 1.3 中，计算结果是相同的 | 使用 TLS pseudorandom function (PRF)。context 为空或长度为0时，计算结果不同 | 改 | |
| trusted_ca_keys | 废弃 | 删 | ||
| status_request_v2 | 废弃 | 删 | ||
| cookie | 可以使用 cookie | 增 | ||
| Alert | Closure alert | 对于 close_notify，发送表明发送方不会再发送新的消息了，随后发送的信息应当被忽略。必须在结束写链接之前发送，除非发送了 error alert。对于读链接没有影响。 | 此前版本中，收到 close_notify 之后，另外一方必须中断写，并且立马发送 close_notify。 | 改 |
1.3 TLS1.3的目标
IETF 对 TLS 1.2 的过时设计和两次往返不甚满意，开始着手定义新版本的 TLS。2013 年 8 月，Eric Rescorla 为新协议制定了一份愿望清单（PDF）。经过一番辩论后，这个新版本被称为 TLS 1.3，它打算解决的主要问题有
- reducing handshake latency ：减少握手延迟
- encrypting more of the handshake ：加密更多握手信息
- improving resiliency to cross-protocol attacks ：提高跨协议攻击的特性
- removing legacy features ：删除旧功能
简而言之：更快、更安全。
