Logjam TLS attack
weakdh.org
weakdh.org
From the start it has listed the suggestion to set up >2048 DH keys.
If you want to test your site for export ciphers, you can try my other side project: https://tls.so/ - you can also use the SSL labs test but mine is faster for just testing ciphersuite. (And it's open source, so you can use it internally as well).
Mozilla also has a good wiki page for SSL settings: https://wiki.mozilla.org/Security/Server_Side_TLS
Sadly my current phone is stuck on SSLv3 so until I replace it I have no mail on my phone anymore.
One small nit with the paper: it is claimed that there had been technical difficulties with the individual logarithm step of the NFS applied to discrete logarithms, making individual logs asymptotically as expensive as the precomputation. Commeine and Semaev [1] deserve the credit for breaking this barrier; Barbulescu did improve their L[1/3, 1.44] to L[1/3, 1.232] by using smarter early-abort strategies, but was not the first to come up with 'cheap' individual logs.
Minimum 2048 bits, please note. 1024 is not safe - and has not been for quite some time. GCHQ and NSA can definitely eat 1024-bit RSA/DH for breakfast at this point (although it does still take them until lunch).
(Those of you still using DSA-1024 signing keys on your PGP keyrings should reroll RSA/RSA ones. I suggest 3072 bits to match a 128-bit workfactor given what we know, but 4096 bits is more common and harmless. 2048 bits is a bare minimum.)
Can you please explain what you mean? Do you mean "those of you still using DSA-1024 anywhere" or do you mean that there is something we should do "on the PGP keyrings" specifically? Can we control how we maintain the keyrings? Is there some setting for the "key on the keyrings"? I ask since I don't know the state of the art of the formats of the keyrings.
By "on your keyrings" I mean that quite a few PGP keys in the wild still use DSA-1024 master signing keys with (often much larger) ElGamal encryption subkeys (as DSA was not specified for a long time with keys beyond 2048-bits).
However, DSA-1024/(ElGamal-anything) is not a safe configuration anymore - an attacker who can do a discrete-log on a highly-valued 1024-bit finite field can recover the signing key, and sign things - including software released under that key, or grant themselves new encryption subkeys of any strength.
It may therefore be a good idea to review your PGP keyrings for any master keys you trust which fit that 1024-bits and below criteria (look for 1024D, or below), as they definitely are overdue an upgrade. You may find that a fruitful search, with a few surprises still. For example, to pick one high-profile signing key that would doubtless have been interesting to Nation-State Adversaries and would have been susceptible to such an attack: http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xE3BA7... ˙ ͜ʟ˙
The common safe configuration for modern OpenPGP (and upstream GnuPG's current default, I believe) is to use RSA signing keys and RSA encryption subkeys, each of at least 2048 bits - really I'd recommend 3072 or 4096 bits, as use of PGP is not as performance-sensitive as TLS and there is no forward secrecy, so I wouldn't really recommend going much below a ≈128-bit workfactor (equivalent to ≈3072 bit RSA or ≈256-bit elliptic-curve).
Edward Snowden trusted RSA-4096 signing and encryption keys with his life, and that obviously worked out fine for him at the time.
You are right, a lot of the keys I have in my public keyring are actually 1024D/<whatever>g, made many years ago. Hm.
This draft /does/ encourages use of larger keys, but also encourages the use of common parameter groups. The weakdh.org site mentions the use of common groups is a reason for this attack to be feasible. It also advises sysadmins to generate their own parameters. To me, that makes using common groups sound like a bad move.
The problem is, I lack proper knowledge to assess whether using common groups really is a bad move, even when using larger group sizes... Anyone here who can?
I don't understand why you would not believe weakdh recommendations? The researchers describe in their paper (1) exactly how they can precompute some values only once in order to then do fast attacks on any vulnerable communication. They proved that the common and too small values are both dangerous. It's real. And it's definitely not "choose the one you like." Change both.
1) https://weakdh.org/imperfect-forward-secrecy.pdf
"Precomputation took 7 days (...) after which computing individual logs took a median time of 90 seconds."
For all I know, a few extra bits parameter length can make the NFS just as infeasible as generating own parameters.
Edit: re-reading my earlier comment I understand your reply better. I've expanded my question to 'even with larger group sizes', as it indeed is clear that it is a problem with smaller groups.
The difference is many orders of magnitude, it is if everybody everywhere can be attacked anytime or just somebody sometimes somewhere.
Moreover, the main reason why it should be done is that the expected browser updates won't block the sites with 1024 bits. So all the sites which for whatever reason still use 1024 bits won't be so vulnerable if they had their own parameters.
The practice of using the common parameters already now worsens the current state. The bad effects of the really bad move already exist. The common parameters are now provably bad and it won't change in the future. Just don't use the common parameters. Generate the new ones everywhere.
And, of course, "minimum 2048 bits, please."
Edit: audi alteram... means "listen to the other side." Which side is the other side here? The stale information is not "the other side" it's just stale.
The 'other side' are the people currently working on the negotiated-ffdhe draft (which I assume are bright people too). The draft was last updated a week ago (12 May 2015), so their considerations must be quite recent.
I'm just trying to get a sense of pros and cons. Iirc, generating own groups has its problems too. For example, the Triple Handshake attack (https://www.secure-resumption.com/) could break TLS because implementations did not properly validate DH params. Allowing only some (set of) pre-defined (known good) params would have stopped that attack.
To be clear, I'm certainly not arguing for or against using common groups. Just trying to get a complete picture. (And yes, based on current information I think too that using unique groups is the right approach.)
There's very little reason in practice to bother trying to patch DHE, it's slow and old and interoperates worse (thanks Java). Chrome's just taking it out in the medium-term.
https://mailarchive.ietf.org/arch/msg/cfrg/BPDuOnVbrWiMSCjcf...
I would say use a custom group if you must stick with 1024-bit groups for some reason. Otherwise, use a vetted 2048+-bit group. If---or when---2048-bit discrete logs over a prime field are broken (and by broken I mean once, regardless of precomputation), it will likely be due to some algorithmic advance, in which case DHE is essentially done for. If nation states have been able to pull that off already, then it's pointless to even recommend anything related to DHE in the first place.
The problem with reusing them is of course when they're not strong enough, and so if an adversary can pop one, they can get a lot of traffic - and as I've said for a while and as the paper makes clear, 1024-bit and below are definitely not strong enough. Anything below 2048-bit would be a bit suspect at this point (which is precisely why the TLS Working Group rejected including any primes in the ffdhe draft smaller than that - even though a couple of people were arguing for them!).
If you're still needing to use 1024-bit DH, DSA or RSA for anything at all, and you can't use larger or switch to ECC for any reason, I feel you have a Big Problem looming you need to get to fixing. Custom DH groups will not buy you long enough time to ignore it - get a plan in place to replace it now. We thought 1024-bit was erring on the small side in the 1990s!
I concur that the NSA's attack on VPN looks like an operational finite-field DH break - I didn't realise that two-thirds of IKE out there would still negotiate Oakley 1 (768) and 2 (1024), but I suppose I didn't account for IKE hardware! Ouch!
Their attacks on TLS are, though also passive, architected far more simply and more suggestive of an RC4 break to me as there seems to be no backend HPC needed - ciphertext goes in, plaintext comes out. Both are realistic attacks, I feel, but RC4 would have been far more common in TLS at the time than 1024-bit DHE, and although 1024-bit RSA would be present many likely sites would have been using 2048-bit, so naturally they'd go for the easiest attack available. (That gives us a loose upper bound for how hard it is to break RC4: easier than this!) I also don't think the CRYPTO group at GCHQ would have described this as a "surprising […] cryptologic advance" from NSA, but just an (entirely-predictable) computational advance, and (again) lots of people in practice relying on crypto that really should have been phased out at least a decade ago. So there's probably more to come on that front.
Best current practice: Forget DHE, use ECDHE with secp256r1 instead (≈128-bit workfactor, much faster, no index calculus). You can probably do that today with just about everything (except perhaps Java). It will be faster, and safer. And, we know of nothing wrong with NIST P-256 at this point, despite its murky origins.
Looking forward, Curve25519 (≈128-bit) and Ed448-Goldilocks (≈222-bit) are, of course, even better still as the algorithms are more foolproof and they are "rigid" with no doubts about where they come from (and in Curve25519's case, it's even faster still). CFRG is working on recommending those for TLS and wider standardisation. You can use 25519 in the latest versions of OpenSSH right now, and you should if you can.
But, if you need to spend the time updating a server configuration, just switch to ECDHE instead.
Between the infrequent releases, the slavish devotion to maintaining backwards-compatibility, the sluggish release distribution, and the general conservative nature of some Java shops when it comes to upgrading, it's just not reasonable to expect the average non-java-using organisation to wait for Java before dropping broken crypto.
If you're running the latest LTS release of Ubuntu you'll get Firefox 37.0.2, released May 2015. But you'll still get Java 7, despite the fact Java 8 was released in March 2014. Giving you cutting-edge TLS1.0 and CBC ciphers [1]. And least Java 7 looks good compared to Java 6 [2] which has no SNI support, a stack of weak ciphers, and only supports the most obscure ciphers. And I know some people who are still running Java 6 in production systems.
If you wait for every last Java 6 holdout before deploying a secure configuration, you'll be waiting forever. Leave us behind, we'll only slow you down [3].
[1] https://www.ssllabs.com/ssltest/viewClient.html?name=Java&ve... [2] https://www.ssllabs.com/ssltest/viewClient.html?name=Java&ve... [3] http://tvtropes.org/pmwiki/pmwiki.php/Main/IWillOnlySlowYouD...
Java 8 is the first to allow above 1024-bit Diffie-Hellman parameter values.
I'm grateful to people who disclose and fix vulnerabilities instead of leaving everyone vulnerable, and kudos especially to Nadia Heninger from this team, whose work has only grown in interesting-ness and practical implications over the past few years.
Also, scary that SSH appears to be partially affected(?)
Because all the countries still can't get along with each other, and thus export restrictions still exist.
http://en.wikipedia.org/wiki/Export_of_cryptography_from_the...
Well, yeah, that's the idea—"export-grade cryptography" essentially means means "cryptography we, as a state actor, can win against in a cyberwar."
"cryptography we, as a state actor, can win against in a cyberwar, but which ultimately will end up being exploited at home as well, since we're all using the same partially broken code base"
Yeah. Is it sufficient to set ServerKeyBits to 2048?
What they are refering to is the Key Exchange method named "diffie-hellman-group1-sha1" which uses a 1024-bit DH group. You can disable this with use of the KexAlgorithms parameter. Starting with OpenSSH 6.6 it is already disabled on the server side, but still allowed with the client. There are severe interoperability problems with embedded devices if disabled.
Be careful: not all clients support the newest algorithms. Example: Ubuntu 12.04 ssh client doesn't support curve25519-sha256@libssh.org (I'm still googling how to upgrade to the latest openssh, anybody has the answer?)
In general, check that you are still able to connect to your server before closing your last ssh connection to it.
> Generate a Strong, Unique Diffie Hellman Group. A few fixed groups are used by millions of servers, which makes them an optimal target for precomputation, and potential eavesdropping. Administrators should generate unique, 2048-bit or stronger Diffie-Hellman groups using "safe" primes for each website or server.
Is this why with the easy-rsa package (https://github.com/OpenVPN/easy-rsa) one should always build a dh pair first? People are using pre-seeded ones when they do not use this tool first!? That is scary.
https://stribika.github.io/2015/01/04/secure-secure-shell.ht...
In my mind, more generally: EC attempts to make crypto algos stretch using fewer bits but implementations are harder to prove both theoretically (by being more esoteric, therefore fewer eyeballs are able to catch errors) and functionally correct (by having more moving parts). Why haven't more conservative stretching / extension of proven algos happened?
Also, even more broadly, this and at lot of other crypto decisions in TLS come off as seat-of-the-pants, guesswork, cooking by committee rather than simple, feature-minimal and bullet-resistant standards (how many way over-engineered and over-featured encodings do certs need?). The result smells like a pile of poo that will get recall after recall, patch after patch until something about the inputs and decision-making process changes. We can't keep having OpenSSL and the TLS committee saying "yes" instead of "no" to (feature creep) throwing every little edge use-case live into production 1.x branch, the codebase is huge enough, and it's nearly impossible to compile out all the little used crap, even in forks. Doing the same thing and expecting a different result is either stupid or insane, or both. OpenSSL and TLS leadership, process changes perhaps?
Also, its nice and dandy to have postfix use SSL but SMTP TLS is always set to opportunistic and can be degraded to no encryption by a MITM - because, you know, compatibility.
Setting up DNSSEC is another kettle of fish, mind.
Or is this just not really a browser issue, and held back on the browser side because blocking insecure ciphers breaks most of the internet?
Presumably because the main danger here comes from state-level adversaries who already know and actively exploit the issue, not script kiddies who might get funny ideas after reading the announcement. So the sooner it is published and people can start fixing their servers and clients, the less damage is done.
I finally found the Mozilla bug entry for this, they've known of it since 2010 when they raised the minimums to 512-bit DH groups.
nginx -t will quickly tell you if you've screwed something up before actually trying to apply changes.
To answer your question more directly, the DHE does use a different form of key establishment which uses different algorithms, different parameters, and potentially different parameter sizes. The forward secrecy is a desirable property in itself, but under some circumstances implementations might use weaker cryptographic parameters in conjunction with it.
(Daniel Kahn Gillmor first told me about this problem; in TLS_DHE_RSA the RSA key is used for authentication of the DH key establishment -- to stop someone from doing an active MITM attack -- but not for the key establishment itself. In TLS_RSA the RSA key is used directly for key establishment. Thus when you use TLS_DHE_RSA, your security levels may be limited by the weakest link mechanism that you rely on for security, which could conceivably be the DH exchange, depending on other features of your configuration and environment. A number of folks have been aware of that particular problem to some extent for a while and even discussed it at, for instance, the IETF TLS working group, but this paper takes things considerably further and makes the problems really concrete.)
Edit: upthread you can find a link to pbsd and AlyssaRowan discussing forms of the problem half a year ago, including the fact that you can get less security from weak DH parameters than you would have gotten from strong RSA parameters, despite the presence of forward secrecy. In some settings there cost trade-offs are possible for attackers between breaking particular sessions vs. breaking all traffic to a particular service.
With DHE, the Diffie-Helman exponent math is what establishes the shared secret, and if the DH prime is broken, then the shared secret can be derived by a MITM. The public DH parameters are sent in the plain, so a MITM can just observe them. A hash of those parameters is signed using RSA, so they can't be changed, but that's not important to defeating forward secrecy.
So if if the RSA key is bigger than ~1024 bits, then TLS_DHE_RSA_WITH_AES_256_CBC_SHA is likely weaker.
[1] There is some further derivation done to get the actually session key, but that's not relevant here.
1. Select your load balancer (EC2 - > Load Balancers). 2. In the Listeners tab, click "Change" in the Cipher column. 3. Ensure that the radio button for "Predefined Security Policy" is selected 4. In the dropdown, select the "ELBSecurityPolicy-2015-05" policy. 5. Click "Save" to apply the settings to the listener. 6. Repeat these steps for each listener that is using HTTPS or SSL for each load balancer.
The `openssl ciphers -v CIPHERSPEC` command will list out what's enabled with a given setting.
I hope this is the last nail in the coffin to see the last of it disabled in the wild, you would have thought FREAK would have done the job.
2. ECDHE is totally different to traditional finite-field DHE. ECDHE over P-256 (or better curves) is not vulnerable to this attack.
(I'm agreeing with your point.)
There is, as I understand it, a huge performance penalty for using keys larger than 2048 bits. People should just use 2048 bit keys, or stop using conventional prime field public key algorithms altogether, is what I think.
I don't think the NSA can do this on demand.
> People should just use 2048 bit keys, or stop using conventional prime field public key algorithms altogether, is what I think.
I believe moving towards ECC (especially djb's work) is probably the right move.
We can't do the former thing at all for 2048 bit DH/RSA, let alone the latter.
Entities attacking 1024 bit keys are doing something we've believed would be inevitable for something like a decade.
When 2048 bit DH/RSA falls, DH and RSA will probably fall with them; they won't fall because compute resources eventually catch up to them, but rather because we discover something about integer factorization or discrete logs that makes prime field cryptography altogether unsafe.
512, which they actually did, is 10.2 core-years for the precomputation plus 10 core-minutes per actual crack. 768 they estimate at 29,300 core-years plus 2 core-days per crack. 1024 is estimated at 45M core-years plus 30 core-days per crack. On top of that while 10M of those core-years are easily parallelizable with specialized hardware (the sieving stages) 35M of them are spent doing linear algebra on a square matrix with 5 billion rows. The authors of the paper note that there's been little work on designing custom systems suitable for this task and only give a rough estimate of the resulting cost (somewhere in the order of hundreds of millions of dollars).
As you can see the challenges presented (hence cost) doesn't scale linearly with problem difficulty. The linear algebra step looks completely implausible at 2048.
http://bindshell.nl/pub/zines/OandE/exp03.txt
(Ctrl+F: Vpn24.org)
We need a new web.
So I suppose he does mean like that.
when TLS was committed to openSSL, the code used the vars 'payload' for []byte... not 'msg' or 'data'....
i wrote about it and some other facts and was downvoted to oblivion
another guy from the w3c team wrote an article "TLS is not HTTPS" but they are selling it as HTTPS, same name logo icon etc, and shipping it to the whole world, his post was removed also..
were heading towards a global root.
found the article: http://www.w3.org/DesignIssues/Security-NotTheS.html
my take on the situation: http://8ch.net/g/res/2200.html#2363
they were beginner crypto mistakes like reusing nonce/null nonce...
and the new logjam bug
keep downvoting guys the government needs you!