Comment by AlyssaRowan
11 years ago
Regarding your first paragraph, I agree: all CAs need continuing scrutiny. Certificate Transparency, for example.
Regarding the rest of your post, however, I'm calling bullshit. You give very bad advice. Deploy TLS on every website. Deploy HTTP Strict-Transport-Security wherever you can.
The sites people visit are confidential, and yes, are not protected enough at the moment. (That will eventually improve, piece by piece.) That's absolutely no excuse at all for you not protecting data about the pages they're on or the specific things they're looking at, even if your site is static, or not protecting the integrity of your site. You have no excuse for that. Go do it.
Your other big problem is thinking that anything on your domain "doesn't need security"! Yes it does - unless you actually desire your website to be co-opted for use in malware planting by Nation-State Adversaries with access to Hacking Team(s) (~cough~) - or the insecure parts of your website being injected by a middleman with malicious JavaScript or someone else's "secure" login page that's http: with a lock favicon. (I have seen this in the wild, yes.) If you've deployed a site with that bad advice, it could be exploited like that today: go back and encrypt it properly before someone hacks your customers. This is why HSTS exists. Use it.
Regarding your CDN point, kindly cite - or demonstrate - your working "known attack" against Cloudflare's deployment?
kindly cite
Black Hat 2009, "Why TLS Keeps Failing to Protect", Moxy Marlinspike, slide 42: https://www.blackhat.com/docs/us-14/materials/us-14-Delignat...
Basic concept: 1) find target site A with shared SSL cert. Cloudflare gets shared SSL certs with 50+ unrelated domains. 2) find vulnerable server B in a domain on same cert. (Probably Wordpress.) 3) attack server B, inserting fake copy of important pages on site A with attack on client or password/credit card interception. 4) use DNS poisoning attack to redirect A to B.
All it takes is one vulnerable site out of the 50+ on the same cert.
The whole shared-cert thing is a workaround for Windows XP. Cloudflare does it because they're still trying to support IE6 on Windows XP, which doesn't speak Server Name Identification, and they don't have enough IPv4 addresses to have one per customer.
Wrong.
5) Cloudflare's sni??????.cloudflaressl.com presents an error to you because the Host: header is either missing, doesn't match the SNI, or otherwise, serves the correct site to you instead of your phishing page.
You obviously haven't tested this. And it's Moxie.
Vhost-confusion is a relevant attack on TLS with non-HTTP protocols, HTTP/0.9 and sites which serve a default domain to clients with no Host: headers. Cloudflare quite specifically does none of these, and is not vulnerable in its deployment - it needs the Host: header to know which site you want it to select with its reverse-proxy, and you can't poison that because it's protected by TLS to Cloudflare.
Also you, the attacker, don't have the cert.
If you can DNS poison away from Cloudflare, please report it to their security team, but you'll find they're looking at deploying DNSSEC soon.