Add FFDHE groups to supported_groups

[dcooper16]

There seems to be a bug in the code behind tickets.fujifilmusa.com (#2116). With a TLS 1.2 ClientHello, this server will not negotiate a TLS_DHE_* cipher suite if the supported_groups extension is present, but does not include an FFDHE group. The result is that the TLS_DHE_* cipher suites are missed by cipher_pref_check() and ciphers_by_strength().

The server's behavior seems to be inconsistent with RFC 7919, but adding FFDHE groups to the supported_groups extension in a TLS 1.2 and below ClientHello doesn't seem to cause problems for other servers. So, this PR adds the FFDHE groups that are currently in supported_groups extension for the TLS 1.3 ClientHello to the TLS 1.2 and earlier ClientHello.

[tonyguadagno]

@dcooper16 so it sounds like i have got a problem on my end as well? is that right?

[drwetter]

@tonyguadagno: mind to divulge the Tomcat version and the SSL/TLS library used?

[dcooper16]

@dcooper16 so it sounds like i have got a problem on my end as well? is that right?

Yes, I believe so. However, it seems unlikely to cause problems in practice, since the TLS_DHE_* cipher suites are not very widely used. I would guess that most clients will negotiate one of the TLS_ECDHE_* cipher suites. Clients that don't support any TLS_ECDHE_* cipher suite would be unlikely to include a supported_groups extension in their ClientHello.

There may be some clients that support some TLS_ECDHE_* cipher suites (and so include a supported_groups extension), but don't support any of the TLS_ECDHE_* cipher suites offered by your server. If these clients do support any of the TLS_DHE_* cipher suites that you server supports, then the connection attempt would fail when it should have succeeded. However, this seems to be an unlikely scenario.

[tonyguadagno]

@drwetter is it ok if i DM you that info?

[drwetter]

Thanks @dcooper16 !

@tonyguadagno : Of course! Just look at the output of grep SWCONTACT testssl.sh

[tonyguadagno]

@drwetter i guess the joke is on me, because i could not find your email addr....so i wrote up a description and you can download it here. i will delete when you are done downloading
https://ffcpftp.fujifilmusa.com/WebClientNew/index.html/?ShareToken=46A73288768FD10079A18656974D92843FC79AC9

[drwetter]

Thanks, got that @tonyguadagno . Can remove that!

(and comment later on that)

[tonyguadagno]

@drwetter I finally got around to running the new script against my local openssl and it looks a lot better. btw, it claims that edge would now negotiate any ciphers...is that the OLD edge or new chromium based edge...because i am running new edge (Version 99.0.1150.30 (Official build) (64-bit)) and it seems fine.

i am not sure how to attack the problem on my side....

[drwetter]

WRT the client siumulation. It's an older version of Edge we use. We probably need an update. My humble guess is that maybe newer Edge browsers take understand RSA-PSS.

To my knowledge Edge was always Edge with Webkit from Chrome. Not 100% sure though.

<offtopic>Feel free to use https://github.com/drwetter/automate_tomcat </offtopic>

[tonyguadagno]

@drwetter automate_tomcat looks cool, i will check it out...btw, i just upgraded to the most current of that major version.

as for the original issue, it seems like i am not configuring something properly to cause this to happen...given my environment, do you know where i should look? is this a bouncycastle issue?

[drwetter]

@dcooper16 sent me some input but I won't appear to take credit for that, so maybe he can respond.

[dcooper16]

What I sent @drwetter was related to this PR's issue. I found bcgit/bc-java#718 reporting the problem with the way that Bouncy Castle handles FFDHE cipher suites when the ClientHello includes a supported_groups extension that doesn't specify any FFDHE groups.

I am not familiar with Bouncy Castle, so have no idea how to configure it so that its TLS server will use non-PSS signature algorithms.