51–60 of 103 posts
Chrome will be increasing it's minimum DH group size to 1024 bits: https://groups.google.com/a/chromium.org/forum/#!topic/secur... But, if you need to spend the time updating a server configuration, just switch to ECDHE instead.
I suggest a 768 bit minimum for now, because of Java. As a side note, the latest IcedTea 6/7 release allow 1024-bit DHE but it is not enabled by default.
Earlier quoted context omitted.
Looks like it's not enough just to set a proper ciphersuite, it's also important to reconfigure the dhparams (which apparently isn't even possible in most common apache versions). Interestingly, Dovecot seems to have had the foresight to automatically regenerate dhparams weekly by default.
You mean like https://wiki.mozilla.org/Security/Server_Side_TLS#DHE_handsh... ?
So I suppose he does mean like that.
From the TLS sysadmin deployment guide( https://weakdh.org/sysadmin.html ): > 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-rs…
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?
Earlier quoted context omitted.
It's not particularly surprising to the IETF TLS Working Group either, which is at least partially why https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe... exists. 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-10…
> It's not particularly surprising to the IETF TLS Working Group either, which is at least partially why https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe... . exists. 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…
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.
I'm using Version 42.0.2311.152 (64-bit) Chrome, so far it's still vulnerable to this. I believe it's the latest production version.
Firefox Developer Edition, which is on 40.0, is also reported as vulnerable.
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?
nginx -t will quickly tell you if you've screwed something up before actually trying to apply changes.
So the NSA can break 1024-bit DHE? Is ECDHE good enough to hold us for now, or do we need to find an alternative to DHE ASAP?
2. ECDHE is totally different to traditional finite-field DHE. ECDHE over P-256 (or better curves) is not vulnerable to this attack.
So the NSA can break 1024-bit DHE? Is ECDHE good enough to hold us for now, or do we need to find an alternative to DHE ASAP?
So the NSA can break 1024-bit DHE? Is ECDHE good enough to hold us for now, or do we need to find an alternative to DHE ASAP?
Two parts to your question: 1. Yes, the NSA can likely break 1024-bit DHE at scale - as well as 1024-bit RSA or anything smaller. (Probably also the RC4 stream cipher, if you didn't listen and are still using that.) 2. ECDHE is totally different to traditional finite-field DHE. ECDHE over P-256 (or better curves) is not vulnerable to this attack.