I see this as security theater. Most web pages don't need to be encrypted. Anything with a form should be, but if you're just viewing static content, there's little point. Yes, it obscures what content you're viewing, slightly. An observer often could figure that out from the file length.
Encrypting everything increases the demand for low-rent SSL certs. Anything below OV (Organization Validated) is junk, and if money is involved, an EV (Extended Validation) cert should be used. Trying to encrypt everything leads to messes such as Cloudflare's MITM certs which name hundreds of unrelated domains. This is a step backwards.
> Most web pages don't need to be encrypted. Anything with a form should be, but if you're just viewing static content, there's little point.
Some really cool HTML and JS functionality will only work over HTTPS.
> Yes, it obscures what content you're viewing, slightly. An observer often could figure that out from the file length.
If you have an attacker than can identify content solely from its length, you have bigger problems than an SSL cert can solve.
> Trying to encrypt everything leads to messes such as Cloudflare's MITM certs which name hundreds of unrelated domains. This is a step backwards.
I do not see the problem. All those domain owners consciously choose to have Cloudflare host their stuff. The cert might be a few KB bigger, but who cares?
> Most web pages don't need to be encrypted. Anything with a form should be, but if you're just viewing static content, there's little point.
Some really cool HTML and JS functionality will only work over HTTPS.
What "really cool" HTML feature requires HTTPS? There can be problems with mixed secure/insecure content, but that's more of an offsite content issue.
> Yes, it obscures what content you're viewing, slightly. An observer often could figure that out from the file length.
If you have an attacker than can identify content solely from its length, you have bigger problems than an SSL cert can solve.
An eavesdropper knows the IP address and the length of the content, even if it's encrypted.
> Trying to encrypt everything leads to messes such as Cloudflare's MITM certs which name hundreds of unrelated domains. This is a step backwards.
I do not see the problem. All those domain owners consciously choose to have Cloudflare host their stuff. The cert might be a few KB bigger, but who cares?
When sites share an SSL cert, and you can break into one of the sharing sites, there's a way to impersonate others. Cloudflare customers for their lower tiers of "security" often don't realize this. The customer doesn't pick which sites share certs; that's up to Cloudflare.[1]
> What "really cool" HTML feature requires HTTPS? There can be problems with mixed secure/insecure content, but that's more of an offsite content issue.
One example would be the the Geolocation API, with more to come[1]. Another example (specifically for HTML) would be Mozilla showing a user-visible warning when it encounters a type="password" field in a form served via HTTP (or with a HTTP target - I'm not certain). This is currently only enabled in the Developer Edition, but will eventually land in stable.
> When sites share an SSL cert, and you can break into one of the sharing sites, there's a way to impersonate others. Cloudflare customers for their lower tiers of "security" often don't realize this. The customer doesn't pick which sites share certs; that's up to Cloudflare.
This is a non-issue for services such as CloudFlare. Site owners do not have access to the private key, only CloudFlare does. Breaking into one of the other sites won't give you access to the private key, only breaking into CloudFlare would, and such a vulnerability would have nothing to do with the fact that you're sharing a SAN certificate with other sites. I'm not aware of any other cross-site vulnerabilities that stem from shared certificates in an environment where every site on that certificate is served by the same frontend.
"One example would be the the Geolocation API, with more to come[1]."
Ugh. Why would they do that ?
I can understand that geolocation could be tremendously sensitive and you absolutely would want to offer the option of SSL ... but why limit it to SSL ?
geolocation is also something that you'd want to hack into and build into things ... and maybe even things with limited processing power and memory.
Wouldn't it be nice to have the option to interact with a geolocation API (over http) with stdio and not include a giant truckload of dependencies and libraries and megabytes of packages ?
> I can understand that geolocation could be tremendously sensitive and you absolutely would want to offer the option of SSL ... but why limit it to SSL ?
I think you answered your own question. ;-)
> geolocation is also something that you'd want to hack into and build into things ... and maybe even things with limited processing power and memory.
Presumably, once your device is capable of running a modern browser such as Chrome or Firefox (which is what we're talking about here), TLS is a drop in the bucket in terms of resource usage. Or were you talking about the server?
Have you ever built toolchains on top of parsing web resources with unix primitives ?
Adding SSL makes it a lot more complex and limits your toolset dramatically.
If your source is sensitive, by all means - use SSL. I don't think anyone would argue with that.
But if you provide a useful resource that isn't sensitive or controversial (say, for instance, the weather) why would you want to chop off so much interoperability ?
I guess if the only way you've every used the web is with a web browser, this doesn't make any sense to you.
This has nothing to do with complexity or tooling.
Many people, including you, forget that TLS protects content from tampering. ISPs, captive portals, and other network entities are known for injecting ads or intercepting transmissions. Imagine your liability if a bad actor is injecting child porn on your site to a large portion of your audience. This isn't unheard of, by the way. Arguably less criminal, even Comcast is known for injecting content into pages.[1]
mholt is the lead developer of Caddy[1], so it's probably safe to assume that he knows a bit about this.
The goal behind the HTTPS everywhere effort isn't just to encrypt private data, but also to provide authentication for your content. ISPs are known to interfere with HTTP requests, injecting ads, malware and what not. That's something that affects anyone, even static sites.
Encrypting everything increases the demand for low-rent SSL certs. Anything below OV (Organization Validated) is junk, and if money is involved, an EV (Extended Validation) cert should be used. Trying to encrypt everything leads to messes such as Cloudflare's MITM certs which name hundreds of unrelated domains. This is a step backwards.