[Java 11新特性翻译]JEP 332 Transport Layer Security (TLS) 1.3

1、写在前面

  本文是在个人学习过程中顺手所得，非专业翻译，文章末尾同步附上英文原版，请各位看官对照阅读，非喜勿喷，谢谢！

2、翻译内容

JEP 332 Transport Layer Security (TLS) 1.3 

JDK11的release版本包含了对TLS1.3（RFC8446）的实现。更多的新特性可以参考JEP332。

对于TLS 1.3，定义了以下新的标准算法名称：

• TLS协议版本名称：TLSv1.3
• SSL Context算法名称：TLSv1.3
• 针对TLS1.3的算法单元：TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384
• X509KeyManager密钥类型：RSASSA-PSS
• X509TrustManager认证类型：RSASSA-PSS

TLS1.3中增加了一个新的安全属性jdk.tls.keyLimits，当处理特定算法的数据量达到指定数量时，post-handshake Key an IV Update会被处罚分发新的密钥。
新增一个新的系统属性jdk.tls.server.protocols用于配置服务端的协议单元。

Note:KRB5加密组件的实现已经被从JDK中移除，因为该算法已经不再安全。
Note:TLS1.3并不能直接兼容以前的版本，尽管可以实现一种后向兼容模式，但升级到TLS1.3仍然存在一定的兼容性风险，主要表现如下：

• TLS1.3使用的是半封闭策略，而1.2及之前的版本使用的都是双工关闭策略，对于依赖于双工关闭策略的应用，升级到1.3时可能存在问题。
• signature_algorithms_cert扩展需要预定义的签名算法来实现证书认证，但实际场景中应用可能会使用不被支持的签名算法。
• 1.3版本不在支持DSA签名算法，如果服务配置了DSA证书，则无法升级到1.3.
• 1.3版本支持的算法单元与1.2及之前的版本不同，若应用硬编码了算法单元，则在升级的过程中需要注意修改代码。
• 1.3版本的session复用行为及秘钥更新行为与1.2及之前的版本不同，若应用依赖于TLS协议的握手过程细节，则需要注意。

系统属性jdk.tls.client.protocols、jdk.tls.server.protocols可以被用于配置客户端和服务端默认协议。

3、英文原版

➜ JEP 332 Transport Layer Security (TLS) 1.3 

The JDK 11 release includes an implementation of the Transport Layer Security (TLS) 1.3 specification (RFC 8446). For more details including a list of the features that are supported, refer to the Java Secure Socket Extension (JSSE) Reference Guide documentation and JEP 332.

For TLS 1.3, the following new standard algorithm names are defined:

1. TLS protocol version name: TLSv1.3
2. SSLContext algorithm name: TLSv1.3
3. TLS cipher suite names for TLS 1.3: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384
4. keyType for X509KeyManager: RSASSA-PSS
5. authType for X509TrustManager: RSASSA-PSS

A new Security Property, jdk.tls.keyLimits, has been added for TLS 1.3. When the specified amount of data of a specific algorithm has been processed, a post-handshake Key and IV Update is triggered to derive new keys.

A new System Property, jdk.tls.server.protocols, has been added to configure the default enabled protocol suite in server side of SunJSSE provider.

Note that the KRB5 cipher suites implementation has been removed from the JDK because they are no longer considered safe to use.

Note that TLS 1.3 is not directly compatible with previous versions. Although TLS 1.3 can be implemented with a backward-compatibility mode, there are still several compatibility risks to take into account when upgrading to TLS 1.3:

1. TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions use a duplex-close policy. For applications that depend on the duplex-close policy, there may be compatibility issues when upgrading to TLS 1.3.
2. The signature_algorithms_cert extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application may use unsupported signature algorithms.
3. The DSA signature algorithm is not supported in TLS 1.3. If a server is configured to only use DSA certificates, it cannot upgrade to TLS 1.3.
4. The supported cipher suites for TLS 1.3 are not the same as TLS 1.2 and prior versions. If an application hard-codes cipher suites which are no longer supported, it may not be able to use TLS 1.3 without modifying the application code.
5. The TLS 1.3 session resumption and key update behaviors are different from TLS 1.2 and prior versions. The compatibility impact should be minimal, but it could be a risk if an application depends on the handshake details of the TLS protocols.

The System properties, jdk.tls.client.protocols and jdk.tls.server.protocols, can be used to configure the default enabled protocols accordingly in the SunJSSE provider if needed.