Logjam: the latest TLS vulnerability explained | Hacker News Reader

Logjam: the latest TLS vulnerability explained

blog.cloudflare.com

92 pointsjgrahamc29 comments

A bit off topic, but I find it quite disheartening that cloudflare has regular blog posts about how great their security is and how safe you are with cloudflare, but at the same time offers customers seriously broken SSL options.

2 of the 3 options ("Universal SSL" and "Full SSL") are not "secure" by today's standards. Universal SSL leaves connections to the origin unsecured allowing for passive and active MITM attackers to intercept things. Full SSL allows an active MITM to intercept origin connections.

Advertising these services as "SSL" is misleading and offers a false sense of security to visitors as they will see the nice green SSL lock and think their connection to a cloudflare-protected website is fully protected. Meanwhile their credit card information and other personal details could be travelling over the internet in plain text to the origin.

Yes. I have said it before and I say it again: Cloudflare (and any other large CDNs) are a perfect setup for a MITM or a perfect target for a nation-state's secret service.

Especially when cloudflare is governed by the laws of the US which includes the patriot act. How do we know this isn't already the case?

If your threat model includes intelligence agencies, set up your own HTTPS with HSTS and HPKP and don't use CloudFlare.

Wow, that was easy.

So, basically anyone providing online services to customers then? Who's threat model should not include intelligence agencies? Online pet shop?

It comes down to personal opinion more than anything.

Universal SSL does not imply "origin unsecured": https://blog.cloudflare.com/universal-ssl-encryption-all-the...

It seems I meant "Flexible SSL" instead of "Universal SSL". According to the main website, flexible SSL is not secured. https://www.cloudflare.com/ssl

The beta test of a Cloudflare CA for "Full SSL" is a big improvement over accepting any self-signed certificate, but I still think "Flexible SSL" should not be a thing.

It misleads users, for a start.

I get the business case (the whole point is that SSL is hard for a large class of server admins). Also it does help for e.g. users coming in via tor or un-trusted networks.

But dammit, I still can't bring myself to like it.

Not to mention their disgraceful Tor captchas.

Why do you think they have implemented these? Just to inconvenience you?

(Another Tor browser user here.) Yes, it sure seems so. Half the time I visit Hacker News (which is behind Cloudflare) I have to fill in a captcha. I'm logged in with a 3k rep account and I'm not trying to do any action, I'm just trying to see the front page. That is surely suspicious enough to give me a captcha every ten minutes.

Edit: to respond to both comments at once: alright Cloudflare may not recognize my HN cookie and account, but they do have two cf_* cookies, and I am merely loading the homepage. No weird URL parameters, no POST data, nothing.

Are you suggesting cloudflare should hook into HN to check your reputation, I'm not sure they have the engineering capacity to extend this to all sites.

To be fair, Cloudflare has no concept of how much reputation you have on HN.

Dude, you're assuming that from that same exact IP address they aren't getting a ton of other traffic that isn't spamming the hell out of them or doing completely sketchy stuff. That's what happens when you share an IP address with other people -- especially those who might be criminals or have other nefarious motives for using tor.

And that's why IP banning is a silly thing in IPv4. In Italy there is CGNAT widely deployed for years and Asian ISPs have big trouble obtaining IPv4 addresses as well.

Dude.

They're the only major internet provider I know that consistently has difficulty providing adequate service to Tor browser users in the common case.

They've even acknowledged that they're doing an unsatisfactory job of it, but still haven't gotten around to improving their system in several months.

