
OpenSSL Key Recovery Attack on DH small subgroups (CVE-2016-0701) - zorpner
http://intothesymmetry.blogspot.com/2016/01/openssl-key-recovery-attack-on-dh-small.html
======
asanso
hi the author of the vuln here. this is my write up
[http://intothesymmetry.blogspot.ch/2016/01/openssl-key-
recov...](http://intothesymmetry.blogspot.ch/2016/01/openssl-key-recovery-
attack-on-dh-small.html)

~~~
jvehent
Thanks for the excellent description of the vuln! You mention Apache not being
vulnerbale. I just looked through the Nginx code, and it doesn't seem to be
vulnerable either because Igor Sysoev enabled SSL_OP_SINGLE_DH_USE back in
2008.
[https://github.com/nginx/nginx/blob/master/src/event/ngx_eve...](https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.c#L250)

~~~
asanso
indeed. but there is always Static DH :) even if not so popular...

~~~
jvehent
Ops teams need a clear "should I do emergency patching? yes/no" message when
any vulnerability gets published. In this instance, it looks like this doesn't
require emergency patching unless you're using something unusual to terminate
SSL.

That said, it's a serious issue, no doubt about that.

~~~
blakesterz
I struggle with this sometimes too! So often I read the report and I'm left
wondering if I should panic or not, so I start reading comments here and
elsewhere to figure out if I need to get this patched OMG RIGHT NOW or I can
hold off until the weekend.

I would LOVE a clear "should I do emergency patching? yes/no" it seems like it
would be frequently (maybe not always?) something that could be added to an
announcement.

~~~
jvehent
That's what your local security team should be for ;) At Mozilla, we track
those and inform the various ops teams of our assessments. They very much rely
on us to decide if it warrants emergency patching or not (modulo operational
concerns to upgrade systems outside maintenance windows).

~~~
detaro
Not so great an option if the closest thing to a "local security team" is the
sysadmin asking the question ;)

------
kingkilr
Super happy that the OpenSSL team decided to be proactive and just enable
`SSL_OP_SINGLE_DH_USE` for all users, as well as bump the minimum DH key size.
Better defaults for everyone!

~~~
DannyBee
Yeah, and it looks like BoringSSL did that about a year ago :)

[https://boringssl.googlesource.com/boringssl/+/9f226a5f5183e...](https://boringssl.googlesource.com/boringssl/+/9f226a5f5183e8814ff30e7436a128a823315532%5E!/#F1)

~~~
kingkilr
David's the best :-)

------
voltagex_
If I've generated new 4096-bit DH parameters to get that green A+ on SSL labs,
do I need to regenerate now?

i.e. I've run openssl dhparam -out dhparam.pem 4096 on a potentially
vulnerable version of OpenSSL.

~~~
caf
No.

------
koolba
> OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in
> TLS. It is not on by default. If the option is not set then the server
> reuses the same private DH exponent for the life of the server process and
> would be vulnerable to this attack. _It is believed that many popular
> applications do set this option and would therefore not be at risk._

Shouldn't that be "... do NOT ..."?

Edit: Nevermind the double negative got me. Setting the option (which is not
on by default) mitigates the issue and they're saying many apps do set it.

------
yuhong
Notice that OpenSSL did 768-bit DHE minimum first then 1024-bit DHE minimum
only now, unlike NSS for example. I think the new version of Firefox was
released about two weeks before Oracle released their Java 6/7 fixes for paid
customers.

