
How to Protect Yourself from NSA Attacks on 1024-bit DH - DiabloD3
https://www.eff.org/deeplinks/2015/10/how-to-protect-yourself-from-nsa-attacks-1024-bit-DH
======
agwa
The OpenVPN section is misleading. The dh option is only supported on the
server side. If you try to use it on the client side (which is what this guide
appears to be tailored towards) it will be ignored and you'll use whatever DH
parameters the server provides.

~~~
tikums
It may be misleading but also in the sense that there's no recommendation to
just drop VPN altogether. How about we just stop relying on terribly over-
designed protocols such as VPN and IPSec? Complexity is the enemy of security.

~~~
DiabloD3
We use OpenVPN at work to provide layer 2 access to a management network that
uses a /24 out of the 10/8 range.

How else do you think we should do this?

~~~
tikums
MinimaLT
[http://cr.yp.to/tcpip/minimalt-20130522.pdf](http://cr.yp.to/tcpip/minimalt-20130522.pdf)

------
ikawe
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/](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/](https://www.howsmyssl.com/) out of date?
Shouldn't I be seeing some kind of warning?

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

~~~
rtb
... but clients can guard against weak server-side DHE by rejecting DHE
ciphersuites. So I think the GP was correct that this diagnostic should be
updated.

~~~
mynameisvlad
No, because as agwa pointed out, howsmyssl checks client security. There's
nothing wrong with a DHE cipher suite and it can be used in a secure manner
quite easily. Since this is wholly on the server, and howsmyssl has no way of
testing a server you're connecting to, then there's no possible way for it to
know if your specific connections are okay or not. Based solely on the client
suites tested, DHE would still be considered secure. It's only the interaction
with an insecure server that makes it insecure.

~~~
kpcyrd
weakdh can be mitigated client side. The website[0] itself has a test for it,
which works by requesting this file[1].

[0]: [https://weakdh.org/](https://weakdh.org/)

[1]:
[https://dhe512.zmap.io/dhe512test.js](https://dhe512.zmap.io/dhe512test.js)

------
diafygi
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?

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

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

------
ck2
Is this really a "best practice" to disable dhe in firefox/chrome?

Won't that just make the server/browser negotiate an even weaker scheme if
they cannot find a matching higher set?

My firefox goes from:

    
    
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
    
    

to:

    
    
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
    
    

Do you really want TLS_RSA? How about 3DES?

~~~
snuxoll
RSA key exchange is still secure, but you lose PFS when downgrading to it
since very few servers will generate ephemeral RSA keys like they will when
using DHE. 3DES is secure, but slow.

Ideally, you would want to just disable all ciphersuites that don't use ECDHE
to do the key exchange, but that would probably hurt compatibility.

------
vitd
Anyone have a way to fix up Safari on OS X 10.11?

~~~
valarauca1
You can't fix this on the client side, but on the server side.

~~~
thephyber
Please read the article before posting. There _are_ some things that can be
done client side to raise the minimum level of encryption, although not to
raise the maximum level of encryption.

One tactic the NSA and at least one vendor are suspected to use is to
inject/drop a header which prevents the client and server of an SSL/TLS
connection from settling on the highest level of encryption that both the
client and server have. In this case, it's best for your client to disable the
weakest forms of SSL/TLS encryption which raises the minimum level of
encryption of the connection.

That's what much of this EFF article describes, although it fails to describe
these steps for browsers other than Firefox and Chrome.

------
hsivonen
Sadly, users who follow this advice will forget that they did by the time they
can't figure out why connections fail to servers that have been configured for
forward secrecy only but run an ECC-incapable version of Apache (thanks to
long-term support Linux distros keeping old Apache around).

~~~
yuhong
Apache decides the DHE keys, OpenSSL decides the ciphersuites used. Red Hat
didn't even enable ECDHE until they moved to OpenSSL 1.0.1 in RHEL 6.5 in late
2013.

~~~
hsivonen
Last I checked (updates may have fixed this), Ubuntu 12.04 had ECC-capable
OpenSSL but ECC-incapable Apache.

~~~
scintill76
tlsinterposer[0] helps in cases like this. (tldr: LD_PRELOAD middleware to
upgrade an application's OpenSSL support without modifying the application.)

[0]
[https://github.com/Netfuture/tlsinterposer](https://github.com/Netfuture/tlsinterposer)

------
ironsides
Tor browser 5.0.3/latest(based on firefox 38.0.3) is not listed. However, it
does have .dhe enabled/"true" set in the config file. For those of you running
- it might be good to add this to your disable "to-do" list.

~~~
MacsHeadroom
It's worth noting that modifying Tor Browser like this makes your TB easier to
fingerprint/track.

I'm not saying people shouldn't do it. But just be aware of the trade-off.

------
lukeasrodgers
If you're having trouble following the instructions to secure SSH on OSX, try
following the directions here: [https://mochtu.de/2015/01/07/updating-openssh-
on-mac-os-x-10...](https://mochtu.de/2015/01/07/updating-openssh-on-mac-
os-x-10-10-yosemite/)

Without using the brew dupe and ` --with-keychain-support` flag, I was getting
cipher errors when trying to use SSH after following the instructions linked
to in TFA.

NB: I am not a security expert.

~~~
zachberger
You may have a cipher mismatch with the server. If you use ssh with the -vv
flag you can see which ciphers the server is supporting and compare that to
the ciphers your client supports.

~~~
lukeasrodgers
Thanks for the tip--the server supports that cipher though, it was just an
issue with my client.

------
windexh8er
Is TLS w/3DES still considered safe (TLS_RSA_WITH_3DES_EDE_CBC_SHA)? My guess
is that it's the next to "go", but is it a risk currently?

~~~
agwa
3DES (the cipher) is secure but incredibly slow. It's often included in server
ciphersuites to support old clients (the alternative for old clients is RC4,
which is not secure).

Edit: I should mention though that 3DES as used in TLS is vulnerable to BEAST
if not mitigated client-side and possibly Lucky 13 too, so the ciphersuite
ought to be the next to "go" along with the other CBC ciphersuites. Still
better than RC4 though.

~~~
windexh8er
Thank you I had an idea of the performance delta. But, comparatively (to
something like TLS_RSA_WITH_AES_[256|128]_CBC_SHA) how does it compare?

Edit: Thanks for the edit! What I was looking for.

~~~
cnt0
Very poorly: [http://zombe.es/post/4078724716/openssl-cipher-
selection](http://zombe.es/post/4078724716/openssl-cipher-selection)

~~~
windexh8er
Thank you for the reference!

------
tux
If you use "Chromium" on linux instead of "Chrome" you can do this; (create a
shortcut with this command)

chromium --cipher-suite-blacklist=0x0033,0x0039,0x009E,0xcc15

Also if you use Nginx web browser; (read this article)

[https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx....](https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html)

~~~
tokenizerrr
Nginx is a server, not a browser.

------
mikelyons
Wont this just prompt NSA to crack the others if they see a spike in disabled
crackables?

~~~
kentt
Valid concern, but that's a bit a defeatist attitude. Yes if we all switch to
more secure encryption, they will try to crack or cripple those, but to crack
1024 DH was a multi billion dollar effort (just on the cusp of what it
feasible for them). If we can use something more secure, then it's out of
their ability. The good part is that often we can increase the difficulty to
crack something by an order of magnitude without a high cost to us.

------
devit
Is there any reason why in TLS the DH g^x the client sends is not encrypted
with the server's RSA key?

That way, a DH compromise merely lose forward secrecy and the data would still
be safe as long as the server private keys are not compromised.

~~~
xnyhps
Strictly speaking that's not forward-secret anymore, as stealing the private
key gives _some_ advantage to cracking the session.

The practical reason is probably that using DHE with TLS is already many times
slower than (plain) RSA. This would only make it slower.

------
alwillis
My big picture take-away is:

It seems that the NSA (and possibly other state-level actors) can access
encrypted traffic that uses 1024-bit Diffie-Hellman that use commonly-used
prime numbers. This means HTTPS, SSH, IPsec, SMTPS, and protocols that rely on
TLS are potentially vulnerable. Where’s there’s smoke, there’s fire and
there’s a lot of smoke indicating the NSA can do this. They have the money,
technology, infrastructure and the technical ability to pull this off.

From [https://weakdh.org](https://weakdh.org): >Breaking the single, most
common 1024-bit prime used by web servers would allow passive eavesdropping on
connections to 18% of the Top 1 Million HTTPS domains. A second prime would
allow passive decryption of connections to 66% of VPN servers and 26% of SSH
servers. A close reading of published NSA leaks shows that the agency’s
attacks on VPNs are consistent with having achieved such a break.

 _This is real_.

It’s all of the networking infrastructure that no longer gets
software/firmware updates running 512, 768 and 1024-bit Diffie-Hellman that
are likely already being exploited, not to mention all of the old VPNs, email
servers, SSH clients, etc. that can’t be easily upgraded and can’t use more
secure encryption protocols. After all of the hoopla dies down, this is the
ongoing problem.

 _But don’t panic._

On current operating systems, going to larger 2048-bit Diffie-Hellman or using
Elliptic-Curve Diffie-Hellman Key Exchange (ECDH) addressed the problem. As
has been pointed out several times, 2048-bit Diffie-Hellman isn’t double the
strenght of 1024-bit Diffie-Hellman; we’re going from a keyspace of 2^1024 to
2^2048. So unless there’s an unprecedented crytography breakthrough or quantum
computers start sprouting like Dandelions, 2048-bit Diffie-Hellman is firmly
in the "it would take more energy than what would be required to boil all of
the oceans on Earth" arena.

If you’re going the ECDHE route, everyone agrees that the NIST curves are
suspect and that Curve25519:
[http://cr.yp.to/ecdh.html](http://cr.yp.to/ecdh.html) is what you want. More
at SafeCurves: [http://safecurves.cr.yp.to](http://safecurves.cr.yp.to).

If you keep up with current cryptography trends, you’re probably already in a
good place, but it doesn’t hurt to check. There are lots of guides on how to
get your stuff right:

* Secure Secure Shell: [https://stribika.github.io/2015/01/04/secure-secure-shell.ht...](https://stribika.github.io/2015/01/04/secure-secure-shell.html)

* Mozilla's Security/Guidelines/OpenSSH: [https://wiki.mozilla.org/Security/Guidelines/OpenSSH](https://wiki.mozilla.org/Security/Guidelines/OpenSSH)

* Guide to Deploying Diffie-Hellman for TLS: [https://weakdh.org/sysadmin.html](https://weakdh.org/sysadmin.html)

* Qualys SSL Server Test: [https://www.ssllabs.com/ssltest/index.html](https://www.ssllabs.com/ssltest/index.html)

~~~
PlzSnow
_" It seems that the NSA (and possibly other state-level actors) can access
encrypted traffic that uses 1024-bit Diffie-Hellman that use commonly-used
prime numbers."_

How does it "seem this"? There's no evidence, no plausibility, no sense here
whatsoever. Someone hypothetically conjectured a magic all-powerful computer
that could magically crack a prime, and that would magically make us all
vulnerable to the government who want to steal the data from my recipe startup
and the church newsletters documents on my laptop.

And therefore, system admins are all recommending upgrading to 2048 keys?

I can't see the sense or logic here. It just seems hysterical conspiracy
nonsense to me.

~~~
schoen
It seems like you're calling section 4.1 of the paper "magical"; do you have
something specific in it to object to that makes you think the estimates are
severely mistaken?

In order to defend against adversaries with undisclosed capabilities, you have
to extrapolate known attack methods and hardware to produce estimates of what
may be practical. _Every_ paper that proposes keylength and parameter size
recommendations does this. If we didn't extrapolate this way, there would have
been no reason to stop using 56-bit symmetric ciphers until 1998 (!). The
hardware necessary to crack such a cipher could have been dismissed as
"magical" because nobody who had built it had published a paper about it.

~~~
PlzSnow
It is magical. There is a magic 36000-core (?) computer that has been running
for years (?). Well no, the paper just invents it. On the hearsay that an
"anonymous nsa official" said they'd cracked something.

It astonishes me that people are running about like rabbits in a headlight on
such flimsy nonsense.

But I understand. It makes us feel important. The new James Bond movie is
coming out. And imagine! We're like a superhero secret agent. We can protect
from the big bad government by increasing all the keys to 2048 bits! And we
get to feel special and important.

Sigh.

~~~
alwillis
_Classified documents published by Der Spiegel [46] indicate that NSA is
passively decrypting IPsec connections at significant scale. The documents do
not describe the crypt- analytic techniques used, but they do provide an
overview of the attack system architecture._

Due to the Snowden leaks, we know the NSA is doing something that they haven't
been able to do previously. The paper just explains, given what we know today,
how this is plausible. There's nothing magical about that.

------
arielweisberg
How can you tell if the commercial VPN service you are using is vulnerable?

The client on mine is very easy to use, but has no debug output/log or console
that I can find so I don't know what it is doing.

~~~
schoen
Do you know what VPN protocol it is? I wonder if it would be easy to figure
out in Wireshark if you had a recording of the beginning of a session.

~~~
arielweisberg
QUIC is what WireShark says I am looking at. I can see the DNS lookup, and
then a stream of encrypted UDP packets with not much plain text in the
payloads.

I get what the other poster says about asking the provider, but I wouldn't
have much confidence in the answer.

~~~
schoen
I'm not really familiar with QUIC, but are there any cryptographic setup steps
that Wireshark can parse out of the first (say) three or four packets that get
exchanged? (Or maybe the key was established when you first used the VPN and
is being cached on your machine and re-used whenever you reconnect?)

------
umrashrf
Not working for Chrome on Linux. Starting Chrome with blacklist arg still
shows _DHE_ entries.

Chrome: 46.0.2490.71 Linux: 3.19.0-30-generic

~~~
kitd
The same for me on Windows 7 Pro 64-bit, Chrome 46.0.2490.71 m

------
JacobiX
The fact that the NSA doesn't include DHE in its Suite B Cryptography
algorithms is quite telling ...

------
forgotusername2
what about just no using encryption and dont doing stupid stuff like
delivering drugs to your house using your own name?

------
jokoon
I get that NSA snooping is abusive if it's the norm. But who exactly would
really want to protect themselves from the NSA?

I mean ultimately, isn't the problem the NSA is snooping on people who aren't
aware of it ? Why would someone try to hide itself from the NSA ? Is it just
because it's a political principle or to just annoy the NSA and discourage
them ? I mean wouldn't this help the bad guys more ?

~~~
jMyles
One of the main things I want to keep private is just family life - conflicts,
love, sex, etc. I don't want the government to know about my private family
life. I don't see how a free, thoughtful, creative society can flourish if the
government can always know the goods on everybody.

~~~
PlzSnow
I don't think the government wants to know about your private family life
neither. I mean, it's edgy to imagine that the government has a secret file on
all of us. But they don't do they? It's just very silly nonsense.

~~~
mikexstudios
That was the argument before Snowden, but we now know that the government
passively records and stores as much information as possible on anyone. So
they _can_ build a secret file on anyone should they feel like it. And they'll
use every piece of information at their disposal (private family life,
shopping and travel habits, what websites you browse, what media you consume,
etc.) to profile you. Ever download a copyrighted file or view pornography?
That will be used against you.

~~~
jonnybgood
> we now know that the government passively records and stores as much
> information as possible on anyone

That's highly impratical. NSA's budget isn't infinite and they have many other
operations that would also require funding.

~~~
macns
Snowden demonstrates the way NSA and the British equivalent operate on demand*
at the documentary film 'Snowden'. You should really skim through it at least,
you will be surprised to what their finite budget can do.

* they collect bulk data, then develop the tools to sort them out

------
rboyd
It's strange that this is all coming up just now. The NSA has had this
technology since at least 1992 when it was revealed in the gripping
documentary movie "Sneakers".

~~~
ryandrake
Then again in Enemy of the State, which should have won the Pulitzer Prize.
Hollywood has been warning us about this stuff for years!

------
olympus
This recent publication illustrates a problem that we have trying to keep our
communications secure. If we all use a single "strong" prime number with our
crypto then the NSA has a huge incentive to pre-compute results from that
single strong number. Now that we know that the NSA is doing this, we won't
all use a proven strong number, and we will all start to do key exchanges with
another method, and it will become the common thread that the NSA can attack.

So the NSA will pretty much always attack whatever common procedure we all use
and find the weak point. If we all used different methods for key exchanges
and encryption then we will all be fractured and the NSA can easily pick off
their targets individually. What's the answer to this problem? Is there crypto
that we can all use that the NSA won't be able to crack even if they have a
strong incentive to do so? And why aren't we all using if such a solution
exists?

~~~
tptacek
Not really. This precomputation attack only works because attacks on 1024 bit
discrete logs were already plausible.

We don't choose cryptographic parameters to make the NSA's job _harder_ ; we
choose them to make the job _implausible_.

So it's exactly the wrong message to take from this paper that we should mix
up parameters more; rather, the message is: don't use weak moduli.

~~~
olympus
> don't use weak moduli.

By this do you mean don't use 1024 bit keys? Would using 2048 bit (or larger)
mean that the NSA wouldn't be able to buy a computer that could do the
computation within a year?

Why don't we all use 2048 bit keys then? Is the communication and processing
overhead so high that we'd rather be vulnerable?

Edit to add: I'm not an expert, but I'm competent enough to force a certain
level of crypto on my computer and to know not to trust the communication when
a website forces a fallback to a lower level. But sometimes I wish there was a
level of explanation (of why we want to do certain things) that was above what
you would give to "Joe off the street" and below the explanation that you
would give to a graduate student in cryptography.

~~~
snuxoll
> By this do you mean don't use 1024 bit keys? Would using 2048 bit (or
> larger) mean that the NSA wouldn't be able to buy a computer that could do
> the computation within a year?

Keep in mind, going from 1024 to 2048 bit DH parameters doesn't double the
search space, it raises it from 2^1024 to 2^2048. At some point the search
space gets so large that you'd need more energy than required to boil all of
Earth's oceans to find the key, which makes such a brute-force attack
implausible.

~~~
cinquemb
I haven't had much crypto-in-practice background (outside of thought
experiments), but I have some math background so I'm quite curious. Shouldn't
people also be worried about non brute force attacks based on finding
mathematical solutions? I mean, "The Uneasy Relationship Between Mathematics
and Cryptography"[0]?

[0]
[http://www.ams.org/notices/200708/tx070800972p.pdf](http://www.ams.org/notices/200708/tx070800972p.pdf)

~~~
tptacek
The attacks we're talking about _are_ non-brute-force mathematical attacks
(specifically, in this case, the index calculus). A pure brute-force attack on
a 2^1024 search space would be comically implausible.

