Remix.run Logo
sam_lowry_ 2 days ago

I am running an HTTP-only blog and it's getting harder every year not to switch to HTTPS.

For instance, Whatsapp can not open HTTP links anymore.

pornel 17 hours ago | parent | next [-]

You're making a mistake assuming that the push for HTTPS-only Web is about protecting the content of your site.

The problem is that mere existence of HTTP is a vulnerability. Users following any insecure link to anywhere allow MITM attackers to inject any content, and redirect to any URL.

These can be targeted attacks against vulnerabilities in the browser. These can be turning browsers into a botnet like the Great Cannon. These can be redirects, popunders, or other sneaky tab manipulation for opening phishing pages for other domains (unrelated to yours) that do have important content.

Your server probably won't even be contacted during such attack. Insecure URLs to your site are the vulnerability. Don't spread URLs that disable network-level security.

projektfu 2 days ago | parent | prev | next [-]

You can proxy it, which for a small server might be the best way to avoid heavy traffic, through caching at the proxy.

g-b-r 2 days ago | parent | prev [-]

For god's sake, however complex ACME might be it's better than not supporting TLS

agarren a day ago | parent | next [-]

Why? I can understand the argument that you don’t want an ISP or a middlebox injecting ads or scripts (valid I think even if I’ve never encountered it to my knowledge), but otherwise you’re publishing content intended for the world. There’s presumably nothing especially sensitive that you need to hide on the wire.

mort96 a day ago | parent [-]

> (valid I think even if I’ve never encountered it to my knowledge)

Visitors to your website may encounter it. Do you not care that your visitors may be seeing ads?

You're also leaking what your visitors are reading to their ISPs and governments. Maybe you don't consider anything you write about to be remotely sensitive, but how critically do you examine that with every new piece you write?

If you wrote something which could be sensitive to readers in some parts of the world (something about circumventing censorship, something critical of some religion, something involving abortion or other forms of healthcare that some governments are cracking down on), do you then add SSL at that point? Or do you refrain from publishing it?

Personally, I like the freedom to just not think about these things. I can write about whatever I want, however controversial it might be in some regions, no matter how dangerous it is for some people to be found reading about it, and be confident that my readers can expect at least a baseline of safety because my blog, like pretty much every other in the world today, uses cryptography to ensure that governments and ISPs can't use deep packet inspection to scan the words they read or use MITM to inject things into my blog. Does it really matter? Well probably not for my site specifically, but across all the blogs and websites in the world and all the visitors in the world, that's a whole lot of "probably not"s which all combine together into a huge "almost definitely".

nssnsjsjsjs a day ago | parent [-]

I agree but SSL doesn't encrypt the IP so there is that information leaked. That isn't to say don't use SSL but more it isn't 100% privacy protection from middlemen.

mort96 a day ago | parent [-]

Yeah, it's unfortunate that it doesn't hide the IP address you connect to. But my thinking is: for someone to hypothetically get in trouble for reading my blog if I don't use SSL, their ISP/government just needs to inspect the packets they receive and scan for particular words or phrases, and they'll have hard proof that the person accessed a particular article. If I use SSL, those governments must have specifically flagged my web server's IP address, and they won't have any hard proof about what content was accessed.

So while it's not perfect, it's pretty good, and a very low investment for me as a website owner :)

bigstrat2003 2 days ago | parent | prev | next [-]

There's no good reason to serve a blog over TLS. You're not handling sensitive data, so unencrypted is just fine.

foobiekr 2 days ago | parent | next [-]

The reason is to prevent your site from becoming a watering hole where malicious actors use it to inject malware into the browsers of your users.

TLS isn't for you, it's for your readers.

dijit a day ago | parent | next [-]

but like, who’s doing that?

Maybe the answer is disabling the JS runtime on non-TLS sites, maybe that has the added benefit of making the web (documents and “posters”) light again.

