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

[Xuelei Fan]

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