Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Logjam TLS attack

weakdh.org

Post reply on HN
Print view View original

41–50 of 103 posts

Re: Logjam TLS attack

#41

Post by michaelt »

yuhong wrote: post #22
agl wrote: post #3

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.

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

Re: Logjam TLS attack

#42

Post by acqq »

syzzer wrote: post #40
acqq wrote: post #39

Earlier quoted context omitted.

Obviously weakdh has more up-to-date recommendations (public only a few hours!) so you should certainly not cling to the older ones published by IETF who-knows-when and which could have been influenced by the players who prefer the weaker encryption for their own benefit. I don't understand why you would not believe weakdh recommendations? The researchers describe in their paper (1) exactly how they can precompute so…

I strongly believe in 'Audi alteram partem', and like to understand rather than believe. Hence my question. 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 newly disclosed research clearly demonstrates that the common parameters enable "precompute just once, attack fast everywhere" whereas when everybody simply generates their own values that approach becomes impossible. The difference is between the days of computation versus the seconds in their example.

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.

Re: Logjam TLS attack

#46

Post by wtracz »

yuhong wrote: post #22
agl wrote: post #3

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.

This was fun to find at the end of two days last week when a third-party system was trying to connect via SSL.

Java 8 is the first to allow above 1024-bit Diffie-Hellman parameter values.

Re: Logjam TLS attack

#47

Post by wolf550e »

So a secure TLS client must refuse to negotiate DHE if the server uses one of the common DHE param values, like in case a Debian no-entropy private key used in the cert?

Re: Logjam TLS attack

#48

Post by mc_hammer »

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.

found the article: http://www.w3.org/DesignIssues/Security-NotTheS.html

my take on the situation: http://8ch.net/g/res/2200.html#2363

Re: Logjam TLS attack

#49

Post by syzzer »

acqq wrote: post #42
syzzer wrote: post #40

Earlier quoted context omitted.

I strongly believe in 'Audi alteram partem', and like to understand rather than believe. Hence my question. 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 newly disclosed research clearly demonstrates that the common parameters enable "precompute just once, attack fast everywhere" whereas when everybody simply generates their own values that approach becomes impossible. The difference is between the days of computation versus the seconds in their example. The difference is many orders of magnitude, it is if everybody everywhere can be attacked anytime or just someb…

Thanks for elaborating.

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.)

Re: Logjam TLS attack

#50

Post by ZoFreX »

mdewinter wrote: post #29

My side project tries to give secure default settings for all major webservers and other software (like haproxy, mysql, mailservers etc): https://cipherli.st/ 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…

Thanks to your guide, I didn't have to change a single thing when this news broke. Excellent work!
Post reply on HN