JEP 332：传输层安全（TLS）1.3
概述
实现传输层安全 (TLS) 协议的 1.3 版本 RFC 8446。
非目标
支持数据报传输层安全 (DTLS) 协议的 1.3 版本并不是目标。同样，支持 TLS 1.3 的每个特性也不是目标；有关将要实现的内容的更多详细信息，请参见描述部分。
动机
TLS 1.3 是对 TLS 协议的一次重大改进，与之前的版本相比，提供了显著的安全性和性能提升。其他供应商的几个早期实现已经可用。为了保持竞争力并与最新标准保持同步，我们需要支持 TLS 1.3。
描述
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。
此 JEP 的主要目标是实现一个最小的、可互操作且兼容的 TLS 1.3 实现。一个最小的实现应支持：
- 协议版本协商
- TLS 1.3 完全握手
- TLS 1.3 会话恢复
- TLS 1.3 密钥和 IV 更新
- TLS 1.3 更新的 OCSP 钉扎
- 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)。