mozilla/cipherscan

int/modern misreport insufficient DHE/ECC bits for PFS

Opened this issue · 2 comments

My system is configured to use the P-384 curve rather than P-256, like so:

prio ciphersuite protocols pfs curves
1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-384,384bits secp384r1

In this config, I get this output in analyze.py:

<site>:443 has intermediate ssl/tls
<snip "old">

Changes needed to match the intermediate level:
<cut for brevity>
* consider using DHE of at least 2048bits and ECC of at least 256bits

Changes needed to match the modern level:
<cut for brevity>
* disable TLSv1.1
* disable TLSv1
* use DHE of at least 2048bits and ECC of at least 256bits

This appears to be because intermediate and modern both set the "must_match" flag when calling has_good_pfs(), which means they require exactly those 2 bit levels (2048 for DHE, 256 for ECC), or will complain.

https://github.com/jvehent/cipherscan/blob/master/analyze.py#L24
https://github.com/jvehent/cipherscan/blob/master/analyze.py#L183
https://github.com/jvehent/cipherscan/blob/master/analyze.py#L238

"old" works fine- it specifies must_match=True as well, but it also recommends specific values to use for maximum compatibility, so this seems reasonable.

I have a similar problem.
But I tested it with EC prime256v1 (secp256r1) and dhparam 4096 with 2048 bits RSA key.

I looked at the code and saw that it was checking that the size of dhparam should be the same as the size of the RSA key.

I'm not sure this is the right logic. At least ssllabs does not find anything wrong with this combination.

Is it still a bug or not?

the code probably should translate the keysize to an abstract security level and compare those, so that it's possible to compare RSA or FFDH to ECC key sizes