hi the author of the vuln here. this is my write up http://intothesymmetry.blogspot.ch/2016/01/openssl-key-recov...

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...

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

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.

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.

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).

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

That's great. Now what about smaller companies which have one, maybe two sysadmins?

I tried to be clear in when you're vulnerable and when not, so that you can decide if you're vulnerable or not. The answer in this case is "it depends, very likely not".

This is a good point. I'll be sure to put that at the top of any vulnerabilities I report in the future.

Ok, let's change the URL to that from https://mta.openssl.org/pipermail/openssl-announce/2016-Janu.... An author's writeup counts as the original source, and people always like to find out how it was done.

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!

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

https://boringssl.googlesource.com/boringssl/+/9f226a5f5183e...

David's the best :-)

Interesting that the corresponding ECDH option is still disabled by default and ephemeral keys are cached.

It's about time they did. I always wondered why this was disabled by default.

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.

No.

> 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.

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.