If I remember correct, there was a serious performance impact when
trying to check every crypto operations before using them (suspend for
seconds or minutes, I cannot remember numbers). That's the underlying
reason why most of the checking got removed in latest JDK releases.
The best approach is still not checking. If it is too ideal, checking at
least as possible. An provider MUST support the JDK required
algorithms; and provider MUST support TLS required algorithms. So there
is no need to check those algorithms. What happens if a provider does
not support those algorithms? Configure the application to avoid the
use of the algorithms, or don't use the provider, as the workaround.
Anyway, it depends on the benchmark. If the performance impact is
minimal, we are happy. Otherwise, we may want to think about
alternative solutions.
Thanks,
Xuelei
On 5/7/2019 1:33 PM, Martin Balao wrote:
Hi Xuelei,
Thanks for having a look.
I'll work on a benchmark to see the impact of this proposal.
I have a couple of ideas but wish we could discuss them before moving to
their implementation.
#1
...............................
Under the assumption that security providers do not change in run time,
we can store "supports" results when SSLCipher instances are created.
There would be a static initialization cost but a negligible run time
cost. The drawback is that the assumption that security providers do not
change in run time is not correct for all use-cases.
#2
...............................
We create many cipher instances to decide if an algorithm is supported
and one of them -depending on which ciphersuite the server chooses- will
be used. We can make something to avoid creating an instance we already
had. Gain would be very low I guess because most of the instances would
be wasted.
Is there something else on your mind? What do you think of this options?
I'll keep thinking.
Kind regards,
Martin.-
On 5/7/19 4:53 PM, Xuelei Fan wrote:
Hi Martin,
Would you mind evaluate the performance impact of the fix and improve it
accordingly?
Thanks,
Xuelei
On 5/7/2019 12:45 PM, Martin Balao wrote:
Hi,
I'd like to propose a fix for "8223482: Unsupported ciphersuites may be
offered by a TLS client" [1]:
* http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/
Testing:
* FipsModeTLS12 (after Webrev.00 modifications) reproduces this bug and
works as a regression test
* No regressions found in jdk/sun/security/ssl
I'd be grateful if someone can have a look.
Thanks,
Martin.-
--
[1] - https://bugs.openjdk.java.net/browse/JDK-8223482
