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 >>
