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

91–100 of 103 posts

Re: Logjam TLS attack

#91

Post by yuhong »

talideon wrote: post #69
zobzu wrote: post #16

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.

DANE can at least partly mitigate this, though that assumes that you've DNSSEC set up, along with TLSA records for your mailservers. Setting up DNSSEC is another kettle of fish, mind.

Yea, DNSSEC has its own problems. Personally I think a version of HSTS for mail is the best idea for now.

Re: Logjam TLS attack

#92

Post by aidenn0 »

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 a bunch, it's fairly easy to find configs for HTTP servers (and SSL labs won't check non 443 ports), but I also run a dovecot server, and this made it easy to check; I had no clue SSLv3 was enabled by default, for example.

Sadly my current phone is stuck on SSLv3 so until I replace it I have no mail on my phone anymore.

Re: Logjam TLS attack

#93

Post by samch »

michaelt wrote: post #41
yuhong wrote: post #22

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…

What people are really saying here is that the native APIs provided the standard Java packages are behind. Java, as a platform, has no inherent limitations like this. Feel free to check out the excellent work of the team a Bouncy Castle [1]. They offer full ECDHE support in a really well maintained library. Sure, Oracle should build this in natively (and I admit that it does look bad when you see it on SSL Labs), but there are other options.

[1] https://www.bouncycastle.org

Re: Logjam TLS attack

#94

Post by acqq »

AlyssaRowan wrote: post #89
acqq wrote: post #34

Earlier quoted context omitted.

> Those of you still using DSA-1024 signing keys on your PGP keyrings should reroll RSA/RSA ones. 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…

I mean use of RSA-1024 or DSA-1024 anywhere, for any purpose, is really too small for safe use now. 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…

Thanks a lot for taking the time to answer.

You are right, a lot of the keys I have in my public keyring are actually 1024D/g, made many years ago. Hm.

Re: Logjam TLS attack

#95

Post by elchief »

0x0 wrote: post #9
jvehent wrote: post #2

Use a proper ciphersuite and stop worrying about downgrade attacks. https://wiki.mozilla.org/Security/Server_Side_TLS

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.

"The recommendations in this guide provide configurations that are not impacted by this."

Re: Logjam TLS attack

#96

Post by dolfje »

So for a full test, I would recommend https://tls.so/ or https://www.ssllabs.com/ssltest/. But if you just want to check if your server has the logjam vulnerability, I would suggest http://security.uwsoftware.be/logjam. It just says No, Yes or Yes by the NSA (for 1024 DH keys). A little bit humour inside a scanner.

Re: Logjam TLS attack

#97

Post by derefr »

darklajid wrote: post #36
derefr wrote: post #18

Earlier quoted context omitted.

> Shipping breakable encryption sounds worse than shipping none at all. Well, yeah, that's the idea—"export-grade cryptography" essentially means means "cryptography we, as a state actor, can win against in a cyberwar."

But the GP's point seems to be that this seems to turn into "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"

Indeed; maybe it would be better named "export-only cryptography"—not for domestic use by order of COMSEC.

Re: Logjam TLS attack

#98

Post by samch »

wtracz wrote: post #46
yuhong wrote: post #22

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.

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.

Java 8 was the first version to do so natively, but out of curiosity what was stopping you from using a library (like Bouncy Castle) to handle encryption in earlier versions of Java?

Re: Logjam TLS attack

#99

Post by zowers »

edgan wrote: post #82

Looks like Amazon's EC2 ELBs have a common 1024 DH. I don't see a way to fix it without moving away from ELBs, or getting Amazon to fix it.

https://forums.aws.amazon.com/ann.jspa?annID=3061 > Today, Elastic Load Balancing released a new default SSL Security Policy that no longer includes Ephemeral Diffie-Hellman (DHE) ciphersuites. ELB offers predefined SSL Security Policies to simplify the configuration of your load balancer by providing a recommended cipher suite that adheres to AWS security best practices.

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.

Re: Logjam TLS attack

#100

Post by bradleyjg »

sarciszewski wrote: post #81
tptacek wrote: post #79

Earlier quoted context omitted.

Attacks don't really scale like that. If 2048 bit prime field discrete logs fail, all of prime field discrete logs (and with it probably RSA) will probably be done for. 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.

Well, if they could crack 1024-bit primes in under a day, how long would you anticipate 2048-bit would last? That's why I said eye it suspiciously. 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.

If you look at the chart on the top of page 8 of the technical paper (https://weakdh.org/imperfect-forward-secrecy.pdf), they have some intelligent guesses for core-years to crack a DH-512, 768, and 1024 group, as well as associated memory requirements.

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.

Post reply on HN