Top
Best
New

Posted by jhalderm 10/28/2025

HTTPS by default(security.googleblog.com)
302 points | 255 commentspage 2
tepmoc 10/29/2025|
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
superkuh 10/29/2025||
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.
rr808 10/29/2025||
Https really sucks for our intranet. Every little web app and service needs certificates and you can't use letsencrypt.
itintheory 10/29/2025||
You may not want to, but you can use public certs and URLs on your intranet. You can't necessarily do http-01 challenges, but DNS based challenges are feasible. There are also other ACME providers which will let you skip challenges for DCVd domains.
kassner 10/30/2025||
> There are also other ACME providers which will let you skip challenges for DCVd domains

Do you have examples? I’m not sure how to search for this feature.

keyle 10/29/2025||
I'm sure there will be a setting flag to stop blocking http sites, or maybe even a domain exclusion which will let you set up your intranet to work on http.

Maybe everything .local will already be allowed.

austin-cheney 10/29/2025||
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.

popcornricecake 10/29/2025|
It's not even certificates that's the problem, but trust. And here Google is making exceptions to allow unencrypted connections to private addresses, because trust is hard. If encryption was not tied to trust, then we would have 0 unencrypted connections by now and we would be that much better off.

Making an exception to allow plain HTTP connections instead of making an exception to allow self-signed certificates, seems like the worse choice to me.

austin-cheney 10/29/2025||
Yeah, that is an excellent point. I really wish there were a unique icon for self-signed certificates opposed to other untrusted certificates. Self-signed certificates are not deceptive or malicious but they are not trusted. In a localhost environment self-signed certificates from the host machine are perfectly fine. Even better would be if browsers did not require certificates at all to make use of HTTPS from localhost, 127.0.0.1, or ::1
shadowgovt 10/28/2025||
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.

marginalia_nu 10/28/2025||
How exactly are unencrypted localhost connections a security weakness? To intercept the data on a loopback connection you'd need a level of access where encryption wouldn't really add much privacy.
zamadatix 10/28/2025|||
Chrome treats localhost as a secure origin (regardless of HTTPS) by default - don't overthink it.
shadowgovt 10/28/2025||
Oh, groovy; if they keep doing that I'm all good, since I usually do one-off remote stuff by SSH tunnels anyway.
jmholla 10/28/2025|||
I haven't used it, but I think `mkcert` is the go to solution for this. [0]

[0]: https://github.com/FiloSottile/mkcert

tracker1 10/28/2025||
As good an idea as this is... I do hope that localhost/127.0.0.1 will be excluded for devs/testers.
cube00 10/28/2025||
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.

matthewaveryusa 10/29/2025||
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.

fooofw 10/28/2025||
What defines private sites, I wonder – beyond "such as local IP addresses like 192.168.0.1, single-label hostnames, and shortlinks like intranet/"?
dadrian 10/28/2025|
Non-unique hostnames, which are RFC 1918 space, single-label hostnames, and addresses assigned to mDNS (.local).
srcreigh 10/28/2025|||
Single label hostnames had an issue where it’s hard to type them into a browser.

How to fix this?

jeroenhd 10/28/2025|||
Usually, completing the domain name by adding the final period will do the job. Instead of entering myprinter into the address bar, try myprinter. so your DNS server doesn't try to resolve myprinter, myprinter.domain, myprinter.domain.tld, and whatever other search domains have been configured. A real, fully-qualified domain ends in a period, though most tools will happily let you avoid that final period.

Alternatively, .local domains will work for mDNS-capable devices (and non-mDNS-capable devices if you like to risk things breaking randomly), and the .internal TLD has been reserved so .internal domains should also work for local addresses.

dadrian 10/28/2025|||
Add a /, e.g. `shortname/`
More comments...