Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

int/modern misreport insufficient DHE/ECC bits for PFS #119

Open
superawesome opened this issue Apr 2, 2016 · 2 comments
Open

int/modern misreport insufficient DHE/ECC bits for PFS #119

superawesome opened this issue Apr 2, 2016 · 2 comments

Comments

@superawesome
Copy link

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.

@VadimKulagin
Copy link

VadimKulagin commented Apr 6, 2018

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?

@tomato42
Copy link
Member

tomato42 commented Apr 9, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants