[8u] RFR : TLSv1.3 protocol support
Alexey Bakhtin
alexey at azul.com
Wed May 13 15:59:03 UTC 2020
Hello,
Please find the patch for sun/security/pkcs11/sslecc regression tests :
http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/test.sslecc/
Now I do not see any regressions in the tiers test run
Alexey
> On 12 May 2020, at 21:35, Alexey Bakhtin <alexey at azul.com> wrote:
>
> 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/
>
> 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/
> 2) Add TLSv1.3 implementation classes from 11.0.7
> 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/
> 4) Fix JDK 8 compatibility issues
> 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/
> 6) Backport JDK-8038893 (Recertify certificate matching) for TLSv1.3
> 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/
> 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/
> 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/
> 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