SMS is unencrypted, phone calls are unencrypted- yet we don’t worry nearly as much about people injecting content or modifying things. Because we trust out providers, largely, but the capability 100% exists for that; with no actual recourse. With browsing the internet we do have recourse- optionally use a VPN.

All of this security theatre is just moving the trust around, I would much rather make laws that protect the integrity of traffic sent via ISPs than add to the computational waste from military grade encrypting the local menu for the pizza shop.

Worse still, the pizza shop won’t go through the effort so they either won’t bother having a website or will put it on facebook or some other crazy centralised platform.

I’ll tell you something, I trust my ISP (Bahnhof- famous for protecting thepiratebay) a lot more than I trust Facebook not to do weird moderation activities.

GoblinSlayer a day ago | parent | prev [-]

Ads will inject it anyway.

nssnsjsjsjs a day ago | parent [-]

If there are ads.

cAtte_ 2 days ago | parent | prev | next [-]

relevant blog post and HN discussion: https://news.ycombinator.com/item?id=22146291

throw0101b 2 days ago | parent | prev | next [-]

> You're not handling sensitive data, so unencrypted is just fine.

Except when an adversary MITMs your site and injects an attack to one of your readers:

* https://www.infoworld.com/article/2188091/uk-spy-agency-uses...

Further: tapping glass is a thing, and if the only traffic that is encrypted is the "important" or "sensitive" stuff, then it sticks out in the flow, and so attackers know to focus just on that. If all traffic is encrypted, then it's much harder for attackers to figure out what is important and what is not.

So by encrypting your "unimportant" data you add more noise that has to be sifted through.

2 days ago | parent | prev [-]
[deleted]
sam_lowry_ 2 days ago | parent | prev [-]

Why? The days of MITM boxes injecting content into HTTP traffic are basically over, and frankly they never were a thing in my part of the world.

I see no other reason to serve content over HTTPS.

JoshTriplett 2 days ago | parent | next [-]

> Why? The days of MITM boxes injecting content into HTTP traffic are basically over

The reason you don't see many MITM boxes injecting content into HTTP anymore is because of widespread HTTPS adoption and browsers taking steps to distrust HTTP, making MITM injection a near-useless tactic.

(This rhymes with the observation that some people now perceive Y2K as overhyped fear-mongering that amounted to nothing, without understanding that immense work happened behind the scenes to avert problems.)

schoen 2 days ago | parent | next [-]

https://en.wikipedia.org/wiki/Preparedness_paradox

JoshTriplett a day ago | parent [-]

Thank you!

sam_lowry_ 2 days ago | parent | prev [-]

How do browsers distrust HTTP, exactly?

JoshTriplett 2 days ago | parent | next [-]

