Hacker News Reader

Comment by diafygi | Hacker News Reader

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?

View on HN

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.

The problem (defined as narrowly as possible) should be as simple as finding every application that uses 1024 bit Diffie Hellman and making it use 2048 bit Diffie Hellman instead.

Easy-rsa[1] (OpenVPN's key/cert generation/signing tool) version 3 will generate a 2048 bit diffie hellman key by default. Previous versions of easy-rsa used 1024 bit as default.

Here is a comment written in the vars configuration file for easy-rsa 2.2.2:

    # Increase this to 2048 if you
    # are paranoid.  This will slow
    # down TLS negotiation performance
    # as well as the one-time DH parms
    # generation process.
    export KEY_SIZE=1024

So if you used easy-rsa version 2.2.2 or previous to generate your diffie hellman key for the server, and didn't increase the default size in the vars file before doing so, your server uses a 1024 bit diffie hellman key.

[1]https://github.com/OpenVPN/easy-rsa

From what we know as long as it is a custom 1024-bit DH key and you're not being actively targeted by the NSA you are probably okay. That said, you should still upgrade to 2048-bit (or higher, if you're paranoid) ASAP.

No, this is terrible advice. Stop using DH-1024.

Hence "That said, you should still upgrade to 2048-bit (or higher, if you're paranoid) ASAP."

How can I tell what DH size I'm using from the OpenVPN client side when I connect to an OpenVPN server?

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

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.

  agwa wrote:
  > 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.

NGINX has had the ssl_dhparam directive (allowing dhparam of arbitrary size) since version 0.7.2, released in 2008.

Reply on news.ycombinator.com