HN Reader

302

255

I have had HTTPS-by-default for years and I can say that we're past the point where there's noticeable year-to-year change for which sites aren't HTTPS. It's almost always old stuff that pre-dates Let's Encrypt (and presumably just nobody ever added HTTPS). The news site which stopped updating in 2007, the blog somebody last posted to in 2011, that sort of thing.

I think it's important to emphasise that although Tim's toy hypermedia system (the "World Wide Web") didn't come with baked in security, ordinary users have never really understood that. It seems to them as though http://foo.example/ must be guaranteed to be foo.example, just making that true by upgrading to HTTPS is way easier than somehow teaching billions of people that it wasn't true and then what they ought to do about that.

I am reminded of the UK's APP scams. "Authorized Push Payment" was a situation where ordinary people think they're paying say, "Big Law Firm" but actually a scammer persuaded them to give money to an account they control because historically the UK's payment systems didn't care about names, so to it a payment to "Big Law Firm" acct #123456789 is the same as a payment to "Jane Smith" acct #123456789 even though you'd never get a bank to open you an account in the name of "Big Law Firm" without documents the scammer doesn't have. To fix this, today's UK payment systems treat the name as a required match not merely for your records, so when you say "Big Law Firm" and try to pay Jane's account because you've been scammed, the software says "Wrong, are you being defrauded?" and so you're safe 'cos you have no reason to fill out "Jane Smith" as that's not who you're intending to give money to.

We could have tried to teach all the tens of millions of UK residents that the name was ignored and so they need other safeguards, but that's not practical. Upgrading payment systems to check the name was difficult but possible.

3 months agoby tialaramex

While this is great for end users, this just shows again what kind of monopoly Google has over the web by owning Chrome.

I work at a company that also happens to run a CDN and the sheer amount of layers Google forces everyone to put onto their stack, which was a very simple text based protocol, is mind boggling.

First there was simple TCP+HTTP. Then HTTPS came around, adding a lot of CPU load onto servers. Then they invented SPDY which became HTTP2, because websites exploded in asset use (mostly JS). Then they reinvented the layer 4 with QUIC (in-house first), which resulted in HTTP3. Now this.

Each of them adding more complexity and data framing onto, what used to be a simple message/file exchange protocol.

And you can not opt out, because customers put their websites into a website checker and want to see all green traffic lights.

3 months agoby philippta

I distinctly remember trying to sign up for Pandora’s premium plan back in 2012 and their credit card form being served and processed over HTTP. I emailed them telling them that I wanted to give them my money if they would just fix the form. They never got back to me or fix it for several more years while I gave my money to Spotify. Back then HTTPS was NOT the norm and it was a battle to switch people to it. Yes it is annoying for internal networks and a few other things but it is necessary.

3 months agoby IgorPartola

Mmmm, great that and mandatory key rotation every 90 days, plus needing to get a cert from an approved CA, means just that more busy work to have an independent web presence.

I don't like people externalizing their security policy preferences. Yes this might be more secure for a class of use-cases, but I as a user should be allowed to decide my threat model. It's not like these initiatives really solve the risks posed by bad actors. We have so much compliance theater around email, and we still have exactly the same threats and issues as existed twenty years ago.

3 months agoby ottah

Prediction: Wifi captive portal vendors will not react to this until after 90% of their customerbase has their funding dry up.

It is incredibly common for public wifi captive portals to be built on a stack of hacks, some of which require the inspection of HTTP and DNS requests to function.

*Yes better tools exist, but they dont arent commonly used, and require Portal, WAP and Client support. Most vendors just tell people to turn new fancy shit off, disable HTTPS and proceed with HTTP.

3 months agoby protocolture

Doesn't it already do this? I keep a domain or two on HTTP to force network-level auth flows (which don't always fire correctly when hitting HTTPS) and I've gotten warnings from Chrome about those sites every time for years... Only if I've been to the site recently does the warning not show up.

3 months agoby drusepth

http://http.rip/ is useful for testing this sort of thing. I used to test with http://neverssl.com/ until they added HTTPS for some reason.

3 months agoby p1mrx

> What's worse, many plaintext HTTP connections today are entirely invisible to users, as HTTP sites may immediately redirect to HTTPS sites. That gives users no opportunity to see Chrome's "Not Secure" URL bar warnings after the risk has occurred, and no opportunity to keep themselves safe in the first place.

What is the risk exactly? A man-in-the-middle redirect to a malicious https site?

3 months agoby bo1024

This is to be honest a little unfortunate. While Https is very important, do we really need to verify that Blog X that I may read once a year is really who they say they are? For many sites it doesn't make a lot of sense but we are here due to human nature

3 months agoby cowl

http://www.slackware.com/ is probably the biggest website I'm aware of that does not serve encrypted traffic[1]. but there are a few other legitimately useful resources that don't encrypt.

[1] (Except on the arm subdomain for some reason)

3 months agoby marginalia_nu

