JEP 332:传输层安全 (TLS) 1.3
概括
实施传输层安全 (TLS) 协议RFC 8446版本 1.3 。
非目标
支持数据报传输层安全 (DTLS) 协议 1.3 版并不是我们的目标。支持 TLS 1.3 的所有功能也不是我们的目标;有关将要实施的内容的更多详细信息,请参阅“描述”部分。
动机
TLS 1.3 是对 TLS 协议的重大修改,与以前的版本相比,安全性和性能得到了显着改进。其他供应商的一些早期实现已经可用。我们需要支持 TLS 1.3 以保持竞争力并跟上最新标准的步伐。
描述
TLS 1.3 是新的 TLS 版本,它取代并废弃了以前的 TLS 版本,包括版本 1.2 ( RFC 5246 )。它还废弃或更改了其他 TLS 功能,例如 OCSP 装订扩展(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。
此 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 )。