61–70 of 103 posts
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.
Earlier quoted context omitted.
Firefox Developer Edition, which is on 40.0, is also reported as vulnerable.
It's a bit strange this was published while the vulnerability isn't patched for the majority of users out there. Browsers vendors don't tend to lag security fixes, so why no responsible disclosure? 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.
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. 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…
Neither. ECDHE on P-256 doesn't have this problem, is available almost everywhere and is faster and safer: use that, or better still, Curve25519 and friends (in OpenSSH already, coming up in TLS later this year hopefully?). 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...
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?
What does ECDHE have to do with DHE? DHE is prime field Diffie Hellman. ECDHE is Elliptic Curve Diffie Hellman. There is no 1024-bit ECDHE.
http://bindshell.nl/pub/zines/OandE/exp03.txt
(Ctrl+F: Vpn24.org)
Earlier quoted context omitted.
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.
Depends on what we mean by "at scale", right? That's why the shared parameter aspect of this attack is so meaningful: they probably can't solve 1024 bit DH problems "on demand".
(I'm agreeing with your point.)
Earlier quoted context omitted.
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.
I say this as a Java developer who thinks Java is on the whole pretty decent: Java is way behind browser vendors when it comes to adding new ciphers and dropping broken ciphers. 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 ex…
just so you know 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. foun…
they were beginner crypto mistakes like reusing nonce/null nonce...
and the new logjam bug
keep downvoting guys the government needs you!
just so you know 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. foun…
TLS implementation has already had 2 serious show-stopping bugs if i remember. and heartbleed on top of that. they were beginner crypto mistakes like reusing nonce/null nonce... and the new logjam bug keep downvoting guys the government needs you!
This isnt exactly news but I guess a good site with a codename is needed to fix things nowadays. 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.