TLS v1.3 extensions in TLS v1.2 handshake

[Fridrich Strba]

Hello, good people,

On 25/05/2021 12:18, Severin Gehwolf wrote:
> Fridrich, is this an 8u-only problem you are observing? Would you have
> some details about the problem so that I can file a bug for you?

The problem is not 8u-only strictly speaking, but in jdk11u, where it is 
surely also present, it is not a regression, because the handshake was 
working the same way at the 11.0.0 release time. In jdk8, we had the tls 
1.2 implementation until a year or half ago, and then we backported the 
jdk11 implementation to support tls1.3. Since then, a tls1.2 handshake 
emits the two new extensions and some servers out there have problem 
with those extensions for some reasons.

Users that communicate to those kind of devices gave up communicating 
using Java 11, and settled on the other LTS version that is active and 
was working until u252 at least.

One of problems one of our customer hit was when a particular version of 
erlang is doing the server side on a third party device. The problem is 
exactly the one that is outlined here https://bugs.erlang.org/browse/ERL-973

I agree that it is erlang's bug since they bomb on legacy ciphers 
instead of ignoring them in the signature_algorithms_cert extension. 
Nonetheless, this is not a system that is easy to deliver upgrade to and 
previously, jdk8's tls1.2 handshake was working for them. With the 
upgrade, it is not working any more. Even if they specify 
'-Djdk.tls.client.protocols=TLSv1.2' on command-line

So I looked into a solution on Java side. And the solution for me was to 
make the jdk8u292 handshake -- when we are not specifying the tlsv1.3 
support -- not emit those two tlsv1.3 extensions. That is basically 
solving the issue. Moreover, the tlsv1.3 handshake looks good too, 
because it is enough to specify the 
'-Djdk.tls.client.protocols=...,TLSv1.3' and the extensions are emitted.

Now, I looked into including a command-line option to make this 
behaviour configurable, but then the code to implement that would be 
much more intrusive then the two-line patch that I sent to the 
security-dev list.

We did not find the supported_versions extension to have any adverse 
effect whenever we were investigating the bugs, but I somehow tried to 
make the handshake to look like the old handshake was looking before.

I hope I was clear enough about the problem. Now, I need two kind of 
information:

1) Does this look like something that could be applied in jdk8u?

2) If not, is this patch harmful if a downstream builds? I don't think 
so as I read the code, but then I cannot claim universal knowledge either.

Cheers

Fridrich