How to Protect Yourself from NSA Attacks on 1024-bit DH
eff.org
eff.org
How else do you think we should do this?
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?
[0]: https://weakdh.org/
OpenVPN? SSH? Nginx? Apache?
Where are the bugs to make these not use insecure dhparams by default?
(I'm not sure Apache even defaults to enabling forward secrecy by default, without which you're not exposed to DH at all).
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.> 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.
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.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?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.
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.
I'm not saying people shouldn't do it. But just be aware of the trade-off.
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.
OpenSSH 7.0 and above disable group 1 Diffie-Hellman by default.
From http://www.openssh.com/txt/release-7.0:
Support for the 1024-bit diffie-hellman-group1-sha1 key exchange is disabled by default at run-time. It may be re-enabled using the instructions at http://www.openssh.com/legacy.html
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.
Edit: Thanks for the edit! What I was looking for.
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....
Fortifying the current weakest link raises the overall security of the remaining system. Whether your threat model includes the NSA or not, disabling the weakest TLS algos is likely to increase your network security.
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.
The practical reason is probably that using DHE with TLS is already many times slower than (plain) RSA. This would only make it slower.
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: >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 is what you want. More at SafeCurves: 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...
* Mozilla's Security/Guidelines/OpenSSH: https://wiki.mozilla.org/Security/Guidelines/OpenSSH
* Guide to Deploying Diffie-Hellman for TLS: https://weakdh.org/sysadmin.html
* Qualys SSL Server Test: https://www.ssllabs.com/ssltest/index.html
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.
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.
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.
With standard transistor costs and utilization, this would cost about $2 per chip to manufacture, after fixed design and tape-out costs of roughly $2M [32]. This suggests that an $8M investment would buy enough ASICs to complete the DH-1024 sieving precomputation in one year.
$8 million is pocket change for the NSA, who's estimated yearly budget is around $10 billion.
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.
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.
I get what the other poster says about asking the provider, but I wouldn't have much confidence in the answer.
As an alternative, VPSs are cheap nowadays and you can easily spin up a VPN server automatically with something like Streisand
Chrome: 46.0.2490.71 Linux: 3.19.0-30-generic
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 ?
No it actually doesn't and shouldn't. It would create a tyranny of the majority.
It took less than 200 years for it to devolve into a full-blown plutocracy.
That's highly impratical. NSA's budget isn't infinite and they have many other operations that would also require funding.
* they collect bulk data, then develop the tools to sort them out
If the government was so repressive, people would know about it. It's america, not Russia. There are many things in place which makes it difficult for the government to literally take advantage of all this data.
The power of the government getting into your personal life to blackmail you into submission (for a multitude of purposes) is something everyone needs to worry about.
The fact that they are the defacto spy agency means they can simply lie about you, and claim their spy powers tell them so, and therefore you are guilty. (Just make sure to claim national security privileges on the information gathered so they cant argue against their accuser.)
I might be wrong, but I feel like I must have misunderstood entirely the thrust of your comment due to how oppositely I interpret this question.
* Hackers/crackers/phishers and organized crime. The NSA data troves _must_ be a juicy target. If any malicious intruder gets access to the data (I know, highly unlikely), what could they use it for? Surveillance, tracking, blackmail, extortion, political affiliations, personal beliefs, etc. What if they don't target you, but rather political leaders in the US. That would make the holders of that information _way_ more powerful than any political campaign donor.
* Have a US security clearance? You are subject to very high standards of conduct. Anything that could impair your judgement or lead to possible blackmail of you or your family is potentially grounds for taking away your security clearance (which likely means you can no longer do your job). Alcohol addiction, gambling addiction, sexual relationships, history of crime, immoral behaviors, etc. Gen David Patreus (Director of the CIA, IIRC) was in an extra-marital affair and tried to his this fact from "the company" and from politicians. In this scenario, he is a "bad guy".
* You are assuming the NSA only uses records for official purposes. We have already heard that some NSA employees have been reprimanded for snooping on their spouses and neighbors using work tools.
* It's not as if the NSA has a perfect record. Snowden wasn't even close to being the first whistleblower and it looks like there may be another post-Snowden disclosure. The NSA doesn't have control of its own people (or contractors) so I assume it doesn't have perfect security procedures either. That means it is open to threats against its data and procedures from both inside and out.
* The NSA is suspected to have tipped off the DEA/DHS and FBI for cases that don't involve terrorism or national security. NSA techniques are suspected to have been adopted by much of DHS. This means the threshold to be considered a "bad guy" is now a lot lower than the NSA used to be tasked with watching. Apply the slippery slope argument. What if the NSA quietly helps out with civil cases (such as MegaUpload) and not just criminal? What if it goes even further?
* The NSA isn't the only organization trying to gain access to sensitive internet communications. If anyone else finds out how to take advantage of some of the same tricks the NSA uses, they could potentially have access to the same data and communications. Think nation-states, organized crime, disorganized criminals, even marketing/tracking companies with questionable ethics.
* If SSL / TLS is no longer beyond cracking in near-real-time, MITM is now possible. This could set back peoples' faith in the security underpinnings of the web even more than it has been eroded in recent years. Even worse if people don't find out about it.
Anybody who is afraid of parallel construction.
And if you're not, you should be.
I've read the wikipedia article, and I don't see how I should be afraid of it. Or maybe I don't understand it properly. Anyway, this article would be targeting people who are the target of the NSA, like political dissidents or journalists.
That in itself should worry you.
Wow. Seriously, why would you think they had that right?
If the link in their HN profile is to be believed, the person you are replying to is almost certainly a US citizen. The NSA is not authorized for domestic surveillance, as General Alexander admitted when he perjured himself in front of Congress[1]. It's in their charter, it's in the 4th Amendment and a couple hundred years of legal precedent. We even addressed these limitations in the Church Committee.
So I really don't understand why you would believe they had the right to spy on domestic targets. Besides, the game played by the FVEY members is letting GCHQ do the spying on US targets, not the NSA.
If the government had cameras inside your house set to record 24x7 would you act any differently than you do today? Are you breaking any laws inside your home, if not, what are you trying to protect yourself from by refusing access?
Have you ever avoided visiting a website, searching for information on certain subjects, or held back writing something online that you felt strongly about because you were afraid of possible repercussions in the future?
If yes, then that is an example of the government eroding our rights which are protected by the first and fourth amendments. The right to privacy online is just as important as the privacy you enjoy (take for granted?) within your own home.
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?
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.
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.
Reminder: 2048 bit discrete logs aren't just twice as hard as 1024 bit discrete logs!
Yes: 2048 bit RSA and DH are significantly slower than 1024 bit, and that's a big part of why they're still in use.
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.