RFR 8223482: Unsupported ciphersuites may be offered by a TLS client

[Martin Balao]

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