It's a hard problem. The challenge is the vast majority of the traffic we see across Tor is malicious. I don't mean malicious in a normative/political sense (e.g., visiting a controversial site) I mean it in the sense that it is trying to harm the visited site (e.g., spam, SQL injection, etc.). Our customers sign up for us to protect them from these malicious visitors. Tor makes users individually anonymous -- which I think is extremely important for the health of the Internet -- but the challenge is that then means we have to fall back on less granular data when assessing a visitor's reputation (e.g., an IP address). CAPTCHAs are an imperfect way of differentiating malicious and non-malicious users both coming from a space where we see a majority of attempted harmful requests. Agree it's not perfect, but we haven't yet come up with a way to respect anonymity, protect our customers from attacks, and not introduce some additional annoyance/friction to good users on shared networks with a large amount of malicious traffic like Tor.

To be clear, we don't disfavor (or favor) Tor exit nodes. The reputation of their IPs is generated automatically, just like the reputation of a company's VPN or your home router. People have suggested we provide our customers a way to whitelist all of Tor's nodes. We could do that, but I worry it may have the opposite of the intended effect. The vast majority of our customers, if given the ability to apply a rule to the Tor network, would choose to blacklist it entirely. While not the HN crowd, most site owners see Tor as a source of their headaches (e.g., credit card fraud, spam, trolling, hacking attempts, etc.). I'm not sure how we can build a system to allow customers to identify a set of IPs to whitelist without also allowing them to blacklist those IPs. I've been the voice internally who has resisted providing a selector on Tor but, maybe counter intuitively, because I am worried about not further harming the network's ability to allow users to surf the network anonymously.

All that said, I agree right now our solution is far from perfect. I believe long term we'll always add a bit of friction to anonymous, shared networks but I think we can make it less painful/annoying. A number of very high profile individuals ranging from human rights activists to ACLU attorneys to even Edward Snowden and Julian Assange have personally asked me to, please!, make it better. A significant portion of our team is working to improve the experience for legitimate anonymized visitors without putting our customers at more risk. We've gotten incrementally better, but we're far from perfect. If you have ideas on how we can be better while still offering the protection our customers hire us for, send them our way or, better yet, come work with us. This is a hard engineering and Internet policy problem that there isn't a silver bullet solution for but that making progress on will have an enormously positive impact to millions of Internet users globally.

Thanks for replying to this, it's good to see you recognize this as an issue.

Some thoughts based off this:

It's clear that these captchas are 95% broken, the fact that these ones are so unreadable suggests the more readable ones were solved, so apparently this implementation can't last in any case.

For what it's worth I would have no problem filling out captchas if they're readable, and other places on the internet do still have readable captchas.

Another reading here is that Cloudflare has sold a product to its customers (hacking protection) that other cloud providers have not attempted to sell. I'm going to be harsh and call that negative externalities for Tor users.

And I'm not sure that product even works as advertised - a scan of the internet can reveal the backend server, which could still be hacked (probably even more so, if the customer is now relying on Cloudflare to protect it).

It seems we're talking about automated attacks only? Else the attacker could just fill out the captcha manually first.

If a targeted attack can be detected (attacker has completed the captcha), just rely on that code instead? If not, have we gained much?

Clearly a lot of customers will have blindly cranked their s3cur1ty bar to 11. Perhaps make it harder for a customer to do that, given the adverse impact it currently causes? Most people probably think DoS when they head to Cloudflare, not free captchas.

Note that I do mean "common case", because its weakens the anonymity set when normal people are hassled out of Tor. So just making "GET /boring-article.html$" work would be a great improvement. If that then lead to a work-flow of "POST /comment" -> 403, user notices, hits refresh and fills out a magically-appeared captcha, then so be it.. Tor users would learn this flow quick enough, and prefer it.

I could totally ask and suggest ideas about this all day for free, but I won't be applying to Cloudflare for the time being fwiw :P Still, I'm grateful you're working on the issue.

I can record a screencast in which I enter the right CAPTCHA and CloudFare still refuses to let me in, repeatedly, when I am using the Tor Browser. This happens to a point that I just give up because life is too short to enter right CAPTCHAs and still see CloudFlare complain.

Supposedly they're working on that: https://www.youtube.com/watch?v=QdVL54l-VWY#t=25m11

