It makes your site inaccessible to people who don't have TLS stacks. I can write and carefully audit an HTTP/1.0 client in a weekend; auditing even the bare minimum the code needed to speak TLS would take months or years.
"HTTPS Everywhere!" means "Heartbleed-like bugs everywhere".
So I should compromise my users security for the incredibly obscure use-case of people who want to browse with their own hand-made tools?
There are several readily available TLS stacks for embedded systems (CyaSSL, PolarSSL, etc.) and plenty for other platforms (Open/Libre/BoringSSL, NSS, etc.), so 'people without a working TLS stack' is not a real-world use case you need to take into account.
The argument is that someone may not be able to audit TLS stack, not that someone may not be able to use TLS stack.
Requiring TLS forces people to include TLS stack, which enlarges trusted computing base a lot. Security depends on many things, but the size of trusted computing base is an important factor.
> "HTTPS Everywhere!" means "Heartbleed-like bugs everywhere".
That's a silly argument. Here is how I will rephrase it: don't use computer because computer software always has bugs. Millions of servers run on all variants of Linux distro and every month we find a dozen of security vulnerabilities. Even standards have bugs and unresolved items.
Well, your site is inaccessible to people who don't have TCP/IP stacks too.
Try writing one of those from scratch and auditing it. (No, seriously, actually do try, break out Rust, do some proofs; more secure code would be awesome.)
> It makes your site inaccessible to people who don't have TLS stacks. I can write and carefully audit an HTTP/1.0 client in a weekend; auditing even the bare minimum the code needed to speak TLS would take months or years.
What about the HTML 5 parsing, the CSS parsing and layout, and the JavaScript virtual machine? I doubt you could write and carefully audit all that in a weekend.
Most sites are already inaccessible to people who don't have modern web browsers, which all include a TLS stack.
In addition to your point, being able to use, for example, Wireshark to debug HTTP communications is often handy. HTTPS makes that challenging.
But specifically about your point, when one audits an HTTP/1.0 client, should one also audit the TCP/IP stack in the kernel? I don't think most researchers/engineers would, and would (for sake of practicality) instead trust the underlying systems. Eventually, TLS will be thrown into that "underlying systems" bin. That time is not likely at hand; there are still too many shortcomings of TLS and its surrounding infrastructure. As evidenced at least by the OP. But when the time does come, writing an HTTPS client in a weekend will be just as practical, since you'll trust the software libraries/kernel to handle TLS. Just as you trust your libraries/kernel to handle TCP/IP today.
I'm curious, do you think that we should use secure communication only when needed and use plain http (or whatever) otherwise? Am I misunderstanding your point?