They show any site served over HTTP as explicitly not secure in the address bar (making HTTPS the "default" and HTTP the visibly dangerous option), they limit many web APIs to sites served over HTTPS ( https://developer.mozilla.org/en-US/docs/Web/Security/Secure...) , https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ), they block or upgrade mixed-content by default (HTTPS sites cannot request HTTP-only resources anymore), they require HTTPS for HTTP/2 and HTTP/3, they increasingly attempt HTTPS to a site first even if linked/typed as http, they warn about downloads over http, and they're continuing to ratchet up such measures over time.

foobiekr 2 days ago | parent | next [-]

If browser vendors really cared, they would disable javascript on non-https sites.

GoblinSlayer a day ago | parent [-]

https://googleprojectzero.blogspot.com/2025/03/blasting-past...

fc417fc802 2 days ago | parent | prev [-]

> they increasingly attempt HTTPS to a site first even if linked/typed as http

And can generally be configured by the user not to downgrade to http without an explicit prompt.

Honestly I disagree with the refusal to support various APIs over http. Making the (configurable last I checked) prompt mandatory per browser session would have sufficed to push all mainstream sites to strictly https.

JoshTriplett 2 days ago | parent [-]

> And can generally be configured by the user not to downgrade to http without an explicit prompt.

Absolutely, and this works quite well on the current web.

> Honestly I disagree with the refusal to support various APIs over http.

There are multiple good reasons to do so. Part of it is pushing people to HTTPS; part of it is the observation that if you allow an API over HTTP, you're allowing that API to any attacker.

fc417fc802 2 days ago | parent [-]

> if you allow an API over HTTP, you're allowing that API to any attacker.

In the scenario I described you're doing that only after the user has explicitly opted in on a case by case basis, and you're forcing a per-session nag on them in order to coerce mainstream website operators to adopt the secure default.

At that point it's functionally slightly more obtuse than adding an exception for a certificate (because those are persistent). Rejecting the latter on the basis of security is adopting a position that no amount of user discretion is acceptable. At least personally I'm comfortable disagreeing with that.

More generally, I support secure defaults but almost invariably disagree with disallowing users to shoot themselves in the foot. As an example, I expect a stern warning if I attempt to uninstall my kernel but I also expect the software on my device to do exactly what I tell it to 100% of the time regardless of what the developers might have thought was best for me.

JoshTriplett 2 days ago | parent [-]

> More generally, I support secure defaults but almost invariably disagree with disallowing users to shoot themselves in the foot.

I agree with this. But also, there is a strong degree to which users will go track down ways (or follow random instructions) to shoot themselves in the foot if some site they care about says "do this so we can function!". I do think, in cases where there's value in collectively pushing for better defaults, it's sometimes OK for the "I can always make my device do exactly what I tell it to do" escape hatch to be "download the source and change it yourself". Not every escape hatch gets a setting, because not every escape hatch is supported.

fc417fc802 2 days ago | parent [-]

> escape hatch to be "download the source and change it yourself"

In theory I agree. In practice building a modern browser is neither easy nor is it feasible to do so on an average computer.

Given that a nag message would suffice to coerce all mainstream operators (thus accomplishing the goals I've seen stated) I'm left unconvinced. That said, I'm not particularly bothered since the trivial workaround is a self signed certificate and the user adding an exception. It's admittedly a case of principle rather than practice.

castillar76 2 days ago | parent | prev | next [-]

They’ve been making it harder and harder to serve things over HTTP-only for a while now. Steps like marking HTTP with big “NOT SECURE” labels and trying to auto-push to HTTP have been pretty effective. (With the exception of certain contexts, I think this is a generally good trend, FWIW.)

g-b-r 2 days ago | parent [-]

I have to change two settings to be able to see plain http things, and luckily I only need to a handful of times a year.

If I'm really curious about your plain http site I'll check it out through archive.org, and I'm definitely not going to keep visiting it frequently.

It's been easy to live with forced https for at least five years (and for at least the last ten with https first, with confirmations for plain http).

castillar76 20 hours ago | parent [-]

I was genuinely taken aback by visiting a restaurant website last night that was only served over HTTP. (Attempting to hit it with HTTPS generated a cert error because their shared provider didn't have a cert for it.) These days, I'd gotten so used to things just being over HTTPS all the time that the warnings in the browser _actually worked_ to grab my attention.

It's a restaurant that's been here with the same menu since the 1970s, and their website does absolutely nothing besides pass out information (phone number, menu, directions), so they probably put it up in 2002 and haven't changed it since. It was just a startling reminder of how ubiquitous HTTPS has gotten.

0xCMP 2 days ago | parent | prev [-]

If you try to open anything with just HTTP on an iOS device (e.g. "Hey, look at this thing I made and have served on the public internet! <link>") it just won't load.

This was my experience sending a link to someone who primarily uses an iPad and is non-technical. They were not going to find/open their Macbook to see the link.

g-b-r 2 days ago | parent | prev | next [-]

You see no reason for privacy, ok

DonHopkins 2 days ago | parent | prev [-]

[flagged]