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

31–40 of 103 posts

Re: Logjam TLS attack

#31

Post by AlyssaRowan »

pbsd wrote: post #5

This is not at all surprising; even I had pointed out the looming DH problem in an earlier thread: https://news.ycombinator.com/item?id=8810316 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 c…

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

Re: Logjam TLS attack

#32

Post by spacefight »

" We further estimate that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime. Breaking the single, most common 1024-bit prime used by web servers would allow passive eavesdropping on connections to 18% of the Top 1 Million HTTPS domains."

We need a new web.

Re: Logjam TLS attack

#33

Post by pmontra »

whimsy wrote: post #13
0x0 wrote: post #4

Why are export grade ciphers even still a thing. I can't believe that libraries are still shipped with implementations for those. Also, scary that SSH appears to be partially affected(?)

> Also, scary that SSH appears to be partially affected(?) Yeah. Is it sufficient to set ServerKeyBits to 2048?

You might want to follow these instructions to secure your ssh server and client https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

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.

Re: Logjam TLS attack

#34

Post by acqq »

AlyssaRowan wrote: post #31
pbsd wrote: post #5

This is not at all surprising; even I had pointed out the looming DH problem in an earlier thread: https://news.ycombinator.com/item?id=8810316 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 c…

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…

> 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 art of the formats of the keyrings.

Re: Logjam TLS attack

#35

Post by 616c »

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

Re: Logjam TLS attack

#36

Post by darklajid »

derefr wrote: post #18
0x0 wrote: post #14

Earlier quoted context omitted.

Shipping breakable encryption sounds worse than shipping none at all. Especially when over and over again it becomes a source of vulnerabilities :(

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

Re: Logjam TLS attack

#37

Post by syzzer »

AlyssaRowan wrote: post #31
pbsd wrote: post #5

This is not at all surprising; even I had pointed out the looming DH problem in an earlier thread: https://news.ycombinator.com/item?id=8810316 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 c…

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

Re: Logjam TLS attack

#38

Post by sanqui »

methou wrote: post #6

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.

Re: Logjam TLS attack

#39

Post by acqq »

syzzer wrote: post #37
AlyssaRowan wrote: post #31

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…

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

Re: Logjam TLS attack

#40

Post by syzzer »

acqq wrote: post #39
syzzer wrote: post #37

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…

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.

Post reply on HN