Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome’s address bar will use https:// by default

blog.chromium.org

Post reply on HN
Print view View original

181–190 of 463 posts

Re: Chrome’s address bar will use https:// by default

#181

Post by Karunamon »

superkuh wrote: post #135
patrickmcnamara wrote: post #22

I'm surprised this took so long. I tried to find an extension recently that could completely block HTTP but I couldn't find anything.

What you've described is, of course, what Google wants in the long run. For corporations making money on the web HTTPS is required and it makes a lot of sense. The problem is the web isn't just corporate sites involving money or private information. But if a browswer, or individual, begins blocking HTTP sites what they're effectively doing is saying, "Only sites approved by corporations should be visitable." This is…

You're not wrong, but plaintext needs to die for reasons everyone already understands. We can deal with the implementation details^wabuses later.

Re: Chrome’s address bar will use https:// by default

#182

Post by Ajedi32 »

superkuh wrote: post #135
patrickmcnamara wrote: post #22

I'm surprised this took so long. I tried to find an extension recently that could completely block HTTP but I couldn't find anything.

What you've described is, of course, what Google wants in the long run. For corporations making money on the web HTTPS is required and it makes a lot of sense. The problem is the web isn't just corporate sites involving money or private information. But if a browswer, or individual, begins blocking HTTP sites what they're effectively doing is saying, "Only sites approved by corporations should be visitable." This is…

A human person can't be a DNS registrar either.

TLS certs aren't a stamp of approval; they're just a statement saying "we've verified that this public key belongs to the owner of this domain".

Re: Chrome’s address bar will use https:// by default

#183

Post by Wowfunhappy »

j1elo wrote: post #150
alecbz wrote: post #144

Earlier quoted context omitted.

> without recourse Doesn't the post say they'll fall back to http if the https attempt fails? > For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails. The only change here seems like it's that, from the user's perspective, initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower…

I'm talking about the general state of HTTPS implantation. If you develop an offline device which offers a web UI, and it happens to use any feature that is deemed to require a Secure Context , you're out of luck. WebRTC is such a feature, but there are lots more, and they can change from one version of the browser to the next one. The players who are pushing so hard to shove HTTPS down our throats are simply closing…

I don't actually see the problem. If you're on a local network, there's no practical way to deal with certificates, so use http. Chrome will fall back. Problem solved.

If http support ever gets truly removed, I will be very upset. But that hasn't happened, so what is there to complain about?

Re: Chrome’s address bar will use https:// by default

#184

Post by davidkhess »

simias wrote: post #111

I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they deci…

Here's an approach I've used before successfully. It's not perfect but it's better than nothing.

1. Create your own root Certificate Authority.

2. Create a script using your favorite language and libraries that will create a new certificate for each device something along the lines of "myiotdevice-AABBCCDD.local". The AABBCCDD needs to be some sort of serialized number that's assigned during manufacturing and won't be repeated between devices.

3. Add to your product support for ZeroConf/mDNS/DNS Service Discovery and advertise an https web server at myiotdevice-AABBCCDD.local.

4. Provide instructions to your users on how to download and install the certificate for your root CA (this only needs to be done once).

5. Print the name "myiotdevice-AABBCCDD.local" on the device and instruct users to type that in to a browser's address bar.

I'm doing this from memory so I may have missed an intricacy here or there (like DNS SD is a weird story on Windows 10) but this approach should basically work well enough.

EDIT - good commentary in replies about the dangers of the CA being compromised. Also, good mention of X.509 Name Constraints and how they can be used to mitigate that danger somewhat. More info here: https://systemoverlord.com/2020/06/14/private-ca-with-x-509-...

Re: Chrome’s address bar will use https:// by default

#185

Post by ohyeshedid »

fluidcruft wrote: post #51
pornel wrote: post #13

That makes a lot of sense. HTTPS adoption is now very high[1], and this might push it a little bit further for sites that don't redirect to HTTPS automatically. I've been using Firefox in the experimental HTTPS-only mode, and the web is quite usable without cleartext HTTP. [1] https://transparencyreport.google.com/https/overview It's not a big change from security perspective though. HTTP requests shouldn't be gettin…

