Live data from Hacker News

How to Protect Yourself from NSA Attacks on 1024-bit DH

eff.org

1–10 of 140 posts

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#2
Does anyone have links to bugs for the affected programs to make 2048 the minimum by default? It seems like we shouldn't have to continue to manually configure secure settings.

OpenVPN? SSH? Nginx? Apache?

Where are the bugs to make these not use insecure dhparams by default?

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#4
post #2

Does anyone have links to bugs for the affected programs to make 2048 the minimum by default? It seems like we shouldn't have to continue to manually configure secure settings. OpenVPN? SSH? Nginx? Apache? Where are the bugs to make these not use insecure dhparams by default?

http://blog.ivanristic.com/2013/08/increasing-dhe-strength-o...

(I'm not sure Apache even defaults to enabling forward secrecy by default, without which you're not exposed to DH at all).

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#5
post #2

Does anyone have links to bugs for the affected programs to make 2048 the minimum by default? It seems like we shouldn't have to continue to manually configure secure settings. OpenVPN? SSH? Nginx? Apache? Where are the bugs to make these not use insecure dhparams by default?

OpenVPN makes you provide your own parameters; there is no default.

As of Apache 2.4.7, the default DH parameters have the same number of bits as your RSA key, and since CAs have required at least 2048 bit RSA for a few years now, you'll be fine.

OpenSSH does ship parameters that are larger than 1024 bits (in addition to 1024 bit parameters), and with the "group-exchange" kex, sufficiently-secure parameters should be negotiated with clients, although I haven't looked too closely to see if this might be vulnerable to downgrade attacks.

Last I looked nginx used fixed 1024 bit parameters, which is very bad. I don't know if this has changed or if there's a bug report.

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#6
The article says:

    You want to make sure that you don't see the text "_DHE_" in the list of ciphersuites.`
And the article links to https://www.howsmyssl.com/, which shows me these in my list of cipher suites:

    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA

But the heading says: "Your SSL client is Probably Okay."

Is https://www.howsmyssl.com/ out of date? Shouldn't I be seeing some kind of warning?

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#7
post #2

Does anyone have links to bugs for the affected programs to make 2048 the minimum by default? It seems like we shouldn't have to continue to manually configure secure settings. OpenVPN? SSH? Nginx? Apache? Where are the bugs to make these not use insecure dhparams by default?

FWIU of the situation, we have reason to suspect the government has 'cracked' the default large primes that are commonly used by a bunch of different software packages, including web servers. Assuming they have, the challenge is then defined as determining which applications and sites tend to use these standardized or hard-coded primes.

> Breaking a second 1024-bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites.

I'll point out that agwa's comment is relevant here in mitigation. Without any control over what primes are used on the server side, the only resolution would be to detect the server is using such a prime and then avoid communicating with that server until they've patched their systems. Perhaps someone who knows more about this could comment on how we could go about notifying websites they are using venerable primes?

Maybe a Chrome plugin attached to an IPFS client could be one method to warn on access of sites using default primes.

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#8
post #6

The article says: You want to make sure that you don't see the text "_DHE_" in the list of ciphersuites.` And the article links to https://www.howsmyssl.com/ , which shows me these in my list of cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA But the heading says: "Your SSL client is Probably Okay." Is https://www.howsmyssl.com/ out of date…

There's nothing inherently wrong with the DHE ciphersuites, as long as the server provides secure parameters. Since weakdh is really a server-side issue, and howsmyssl.com is a client-side test, a warning doesn't really make sense.

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#10
post #5
post #2

Does anyone have links to bugs for the affected programs to make 2048 the minimum by default? It seems like we shouldn't have to continue to manually configure secure settings. OpenVPN? SSH? Nginx? Apache? Where are the bugs to make these not use insecure dhparams by default?

OpenVPN makes you provide your own parameters; there is no default. As of Apache 2.4.7, the default DH parameters have the same number of bits as your RSA key, and since CAs have required at least 2048 bit RSA for a few years now, you'll be fine. OpenSSH does ship parameters that are larger than 1024 bits (in addition to 1024 bit parameters), and with the "group-exchange" kex, sufficiently-secure parameters should be…

[deleted]
Post reply on HN