On Tue, 29 Apr 2025 21:51:00 GMT, Artur Barashev <abaras...@openjdk.org> wrote:
>> The current key manager is SunX509, which is configured in the >> java.security. The SunX509 algorithm does not check the local certificate. >> The PKIX algorithm should be preferred now so that the default key manager >> could be more robust. >> >> Compatibility considerations: >> >> 1) Customers using local certificates signed using algorithms prohibited by >> the default configuration (notably MD5 and SHA1) no longer will be able to >> use such certificates without modifying algorithm constraints in >> `java.security` config file. >> >> 2) Performance impact: there is about x2 performance decrease for full >> (non-resume) TLS handshake: >> >> **SUNX509** >> Benchmark (resume) (tlsVersion) Mode >> Cnt Score Error Units >> SSLHandshake.doHandshake true TLSv1.2 thrpt 15 19758.012 ± >> 758.237 ops/s >> SSLHandshake.doHandshake true TLS thrpt 15 1861.695 ± >> 14.681 ops/s >> SSLHandshake.doHandshake false TLSv1.2 thrpt 15 **1186.962** >> ± 12.085 ops/s >> SSLHandshake.doHandshake false TLS thrpt 15 **1056.288** >> ± 7.197 ops/s >> Finished running test 'micro:java.security.SSLHandshake' >> >> **PKIX** >> Benchmark (resume) (tlsVersion) Mode >> Cnt Score Error Units >> SSLHandshake.doHandshake true TLSv1.2 thrpt 15 19724.887 ± >> 393.636 ops/s >> SSLHandshake.doHandshake true TLS thrpt 15 1848.927 ± >> 22.946 ops/s >> SSLHandshake.doHandshake false TLSv1.2 thrpt 15 **511.684** >> ± 5.405 ops/s >> SSLHandshake.doHandshake false TLS thrpt 15 **490.698** >> ± 6.453 ops/s >> Finished running test 'micro:java.security.SSLHandshake' > > Artur Barashev has updated the pull request incrementally with one additional > commit since the last revision: > > Address review comments Well, technically the current 1ms takes into account both the client side and the server side of the handshake. Last time I checked, they were more or less evenly split. The 1ms slowdown will happen entirely on the server side, so it's more of a 3x slowdown. Most of the time an extra millisecond doesn't matter, but it can be a factor in the server startup time on a busy server. We currently invalidate all session resumption tickets during server restart. Re your point 3: what's the observable difference? If the certificate we can offer doesn't meet the peer's expectations, will we fail the handshake on the server side instead of failing on the client side, or is it something else? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2850325489