Like reported earlier it is quite easy to test if your server is (still) affected. I used http://security.uwsoftware.be/logjam since it didn't had a cache on it. That makes it possible to fix and confirm fixed. (IIUC most other tools had a cache. So when testing after fixing it was just showing that it was still vulnerable).

I wish there were more diagrams (like the one in this article) that explains how specific HTTPS ciphersuites work and how all keys are derived and agreed upon, and not just the initial TLS handshake. I would like to learn why I need to generate an RSA key for my server when it's just using AES in the end. I want to know the steps in the black magic involved in going from an asymmetric cipher to a symmetric one.

(Author here.) Beautiful! I'm about to start a strictly technical podcast about cryptography and attacks, and I was planning to do the first episode on all the TLS Key Exchanges. I'm super-happy to see that there might be interest on this in particular :)

Keep an eye on blog.filippo.io maybe, then!

Well, you've piqued my interest! :D

But the black magic lies exactly in the handshake. You need to generate the RSA key (or more broadly, an asymmetric key) in order for the handshake to take place.

An analogy I like to use are boxes with locks. Imagine that, given a lock design, I can produce a bunch of boxes with the exact copies of the lock and keys for the lock. Symmetric crypto corresponds to everyday locks: if you have the key for the lock, you can open or close the lock as you wish. Asymmetric crypto corresponds to a special kind of lock, which comes with two keys: one kind for locking the lock (the public keys), another for unlocking (the private keys).

Now if somebody wants to communicate with me securely, the choice of lock affects the key distribution significantly. If I have just symmetric locks, for each person I want to talk to, I have to create a new box with a separate lock, and make sure they are the only ones having a key for this lock. The latter I have to in person. Meaning, if I want to talk to somebody on the Internet, I first have to meet them in person (that is, out of band), before we can communicate securely. This doesn't scale well. With asymmetric crypto, however, I can just leave a bunch of open boxes and corresponding locking (public) keys lying around (the keys for the different boxes can be same or different, doesn't matter). If Assange now wants to send me a message, he writes it on a piece of paper, puts it in one of the open boxes, and locks it with the locking key. I'm the only person with the unlocking (private) key for this lock so I'm the only one who can read the message. This is just basic asymmetric crypto.

Another thing Assange could do is, instead of leaving a piece of paper with the message, to leave a piece of paper with a fresh design of a symmetric lock. Now I can safely create my own symmetric box according to the design, put messages inside, lock them and leave them around for Assange to pick up. This is secure since he's created the design and he's the only one apart from me who can open such boxes.

This is a 10,000 foot view of how to do the switch from asymmetric to symmetric crypto, but there are many other questions that need to be addressed to get an actual protocol. Thes include "how does Assange know this public key belongs to me" (answer: certificates and certificate authorities), "how do I know the message came from Assange" (answer: digital signatures), "what purpose does this message serve" (tagging and nonces), "what kind of designs I can produce locks for" (ciphersuite negotiation) and so on. Additionally, there's all kinds of things that can go wrong when implementing this - basically, even though we know how to check the security of a high-level design of a protocol using formal methods (the so-called "symbolic verification" tools), we don't really have a systematic way of translating these designs into actual implementations while preserving the security guarantees.

Also, there are direct key-exchange protocols (such as Diffie-Hellman) which work differently than the basic idea above.

Great article! And shameless plug, my take on the attack which I think complement this article well: http://cryptologie.net/article/270/the-logjam-attack/

Loved cloudflare idea and used them for several websites driving > 2M views per day, and it's great to see them post things about security, but from my experiences/benchmarks:

    * Inject JS via html packets rewriting
    * High numbers of false positives even on lowest threshold
    * Issues with flash resources for some users
    * Odd price structure (Based on number of domains not traffic)
    * Adsense on error/not-a-bot pages

Nice logo.

Reply on news.ycombinator.com