I love https, but I also hate that its basically killed on-site caching and give CDNs more power as its only way to distribute content closer to user

3 months agoby tepmoc

HTTPS is great. HTTPS without HTTP is terrible for many human person use cases. Pretending those use cases don't exist is anti-human. But for corporate person use cases HTTPS-only is more than fine, it's required. So they'll force it on us all in all contexts. But in our own personal setups we can chose to be the change we want to see in the world and run HTTP+HTTPS. Even if most of the web becomes an HTTPS-only ID-centric corporate wasteland it doesn't take that many people to make a real web. It existed before them and still does. There's more human's websites out there now then ever. It's just getting harder and harder to find and see using their search and browser defaults. It's not okay, but maybe this is finally a solution to eternal september and we can all just live peacefully on TCP/IP HTTP/1.1 HTTP+HTTPS with HTML while corporate persons diverge off into UDP-land with HTTP/3 HTTPS-only CA TLS only QUIC for delivering javascript applications.

3 months agoby superkuh

Https really sucks for our intranet. Every little web app and service needs certificates and you can't use letsencrypt.

3 months agoby rr808

The only challenge to https, as compared to http, is certificates. If not for certificates I could roll out a server with https absolutely anywhere in seconds including localhost and internal intranets.

On another note I would much prefer to skip https, as the default, and go straight to WSS (TLS WebSockets). WebSockets are superior to HTTP in absolutely every regard except that HTTP is session-less.

3 months agoby austin-cheney

Good stuff.

Anyone have a good recipe for setting up an HTTPS for one-off experiments in localhost? I generally don't because there isn't much of a compromise story there, but it's always been a security weakness in how I do tests and if Chrome is going to start reminding me stridently I should probably bother to fix it.

3 months agoby shadowgovt

As good an idea as this is... I do hope that localhost/127.0.0.1 will be excluded for devs/testers.

3 months agoby tracker1

What's worse, many plaintext HTTP connections today are entirely invisible to users, as HTTP sites may immediately redirect to HTTPS sites. That gives users no opportunity to see Chrome's "Not Secure" URL bar warnings after the risk has occurred, and no opportunity to keep themselves safe in the first place.

Two hosting providers I use only offer HTTP redirects (one being so bad it serves up a self signed cert on the redirect if you attempt HTTPS) so hopefully this kicks them into gear to offer proper secure redirects.

3 months agoby cube00

If I set a DNS entry that points to a private ip (e.g, A internal.domain.com 192.168.0.5), will the allow private site setting succeed or fail for http://internal.domain.com?

Either way I agreee with this update. It's better to put the burden of knowledge on those hosting things locally and tinkering with DNS than those that have no idea that a domain does not infer ownership of said domain.

3 months agoby matthewaveryusa

What defines private sites, I wonder – beyond "such as local IP addresses like 192.168.0.1, single-label hostnames, and shortlinks like intranet/"?

3 months agoby fooofw

> HTTPS adoption expressed as a percentage of main frame page loads

Why is Linux adoption at 80% when MacOS/Android/Windows are at 95%? Quite unexpected.

3 months agoby dist-epoch

> One year from now, with the release of Chrome 154 in October 2026...

Wait a minute, how do they know what version Chrome will be at a year from now?

3 months agoby lateforwork

I see this as pretty much only a positive thing.

3 months agoby not4uffin

I for one hate https. Some html5 apis like location do not work without it and you get big fat warnings if you don‘t use it.

From having to pay for it in the past to now having to set up lets-encrypt, certbot, https-ingresses!

God, half my hobbyist and raw non-helm kubernetes config is https related. https-ingress.yaml is gigantic!

Is this really the best devex we could come up with?

3 months agoby Traubenfuchs

Does this apply to requests made by JS or just page loads?

3 months agoby MBCook

How dangerous is plain http?

3 months agoby bagol

Security theatre is all it is. Protect us from petty thieves but let our employers and the gov MITM our comms.

3 months agoby nakamoto_damacy

Thanks God, i am not using google

3 months agoby pKropotkin

"cannot connect" is next ?

3 months agoby mistrial9

We need to replace the DNS system with a blockchain-based alternative where people can own domains on-chain without renewal fees. The public key used to encrypt data would be shown alongside the IP addresses registered for that domain name (same record). The owner of the domain (an NFT) would be able to change their public encryption key at will on-chain. They would only pay a fee when they want to perform some write action; holding the domain and lookups would be free forever. No need to separate DNS from the certification and encryption layer. You know the private key, you own the domain. So much cleaner than the mess we have now.

If someone doesn't like it, they can stay behind on the old DNS system or they can launch a new blockchain with their own version of reality... It's retarded that we need to have one version of reality for the entire planet. If someone in China wants to own facebook.com, they should be allowed. Heck, it could be a separate silo per city. The age of copyright and trademark is over. I don't see AI companies distributing royalties to people who wrote its training set...

3 months agoby jongjong