Unable to negotiate FFDHE (TLS_DHE_RSA_*) cipher suites when TLS supported Groups extensions is present but contains no ffdhe* code points.

[alt4444]

When using BC code in a TlsServer if the client presents only TLS_DHE cipher suites as possible candidates along with a "support_groups" extension in the "Client Hello" message which does not contain any ffdhe* groups (codepoints between 256 and 511, inclusive) then none of the TLS_DHE_* cipher suites can be selected.

Whilst according to rfc7919:-

If at least one FFDHE cipher suite is present in the client cipher suite list and the Supported Groups extension is either absent from the ClientHello entirely or contains no FFDHE groups (i.e., no codepoints between 256 and 511, inclusive), then the server knows that the client is not compatible with this document. In this scenario, a server MAY select a non-FFDHE cipher suite, or it MAY select an FFDHE cipher suite and offer an FFDHE group of its choice to the client as part of a traditional ServerKeyExchange.

this can be considered correct behavior it does introduce a number of incompatibilities. Usually if the support_groups extension is present then it is likely (but not a requirement) that the TLS_ECDHE_* cipher suites are present and will be selected above the TLS_DHE_* and a suite will negotiated. However if none of these ciphers are present then TLS_DHE will not be considered.

Is there a possibility that the BC code can be modified so that if the support_groups contain no ffdhe* codepoints then the server can offer a FFDHE group of its choice as per RFC option? The code in question looks to be in AbstractTlsServer::getSelectedCipher Suite() . This could be a configuration system parameter.

[tonyguadagno]

hi, i think i am running into this exact issue on tickets.fujifilmusa.com..... i see this ticket is open and old...will anything be done about it? is there any other way to address this issue? in short, browsers can hit the site without issue, but ssl checkers like www.ssllabs.com cannot.

thanks