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.

> "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?