Comment by Animats
11 years ago
The EFF has a bad track record in this area. The last time they tried something to identify web sites, it was TRUSTe, a nonprofit set up by the EFF and headed by EFF's director. Then TRUSTe was spun off as a for-profit private company, reduced their standards, stopped publishing enforcement actions, and became a scam operation. The Federal Trade Commission just fined them: "TRUSTe Settles FTC Charges it Deceived Consumers Through Its Privacy Seal Program Company Failed to Conduct Annual Recertifications, Facilitated Misrepresentation as Non-Profit" (http://www.ftc.gov/news-events/press-releases/2014/11/truste...) So an EFF-based scheme for a new trusted nonprofit has to be viewed sceptically.
This new SSL scheme is mostly security theater. There's no particular reason to encrypt traffic to most web pages. Anyone with access to the connection can tell what site you're talking to. If it's public static content, what is SSL protecting? Unless there's a login mechanism and non-public pages, SSL isn't protecting much.
The downside of SSL everywhere is weak SSL everywhere. Cloudflare sells security theater encryption now. All their offerings involve Cloudflare acting as a man-in-the-middle, with everything decrypted at Cloudflare. (Cloudflare's CEO is fighting interception demands in court and in the press, which indicates they get such requests. Cloudflare is honest about what they're doing; the certificates they use say "Cloudflare, Inc.", so they identify themselves as a man-in-the-middle. They're not bad guys.)
If you try to encrypt everything, the high-volume cacheable stuff that doesn't need security but does need a big content delivery network (think Flickr) has to be encrypted. So the content-delivery network needs to impersonate the end site and becomes a point of attack. There are known attacks on CDNs; anybody using multi-domain SSL certs with unrelated domains (36,000 Cloudflare sites alone) is vulnerable if any site on the cert can be broken into. If the site's logins go through the same mechanism, security is weaker than if only the important pages were encrypted.
You're better off having a small secure site like "secure.example.com" for checkout and payment, preferably with an Extended Validation SSL certificate, a unique IP address, and a dedicated server. There's no reason to encrypt your public product catalog pages. Leave them on "example.com" unencrypted.
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.
>If it's public static content, what is SSL protecting?
Plenty.
Off the top of my head:
It protects people/companies from having their reputations ruined by a MITM attack that replaces content on their site with something offensive.
It protects sensitive/important content on sites from being tampered with by an attacker. For example, if I am hosting a binary for download I can make a signature available for that binary on my site. In order for the signature to serve its purpose the user needs to be sure it hasn't been modified en route.
> Anyone with access to the connection can tell what site you're talking to.
HTTPS encrypts the URL paths you access [1]. Would you rather an adversary knew which IPs you visited, or the IPs plus the URLs?
[1] http://stackoverflow.com/questions/499591/are-https-urls-enc...
> If it's public static content, what is SSL protecting?
Comcast was recently caught injecting self-promotional ads via JavaScript injection. Sites using HTTPS are immune from this sort of attack. [1]
[1] http://arstechnica.com/tech-policy/2014/09/why-comcasts-java...
TLS gives you authenticity and secrecy; those seem like useful defaults, and in 2014, I think the question should be "how?" rather than "why?" It seems this project aims to address some of the process headaches and cost barriers that currently deter some from using TLS by default.
I do think behind-the-CDN interception, in-front-of-the-CDN compromises, and weak CDN crypto are all serious concerns. I won't name any names here, but the employment histories of major CDNs' security team members definitely deserve closer scrutiny by civil society groups and reporters, especially those interested in fighting mass surveillance.
But overall, I think it's important to respect the privacy and security of users first, and work toward solving the engineering problems that need to be solved in order to affirm that commitment to users, as these folks have tried to do.
> If it's public static content, what is SSL protecting?
In this case, SSL protects against MITM attacks. If a customer goes to the unencrypted "example.com" site and gets a bunch of ads for porn, it will give the customer a negative impression of the company. All it would take is a few pitchfork-wielding high-profile twitter accounts to cause a PR nightmare. Even if the cause is a hacked coffee shop wireless access point, it may be hard to restore public opinion.
That scenario is a long-shot, but in my opinion, the potential negative consequences outweigh the time and energy required to set up SSL (especially since a basic SSL certificate is free).
> especially since a basic SSL certificate is free
From where? StartSSL only gives out free certs to individuals. For my company, they've actually required me to get organizational validation in the past, which wasn't cheap ($200, IIRC—$100 for the organizational validation, plus $100 for stage 2 personal validation, which also required me to upload images of my driver's license and passport).
That's interesting, it doesn't mention that on their website. I have only received a certificate from them as an individual, so I haven't encountered that limitation.
Even so, I'd argue that $200 is a fairly cheap way to protect the integrity of your company.
Domain validated certs for websites are free, got one a couple of weeks ago for a site.
1 reply →
> If it's public static content, what is SSL protecting?
https:// helps protect the act of participation and deters the building of dossiers.
Its the difference between the books in the library and the list of books in the library you have read.
Since SSL doesn't hide the length of the encrypted document, an attacker can make a good guess as to what public static content is being read.
Out of curiosity, does keeping connections alive help at all with this? Would an effective defense be embedding variable-length chunks of nonce in each header?
> There's no particular reason to encrypt traffic to most web pages
how about the SPDY protocol and the faster speed it offers?
> There's no reason to encrypt your public product catalog pages. Leave them on "example.com" unencrypted.
Of course this is true in theory, but in practice, both clients and customers get 'warm fuzzies' from seeing that green lock in the URL window.
It let's them 'know' that the company they are dealing with is at least somewhat reputable. Whether this is true or not doesn't matter; it is the perception many people have, and it does affect sales numbers in the real world.
i think the realpolitik/"not really caring about users" rationale is more "when someone MITMs the person browsing your company's catalog, it still makes your company look bad". and in my opinion, it should.