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.