Discourse on HTTPS
An internet lectures passersby about webshit. The lectures are sprinkled with advertisements for an HTTP server that runs as root. We are expected to take security advice from this person seriously.
We do not.
Your site needs HTTPS.
"But my site doesn't have forms or collect information from users."
Doesn't matter. HTTPS protects more than just form data! HTTPS keeps the URLs, headers, and contents of all transferred pages confidential.
If I wanted confidentiality, maybe I'd care about HTTPS. But I don't, and if someone else does, they can acquire it themselves. My site does not need HTTPS.
"There's nothing sensitive on my site anyway."
Your site is a liability! Just because your site is hosted safely in your account doesn't mean it won't travel through cables and boxes controlled by who knows how many corporate- and state-owned entities. Do you really want someone injecting scripts, images, or ad content onto your page so that it looks like you put them there? Or changing the words on your page? Or using your site to attack other sites? This stuff happens: on airlines (a lot, and again), in China, even ISPs do it (a lot). And HTTPS prevents all of it. It guarantees content integrity and the ability to detect tampering. If we encrypt only secret content, then we automatically paint a target on those transmissions. Keep which of your transmissions contain secrets secret by encrypting everything.
None of those things are my problem. If people don't want to see my site with random trash inserted into it, they can choose not to access it through broken and/or compromised networks. If other website operators are concerned about this sort of thing, they are free to use HTTPS, but I have no reason to do so. Encryption should be available to anyone who wants to serve encrypted content, but I have no interest in using it for my website. It's a shame that people are using web browsers (note: not my website, but BROWSERS) as attack vectors. The legions of browser programmers employed by Mozilla, Google, Apple, and Microsoft should do something about that. It's not my flaw to fix, because it's a problem with the clients. My site does not need HTTPS.
"The site is HTTP, but our forms are submitted over HTTPS."
This is as bad as not using any HTTPS at all! All the attacker has to do is change the link or form action to a URL on his/her own server. There's no way to detect this because it happens over the wire with plain HTTP. Encrypt the WHOLE site and redirect HTTP to HTTPS.
This is a great reason to use HTTPS! It has nothing to do with my website, which does not have any interactive elements whatsoever. I don't use forms. What is there to attack? Nothing: my site does not need HTTPS.
"I can't afford a certificate."
I hope they soon become freely available from competent people as well. Meanwhile, I'll continue to pay for SSL certificates when I need them -- which is not for my website, because my site does not need HTTPS.
"HTTPS is difficult to set up and maintain."
Sure! I'll reengineer everything to use some hipster http server, which doesn't even run on half of the operating systems I use. What could be easier? No, thanks; my site does not need HTTPS.
"Attackers can still impersonate my site, even if I use HTTPS."
They can try, but as long as your private key stays private, browsers will show warnings if attackers present a mismatched or invalid TLS certificate. And if the attacker does not use HTTPS at all, browsers should mark the imposter page as insecure. To this end, HTTPS guarantees authenticity.
This is only true as long as some asshole certificate authority does not issue illegitimate certificates for my website. Good thing that doesn't happen, over and over and over and over. You can't convincingly pretend to be me if I don't make any promises about who I am, so my site does not need HTTPS.
"Domain-validated (DV) certificates aren't secure."
Yes they are. Just don't lose control over your DNS and choose a competent certificate authority (as opposed to less competent or troublesome ones). There is absolutely no difference in the cryptography in a DV certificate compared to that of an extended validation (EV) certificate.
Earlier you recommended letsencrypt, and now suddenly you want me to pick a competent certificate authority? The only reason they didn't leak my info already is because my site does not need HTTPS.
"But CAs can misissue for my site any day <...or any other complaint about the CA system>."
Look, this discussion isn't about PKI. It's the best system we've got for right now. Deal with it and secure your site. Use CAA records to restrict which CAs can issue certificates for your site, then cross your fingers and hope transparency and oversight works (it does, so far).
Your "best system" is a trash fire and gains me nothing. I will not participate; my site is secure enough for my desires without it. As an industry, take a breath and get your shit together, and get back to me when you're not such a goddamn embarrassment. I will not have to cross my fingers because my site does not need HTTPS.
"HTTPS doesn't hide the size of the content, leaking clues to attackers."
TLS 1.3 and HTTP/2 have padding frames to inflate the size of the ciphertext.
Super! Let me know when those get out of draft spec status and into something I can feasibly implement. Actually, don't; I do not need those technologies because my site does not need HTTPS.
"HTTPS doesn't hide the DNS lookup."
Of course not. DNS != HTTP. But is that really a valid reason not to encrypt the connection between your website and its visitors?? (Hint: no.)
This is indeed a pretty stupid objection to have against HTTPS. Fortunately I do not care whether the user's DNS lookups are hidden. I don't care if anything is hidden. So even though we're in agreement about this not being a valid objection: my site does not need HTTPS.
"HTTPS is slow."
No it's not. Sites with modern servers load faster over HTTPS than over HTTP because of HTTP/2.
...assuming you use HTTP/2. Which I will not. Anyway, I don't care whether HTTPS is slow, because my site does not need HTTPS.
"Phishing sites use HTTPS."
... so you won't?
No, but for entirely non-phishing related reasons. I won't use HTTPS because my site does not need HTTPS.
"Our site displays ads over HTTP."
Sorry, not sorry. Doesn't change the fact that your site still needs HTTPS. Switching to HTTPS with ads still over HTTP will cause mixed content warnings in browsers, so you better figure out a cute way to wiggle out of that ad publishing contract that looked really attractive when you first signed it, or convince your ad network to move to HTTPS before you do.
Obviously my site does not display ads; as has been pointed out, It does not even appear to be monetized. This is because I have a real job and the entire web ad industry can fuck itself off a cliff. So, while mixed-content warnings are pretty obnoxious, my site does not need HTTPS.
"It works over HTTP just fine."
That's what Oil and Gas International thought, too. Until browsers started flagging HTTP pages as insecure.
Good thing I'm not Oil and Gas International! I don't personally care if browsers flag HTTP pages as insecure, as insecurity does not materially affect my site. It works perfectly well right now, because my site does not need HTTPS.
"But TLS proxies break the guarantees of HTTPS."
Only if the end user's computer is modified to trust the TLS proxy. This requires administrator (root) privileges, so the owner of the computer must allow it. Besides, HTTPS interception can usually be detected by web servers.
First of all, there are plenty of circumstances in which root is not required to trust a CA. But that's not really the point here: this is all just handwaving away the earlier whining about how governments and ISPs are molesting HTTP traffic. If your government is actively hostile to your communications, overthrow it. If you think J. Random User is going to give a single shit (or even notice) when the telco provider ships a phone update that adds trust to MITM certs, you're completely delusional. So, yes. TLS proxies do break the "guarantees" of HTTPS. It's just software. It can't fix your society. Fortunately, none of that affects me, because my site does not need HTTPS.
"At least I can still serve my site over both HTTP and HTTPS."
The only reason you should open port 80 on your server is to redirect all requests to port 443 and then close the connection on port 80. (Someday, maybe we can drop port 80 altogether.)
I'll do whatever the fuck I please over port 80, thanks. I will abstain from port 443, because my site does not need HTTPS.
"My site is only accessible internally or with a VPN."
How much do you trust the corporation or state that owns the infrastructure? And the companies that produced the hardware that comprises your network? Or the VPN provider?
Far, far more than I trust you. I can sue my networking vendors for failure to meet the terms of their contract. What's my remediation for your bad advice? Anyway, I don't need to trust a VPN. This site is not intended to be encrypted at all, so my site does not need HTTPS.
"We hash the passwords."
Good for you. Now please tell me you're collecting them via HTTPS. ... you are, right?
I'll do you one better: I don't collect passwords at all! Only an asshole would build plaintext auth, so I agree that passwords should only be sent across encrypted connections -- but my site does not need HTTPS.
"HTTPS impacts SEO."
You're right—HTTPS improves it! Switching site URLs improperly may impact your search rankings, but HTTPS actually improves them. Just do the switch properly according to the search engine you're optimizing for, and everything will be fine, with only temporary side-effects at most.
I do not give a shit about SEO and I fervently wish for the speedy retirement of everyone who does. SEO shitbags rank with email spammers as the absolute lowest pigshit dirtfuck dregs of humanity. The world would be a better place without any of their noise. SEO is not of interest to me: one more reason my site does not need HTTPS.
"It's the browser's job to keep users safe."
True, but incomplete. It is not SOLELY the browser's job. Browsers can only keep the users safe if the server provides credentials through an HTTPS certificate. As a site owner, it's your responsibility to provide these credentials for your clients.
Horseshit. Users must keep themselves safe. Software can't ever do that for you. Users are on their own to ensure they use a quality web client, on a computer they're reasonably sure is well-maintained, over an internet connection that is not run by people who hate them. None of the packets I send out are unsafe, so my site does not need HTTPS.
— HOW TO GET ON HTTPS —
The easiest way is through Let's Encrypt and the Caddy web server, which enables HTTPS for all your sites automatically. You can also use a simple, stand-alone Let's Encrypt client called lego, which runs on every platform.
If you prefer a little more setup and system integration with traditional web servers, the EFF's client Certbot will suit you well.
There are plenty of other ways to get your site on HTTPS without much trouble. Das Surma has a guide for several web servers and CDNs like Cloudflare can make your site available over HTTPS for minimal fees, if any at all.
I don't really care how to get on HTTPS, because my site does not need HTTPS.