I feel the notion of "I don't want to deal with HTTPS" is mostly to blame on the ridiculous UX of cert management in the past. The act of creating a CSR alone using openssl is reason enough to justify the emotional rejection of HTTPS.

Since I switched all my setups to Caddy [1] using HTTPS by default has become an absolute no-brainer and nothing to care about, as it simply happens automatically due to its built-in ACME support.

[1] https://caddyserver.com/

> 1. HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs. Man-in-the-middle attacks of this sort really have happened, [0] and remember that the browser itself may have exploitable security vulnerabilities.

1a. Spy agencies or botnets that have compromised routers and want to attack Internet users. (The spy agencies are probably more of a concern for backbone routers, while the botnets are probably more of a concern for CPE routers.)

> 5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just 3 reasons:

I've encountered, I guess, five others: you want to use the server in a mostly or totally offline environment (so it can't count on getting Internet access to perform renewals), you want to use a totally air-gapped environment, you don't possess a domain name or can't be sure of renewing it for some reason, you want to use web protocols for a very lightweight (but not necessarily very old) embedded system in a LAN, or you are subject to sanctions that prevent CAs from charging you for a certificate and/or issuing one to you at all.

I guess also "for some reason you want to use TCP/IP on a point-to-point link to collect telemetry where very low latency is your absolute highest priority, and integrity and/or confidentiality are handled sufficiently by some other layer somehow". (Although in that case the client probably isn't a web browser, so this probably isn't an issue.)

This is a good comment. There are I believe a couple more cases where HTTPS is difficult: - You use a dynamic subsubdomain scheme. E.g. abc.xyz.example.org. A wildcard certificate for *.example.org only covers xyz.example.org, not abc.xyz.example.org. Requesting a certificate as the page is requested is possible, but will cause a lot of latency, and you will probably hit the Let's Encrypt rate limit; - You embed resources that are only available over HTTP and cannot be proxied, either for technical or legal reasons; - You request resources from a local IP address, e.g. a website hosted on GitLab Pages that shows you the data from your own DIY weather station which runs in your local network.

These cases are not that common, but that does not make them nonexistent. 99% of websites don't fall under one of these cases (there are probably some others I have not even considered), and should probably support HTTPS.

I see HackerNews chewed up your formatting. An extra newline between bullet-points is necessary.

> You use a dynamic subsubdomain scheme

Good point. If you run a site that creates a new subdomain per customer, and uses subsubdomains, you might end up making a high volume of cert requests. I don't know a lot about this stuff but presumably there are paid CAs that offer a more generous rate limit than Let's Encrypt?

> You embed resources that are only available over HTTP and cannot be proxied, either for technical or legal reasons

When is this a problem?

> You request resources from a local IP address, e.g. a website hosted on GitLab Pages that shows you the data from your own DIY weather station which runs in your local network

I don't follow here. If for some reason you need to present that data as a local HTTP service, that service could just act as a proxy to GitLab Pages over HTTPS, no?

>HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs.

If you are in a legal/political environment that allows active attacks by an ISP on their customers then you have a much bigger problem than just this sort of thing.

Comcast in the US has injected content into non-secured pages to notify customers of things. That is a horrible business practice that should not be allowed.

What can I, an individual with nearly zero political clout (I can vote... but I live in a gerrymandered district... another layer to the problem!) do to get this problem fixed? Best case scenario, I say something, it goes viral, people march in protest against bad ISPs, the monopolies get broken up, etc. But how long does that all take?

Meanwhile, I'll only use HTTPS websites as a first-line of defense. The "much bigger problem" can be solved in parallel.

"It is in fact quite possible – and quite common – for a firewall or other device in your network path to terminate your TLS connection with a website and then re-create a TLS connection from the device to your browser." https://www.internetsociety.org/resources/deploy360/dane/

Isn't it then possible, albeit harder to do a MITM attack at this point with HTTPS?

If you've decided that you trust the "firewall or other device", perhaps because you purchased it, or because doing so is a condition of employment, then you get to keep both halves.

If the "firewall or other device" tries to interpose when you don't trust it, that won't work, for the same reason it doesn't work for bad guys. We do not distinguish the apparent reason for attempts to destroy the confidentiality, integrity or authenticity promises in TLS, whatever the apparent motive your HTTP transaction will either work, delivering those promises or you get an error and no progress is made.

This has happened in both USA & UK; in Toronto Canada, my top-2-in-the-country ISP has hijacked DNS, hijacked 404, and injected "helpful ads" at times. Every time there was a substantial backlash, but that came in on the nerds + grassroots level, not because of pre-existing laws.

"you" and clients connecting to your server might be different entities.

Thanks; #1 is the most persuasive argument for the type of site I'm envisioning (and likely massive part of "remaining 15%"). While a lot of other arguments in comments are not persuasive because they don't seem a feasible or relevant threat vector, a non-specific, generic injection of ads/malware makes more sense as a legitimate threat vector such a site could get caught in.

A fair question deserving a real answer, rather than downvotes.

It gets downvoted because this idea ("my site isn't sensitive so I don't want https") gets brought up and refuted every time LE or HTTPS comes up and it's getting old.