This is an awkward argument. One of my sites documents how to configure servers, for example. What excuse is there that something like that needs to be encrypted?

The most legitimate reason I've heard is for privacy. I don't believe the gov't is going to lock someone up for learning how to serve web pages.

Integrity protection. There are a lot of ways to instruct someone to configure their web server in a way that is subtly insecure, not to mention attacks like http://thejh.net/misc/website-terminal-copy-paste

It'd be slightly nice if we were able to have integrity-protected HTTP without encryption (lower overhead, easier debugging with packet dumps), but the advantages are minimal (ciphers are not really the overhead, SSLKEYLOGFILE is a thing) and it's a lot of complexity to the web platform, which is a downside for web developers like you and me: the rules for mixed content between HTTP, HTTPI, and HTTPS are going to be much more involved and confusing.

You can already send unecrypted authenticated data with HTTPS.

Via one of the NULL-cipher suites? That's a somewhat expansive definition of "can" and "HTTPS," since most if not all browsers are unwilling to negotiate any of those suites. Indeed, most SSL libraries make it hard to use those suites: for instance, OpenSSL says (`man ciphers`), "Because these offer no encryption at all and are a security risk they are disabled unless explicitly included."

Which makes sense, since they'd have the exact same problems as an explicit HTTPI protocol, just even more confusing: you'd want to not send things like secure cookies across those ciphers, you'd have to handle mixed content with actual-HTTPS carefully, etc.

Using HTTP instead of HTTPS allows an evil ISP injecting, for example, ads into your website or modifing its content in any way while serving it.

Keep in mind you're also ensuring the integrity of the document is kept and the user has (to some degree) a good idea that the document is actually from you. Confidentiality is only one aspect. I think a couple of ISPs in the US were injecting ads/content at one point into pages served over HTTP.

Consider Tor: in this case, your "ISP" is a random server on the internet. Maybe your Comcast or TimeWarner ISPs will not be malicious, but with Tor, any one in the world can register to be an exit node/ISP. HTTPS helps protect you from attacks in this "random ISP" model.

>I don't believe the gov't is going to lock someone up for learning how to serve web pages.

That's essentially the same as not locking your car doors because you feel your car isn't worth breaking into.

Sorry but I actualy can't load the website because of an HTTPS error (Firefox 43/Linux) (Error code : sec_error_ocsp_old_response).

I just downloaded and installed Firefox 44 today and it works great. Clear your cache?

So I've updated to Firefox 44 and it works indeed but it seems broken on Firefox 43.* on both of my computers (work and personal), you might want to have a look at it since 43.* is a quite recent version. (I'm not the one who downvoted you).

Here's a good excuse for not using https for everything: it breaks caching of files by proxies!

Right. So what's the solution? I run my wife's retail website. Am I supposed to just stop worrying about caching static assets like product images, scripts, etc.? Do I just throw my hands in the air and assume it evens out because I switched to HTTPS?

Serious question, what are my options?

Do you run the cache / contract with someone to run the cache, or are you worried about third parties who run caching servers out of your control (like mobile ISPs, corporate networks, etc.)? If the latter, I'm surprised/curious what the use case is.

If the former, you can stick those on HTTPS too just fine. CloudFlare will be an entire SSL-enabled CDN for you for free. Amazon Cloudfront will serve SSL for you for free (though you still have to pay for Cloudfront itself, and get a cert on your own, though you can do that for free).

Amazon Certificate Manager will issue certificates for CloudFront for free.

* Ensure your server is setting ETags correctly so the clients can determine which assets they need to re-request.

* Make use of edge CDNs with https termination

Turns out my CDN supports HTTPS (using cloudinary), so that's good. Thanks for the ETag reminder, I'm not doing that yet.

That's what CDNs are for. If you control your proxy, nothing prevents you from giving it access to your https by setting up your private key on it. Https is also tapable, but only by servers you trust.

The more privacy-conscious amongst us probably consider that a positive reason not a negative one...

I tried out caddyserver about an hour ago, and the ease of use is awesome. Had it serving my domain with a letsencrypt auto-generated cert in 2 minutes from never having looked at the caddy docs before.

> Regardless of Google's move, there is no excuse for any site not to be served encrypted anymore.

Honest question: are you willing to indemnify your users when the next Heartbleed-like attack comes out for the underlying SSL library you are using in your product?

If you are willing to do that, and will offer me a no-cost wildcard domain certificate, I will switch to your product and start using HTTPS.