Diffie-Hellman group parameters for SSH

[ageis]

/etc/ssh/moduli contains the default prime numbers that are bundled with OpenSSH on Ubuntu.

In light of recent research on weak DH¹ ² we should probably think twice about using common primes, or including any 1024-bit primes at all—and generate our own moduli of 2048 bits or greater.

The risk here is mitigated by the extensive firewalling preventing direct SSH access to either server from the open internet, so we are relying additionally on the not-super-strong 1024-bit RSA cryptography in the Tor hidden service protocol (and stealth authentication) which is in the process of being upgraded. An unprecedented investment of massive computation resources capable of breaking both Tor and the SSH key exchange at the same time would be catastrophic.

Fortunately, the servers are preferring Curve25519 and SHA2 in KexAlgorithms³.

I know absolutely nothing about discrete logarithmics or field sieve analysis, but I will quote from the paper which speculated about how the NSA is able to decrypt a majority of connections through a break in Diffie-Hellman key exchange:

Since a handful of primes are so widely reused, the payoff, in terms of connections they could decrypt, would be enormous. Breaking a single, common 1024-bit prime would allow NSA to passively decrypt connections to two-thirds of VPNs and a quarter of all SSH servers globally. Breaking a second 1024-bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites. In other words, a one-time investment in massive computation would make it possible to eavesdrop on trillions of encrypted connections.

Additional links: https://security.stackexchange.com/a/41947 http://entropux.net/article/openssh-moduli/

[garrettr]

Fortunately, the servers are preferring Curve25519 and SHA2 in KexAlgorithms³.

This only matters if the SSH clients that typically connect to them also prefer or at least support these KexAlgorithms. In the case of SecureDrop SSH, that's Tails on the Admin Workstation. Does the default SSH client configuration on Tails support these algos?

[jacksingleton]

So I've done a bit of research on tor's DH groups.

At least for 0.2.5 and 0.2.6 (the versions included in Jessie and the Tor Debian repo respectively) tor by default uses 1024 bit DH groups from apache2 (embedded in the source, https://github.com/torproject/tor/blob/maint-0.2.6/src/common/crypto.c#L2023).

BUT, it looks like there is an infrequently used config parameter called DynamicDHGroups. There's not a lot of documentation on this, but despite being originally implemented only for bridge servers (https://trac.torproject.org/projects/tor/ticket/4548) I think it also applies to hidden services as described in the ticket above and indicated in the code (https://github.com/torproject/tor/blob/maint-0.2.6/src/or/config.c#L1507) can someone more familiar with tor verify this?

Interestingly, this functionality was removed from 2.7 earlier this year: https://github.com/torproject/tor/commit/511ca9b91cec03f4ef6f23adccd5cdd47a245e5f

[jacksingleton]

I guess I should add what I'm proposing is that we we check that DynamicDHGroups applies to hidden services, and if so, add DynamicDHGroups 1 to https://github.com/freedomofpress/securedrop/blob/develop/install_files/ansible-base/roles/common-app/files/torrc-app

[garrettr]

@jacksingleton Great analysis, I've been wondering about how the weak DH attack affects Tor. Could you create a new issue for this though, so we have two issues? e.g.

1. Mitigate weak DH in our SSH configuration
2. Mitigate weak DH in our Tor configuration

[jacksingleton]

Definitely - https://github.com/freedomofpress/securedrop/issues/1191

[greyspectrum]

I may have something useful to contribute. I wrote a small script to try and set good defaults for SSH, leaning heavily on stribika's work (available here: https://stribika.github.io/2015/01/04/secure-secure-shell.html).

My script removes small primes from /etc/ssh/moduli and edits /etc/ssh/ssh_config to set secure default ciphers, block cipher modes, MACs, & other settings:

https://github.com/greyspectrum/auto-ssh/blob/master/auto-ssh.sh

I see that SSH configuration for the SecureDrop server is handled by Ansible. Is there a place for a shell script to handle hardening the Tails client configuration for the Admin Workstation? If something like this would address this issue, I'm open to working on it and coming up with something workable to submit for peer review here.

[psivesely]

Good blog post! I'd like to work together to implement these suggestions because it seems like most the recommendations you make are spot-on. We should perhaps re-evaluate the situation--specifically with the versions provided by Debian 7 Jessie and Ubuntu 14.04 Trusty in mind--but I don't think much if anything has changed for this distros since you wrote it. Also, see constraints regarding OTP and an Ansible (https://github.com/freedomofpress/securedrop/issues/1283#issuecomment-218895743). Last on constraints we're pretty set on avoiding adding additional bash scripts in favor of Ansible, or at least Python (https://github.com/freedomofpress/securedrop/issues/1409).

UsePrivilegeSeparation=sandbox
UsePrivilegeSeparation yes
StrictModes yes

Fortunately, RSA using SHA1 is not a problem here because the value being signed is actually a SHA2 hash. The hash function SHA1(SHA2(x)) is just as secure as SHA2 (it has less bits of course but no better attacks).

Can you provide a source for this claim? I remember seeing a proof in a cryptography class that f(f(x)) is not necessarily one way, even if f(x) is. I think you're probably right in this case, and I think counterexamples may be more contrived, but it's at least not an assertion that immediately follow mathematically.