JEP 332: Transport Layer Security (TLS) 1.3 | 传输层安全性（TLS）1.3
摘要
实现传输层安全性（TLS）协议版本 1.3，遵循 RFC 8446。
非目标
本提案的目标不包括支持数据报传输层安全性（DTLS）协议版本 1.3。同时，也不是为了支持 TLS 1.3 的每一项特性；更多关于将实现哪些特性的详细信息，请参见描述部分。
动机
TLS 1.3 是 TLS 协议的一次重大更新，与前一个版本相比，它提供了显著的安全性和性能改进。目前，其他供应商已经提供了几种早期实现。我们需要支持 TLS 1.3 以保持竞争力并跟上最新的标准。
描述
TLS 1.3 是一个新的 TLS 版本，它取代了并废弃了包括版本 1.2（RFC 5246）在内的以前的 TLS 版本。它还废弃或更改了其他 TLS 特性，如 OCSP stapling 扩展（RFC 6066，RFC 6961），以及会话哈希和扩展主密钥扩展（RFC 7627）。
JDK 中的 Java 安全套接字扩展（JSSE）提供了 SSL、TLS 和 DTLS 协议的框架和 Java 实现。目前，JSSE API 和 JDK 实现支持 SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2、DTLS 1.0 和 DTLS 1.2。通过本提案，将增加对 TLS 1.3 的支持。
这个 JEP 的主要目标是实现一个可互操作且兼容的 TLS 1.3 最小版本。最小实现应该支持以下功能：
- 协议版本协商
- TLS 1.3 完整握手
- TLS 1.3 会话恢复
- TLS 1.3 密钥和初始化向量（iv）更新
- TLS 1.3 更新的 OCSP stapling
- TLS 1.3 向后兼容模式
- TLS 1.3 所需的扩展和算法
- RSASSA-PSS 签名算法（8146293）
对于最小实现，不需要新的公共 API。但是，需要以下新的 标准算法名称：
- TLS 协议版本名称：
TLSv1.3 javax.net.ssl.SSLContext算法名称：TLSv1.3- TLS 1.3 的 TLS 密码套件名称：
TLS_AES_128_GCM_SHA256，TLS_AES_256_GCM_SHA384。
此外，KRB5 密码套件将从 JDK 中移除，因为它们不再被认为是安全的。
与此 JEP 并行，我们将为以下可选的 TLS 1.3 功能开发加密算法支持：
如果时间允许，这些功能可能会包含在此 JEP 中；否则，它们将被作为单独的功能进行开发和集成。
以下重要功能将不会作为此 JEP 的一部分来实现：
- 0-RTT（零次往返时间）数据
- 握手后认证
- 签名证书时间戳（SCT）：RFC 6962
TLS 1.3 与之前的版本并不直接兼容。尽管 TLS 1.3 可以通过向后兼容模式来实现，但在使用此模式时仍存在一些兼容性风险：
TLS 1.3 使用半关闭策略，而 TLS 1.2 及更早版本使用双工关闭策略。对于依赖双工关闭策略的应用程序，在升级到 TLS 1.3 时可能会遇到兼容性问题。
signature_algorithms_cert扩展要求使用预定义的签名算法进行证书认证。然而，在实践中，应用程序可能会使用不受支持的签名算法。TLS 1.3 不支持 DSA 签名算法。如果服务器配置为仅使用 DSA 证书，则无法升级到 TLS 1.3。
TLS 1.3 支持的密码套件与 TLS 1.2 及更早版本不同。如果应用程序硬编码了不再支持的密码套件，那么它可能需要在不修改应用程序代码的情况下无法使用 TLS 1.3。
为了降低兼容性风险，这个 TLS 1.3 实现将实现并默认启用向后兼容模式。应用程序可以根据需要关闭向后兼容模式，并开启或关闭 TLS 1.3。
测试
将开发或增强测试，以验证以下一般要求：
- 验证（D）TLS 1.2 及之前版本没有兼容性问题。
- 验证实现不会以意想不到的方式破坏向后兼容性。
- 验证实现不会引入任何意外的互操作性问题。
- 验证没有显著的性能影响。
- 验证在客户端和服务器模式下，实现都能与其他 TLS 1.3 实现进行互操作。
风险和假设
为了进行互操作性测试，需要一个支持 RFC 的第三方 TLS 1.3 实现。
依赖项
TLS 1.3 需要支持 RSASSA-PSS 签名算法（8146293）。