[8u] RFR : TLSv1.3 protocol support
Alexey Bakhtin
alexey at azul.com
Tue May 12 18:34:34 UTC 2020
Hello Martin,
Thank you for coordinating the review process for this feature.
As you suggested I’ve rebased TLS1.3 implementation.
Now it is based on the 11.0.7 and applicable to 8u262
The full version of the patch is located at: http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/full/ <http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/full/>
This patch includes the following bug fixes (in addition to listed previously):
JDK-8225766: Curve in certificate should not affect signature scheme when using TLSv1.3
JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3
JDK-8218889: Improperly use of the Optional API
JDK-4919790: Errors in alert ssl message does not reflect the actual certificate status
JDK-8221270: Duplicated synchronized keywords in SSLSocketImpl
JDK-8229733: TLS message handling improvements
JDK-8232424: More constrained algorithms
JDK-8232581: Improve TLS verification
JDK-8235691: Enhance TLS connectivity
As suggested, I’ve split out the patch into the set of steps for better understanding the origin of the files and changes.
1) Remove files of original TLSv1.2 implementation that are not required for TLSv1.3 implementation.
http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step0/ <http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step0/>
2) Add TLSv1.3 implementation classes from 11.0.7
http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step1/ <http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step1/>
This patch also includes changes in the java.security property file and adds TLSv1.3 protocol definition in the SunJSSE provider class
3) Remove DTLS protocol implementation
http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step2/ <http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step2/>
4) Fix JDK 8 compatibility issues
http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step3/ <http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step3/>
In most cases these changes related to using a class from another package or different language constructions.
Also, this fix includes changes in the HandshakeHash class caused by the absence of MessageDigestSpi2 interface
5) Exclude JDK-8148188 (JFR security events) as it is not supported in 8u yet
http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step4/ <http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step4/>
6) Backport JDK-8038893 (Recertify certificate matching) for TLSv1.3
http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step5/ <http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step5/>
7) OCSP stapling support
http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step6/ <http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step6/>
OCSP is disabled by default on the client and server side.
8) Add TLS_KRB5 cipher suites according to RFC-2712
http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step7/ <http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step7/>
This functionality was excluded from the TLSv1.3 implementation in JDK11
Backport TLS_KRB5 cipher suites from the JDK8u
9) update for jtreg tests
http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/test/ <http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/test/>
This part is not separated yet. I’m going to sort it in the next iteration.
Also, this patch does not include porting of the sun/security/pkcs11/sslecc tests. It's in progress.
JCK8c tests passed, javax/net/ssl and sun/security/ssl jtreg test passed.
tier1 and tier2 tests (except of sun/security/pkcs11/sslecc) are passed.
Please verify that the keystore files in the test/sun/security/ssl/etc directory are updated by the patch
Regards
Alexey
> On 7 May 2020, at 20:56, Martin Balao <mbalao at redhat.com> wrote:
>
> Hi,
>
> To proceed with the review of this proposal, we agreed on the following:
>
> * There will be a rebase of Webrev.04 to get TLS-related files from 11.0.7
> * Webrev.05 will be based on 8u262 (so no changes between 8u242 /
> 8uMR3 and 8u262 should be missing)
>
> * Files replaced will appear as new files in the changeset, and changes
> on top of them will appear in a separate patch
> * This view is mainly for reviewing purposes. We will then decide how
> to make it visible in the repository.
>
> * Current test failures on sun/security/ssl will be fixed
> * No regressions should be observable in JDK-tier1, JDK-tier2 and
> sun/security/ssl
>
> * As a review strategy, I'll separate patch changes in 2 groups:
> * Changes within sun/security/ssl namespace
> * Focus will be on changes required on top of replaced files to work
> on 8u
> * This should work as a coherent unit, implementation of the SunJSSE
> provider and javax.net.ssl API
> * Changes out of sun/security/ssl namespace
> * Focus will be on each particular change
> * File replacement is not expected here
> * For each group, I need to understand the rational behind each change
> and the implications on other files (involved changesets scope)
> * We will document these findings in the public list (here)
>
> * Azul may decide to propose a fallback scheme to bring the 'legacy' 8u
> TLS engine as a configurable non-default provider. This was not strictly
> required as part of my review but we will certainly evaluate it.
>
> * More independent reviewers are welcomed. So far, there are internal
> reviewers from Azul and externals from Red Hat.
>
> * Target date for inclusion is still under discussion; but most of the
> review work is expected for the end of May.
>
> Thanks,
> Martin.-
>
More information about the jdk8u-dev
mailing list