The biggest problem I'm having is that our edge firewall doesn't play nicely with it for some reason. I get these random websites that refuse to work in Firefox, but they always work fine in Chrome. And it's not certificate errors, it's just "connection reset by peer". I'm not entirely sure how it's working, but I've seen a few other people with these issues at the mozilla bug tracker and it's always just sort of eit…

I'm wondering if the tested Firefox install has enabled DoH?

Re: Chrome’s address bar will use https:// by default

#186

Post by nahuel0x »

simias wrote: post #111

I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they deci…

There is a (defunct?) W3C working group about this, see https://www.w3.org/community/httpslocal/ and https://github.com/httpslocal

Re: Chrome’s address bar will use https:// by default

#187

Post by Wowfunhappy »

MaxBarraclough wrote: post #178
franga2000 wrote: post #169

Earlier quoted context omitted.

Yeah, there really needs to be a "secure, but not trusted" mode. My suggestion would be add a "trusted-only" TXT DNS entry that a browser could check when presented with an untrusted connection. HTTP: gray broken padlock HTTPS+Cert: green padlock HTTPS+no cert: gray padlock HTTPS+no cert+trusted-only: red broken padlock Any complaints? No? Ok, let's make it a standard! Oh wait... we're not in control of the standard,…

On the face of it, it sounds simple enough: special treatment when the IP address is an IETF-designated private IPv4 address (e.g. 192.168.x.y). Is there some reason this wouldn't work, that I haven't thought of?

Whitelisting specific addresses makes me uncomfortable.

But I can't actually articulate why it would be bad in this instance, so maybe it's fine...

Re: Chrome’s address bar will use https:// by default

#188

Post by simias »

tony101 wrote: post #176
simias wrote: post #111

I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they deci…

> "I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they decide to proceed, or just go with good old HTTP but then you hit all sorts of limitations, and obviously zero security." How about what Plex did for its self-hosted media servers? "Firs…

That's very cool, but it still requires a working and reliable internet connection.

Also these ultra-long URLs are very clumsy and can't really be used directly, so you need to have some sort of cloud frontend that where the device phones home in order to announce its LAN IP, then the user can go through there in order to connect to their LAN devices.

For something like Plex it makes a lot of sense since you're probably going to have an internet connection when you use it anyway, but for my devices it's a deal breaker.

And at any rate, that's a whole lot of infrastructure just to be able to expose a simple web interface.

Re: Chrome’s address bar will use https:// by default

#189

Post by vladvasiliu »

tony101 wrote: post #176
simias wrote: post #111

I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they deci…

> "I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they decide to proceed, or just go with good old HTTP but then you hit all sorts of limitations, and obviously zero security." How about what Plex did for its self-hosted media servers? "Firs…

But this requires the manufacturer of the IoT device to provide a central service like Plex does.

Maybe they can't afford it, or the device is expected to run for a very long time, like even after the manufacturer goes out of business. Or as some other commenters have said, it's a personal / hobby project and the "manufacturer" doesn't have the means nor the will to maintain some outside management server.

Re: Chrome’s address bar will use https:// by default

#190

Post by cblconfederate »

jVinc wrote: post #168

What a journey it has been. http://www.example.com http://example.com https://example.com example.com We're finally getting there! Now just a decades to go and we'll reverse the order to get com.example After which we'll wait a couple of decades to decide we don't need TLDs as ICANN is instead just given a free pass to print any amount of money they want without that silly distraction. Then we'll be at just: example…

Actually we should have switched to resource locators that are just plain strings ("ycombinator news threads 26558305" . It s what google has been pushing everyone to do anyway (readable URLs), and what the centralization of the web led to ( fb / twitter usernames). Its easy for people to parse and speak through the phone, and it would be a decentralized, natural revival of AOL keywords. It would also drop total google searches by a few tens of percent

Not sure where the protocol would fit though

Post reply on HN