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

141–150 of 463 posts

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

#141

Post by somehnguy »

wjrtyjw wrote: post #131
boardwaalk wrote: post #118

Earlier quoted context omitted.

It seems like we should have something like known_hosts for ssh, yeah. As long as it’s trusting one domain at a time (not a root CA), would it really be /that/ bad? This and browser vendors being overbearing about extensions (I know they’re powerful) gets me down.

Isn't this the default behavior of most browsers? Access an https service with an untrusted tls certificate, the browser throws a warning and offers a way to permanently trust the certificate.

Neither Chrome nor Edge offer a simple way to permanently trust the cert. I’m sure there is a way to do it but they don’t make it obvious. It’s maddening as someone who develops and distributes local network apps with https.

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

#143

Post by maxk42 »

shadowgovt wrote: post #115
maxk42 wrote: post #64

I've said it many times, but nobody seems concerned: Certificate authorities are being used as tools of censorship by oppressive regimes. Until a central-authority-free alternative exists, the move to HTTPS is bad for a free world.

Is it better for a free world to have the traffic be unencrypted? Feels like one head of the hydra is control of the cert-trust network, but another head is traffic-sniffing and monitoring one's online activity, yeah?

Please do not bring a straw man argument to the table. I clearly said " Until a central-authority-free alternative exists". Such alternatives are readily available and already used to secure e.g. ssh connections, but are not without drawbacks. One alternative that might be less likely to suffer from the same weaknesses as a certifcate-free model is a distributed certificate authority that relies on a ledger like DNS.

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

#144

Post by alecbz »

j1elo wrote: post #136
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…

It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. What happens with offline LAN? And the ideal IoT devices that we would all want to have? (I mean those we dream about in all IoT HN posts, where the rants typically are that no internet connection should be needed for most of these kinds of devices) What about offlin…

> 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).

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

#145

Post by alecbz »

prepend wrote: post #56
reaperducer wrote: post #48

When the big push to HTTPS came around, I was all in favor of it. Now... I'm more skeptical. Not everything has to be HTTPS. And I've become aware that many of the sites I visit are HTTP only and will never become HTTPS because of their age, or the lack of technical ability of their owners. HTTPS also has the side effect of obsoleting older hardware for no real reason. I have devices that work perfectly fine, but can…

I like using http where appropriate and not wasting resources. I publish a blog and there’s no need for https. Adding https just adds a little more effort and provides no benefit to the user. I guess if you count the ISP not knowing, but Google knowing, that you’re visiting my blog, then that’s a reason. But that’s a user issue, not a server issue. Practically, my host does all the cert stuff for me and it’s not hard…

You don't care if your blog's content gets MITM'd?

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

#146

Post by heavyset_go »

boardwaalk wrote: post #118
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…

It seems like we should have something like known_hosts for ssh, yeah. As long as it’s trusting one domain at a time (not a root CA), would it really be /that/ bad? This and browser vendors being overbearing about extensions (I know they’re powerful) gets me down.

You used to be able to add your own certificates to a device's certificate store. Nonadjustable certificate stores complement planned obsolescence, and help split the market into consumer and enterprise devices, that latter of which you can charge a premium for.

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

#147

Post by WanderPanda »

wjrtyjw wrote: post #131
boardwaalk wrote: post #118

Earlier quoted context omitted.

It seems like we should have something like known_hosts for ssh, yeah. As long as it’s trusting one domain at a time (not a root CA), would it really be /that/ bad? This and browser vendors being overbearing about extensions (I know they’re powerful) gets me down.

Isn't this the default behavior of most browsers? Access an https service with an untrusted tls certificate, the browser throws a warning and offers a way to permanently trust the certificate.

I am actually glad that they don’t permanently trust it like I belief Safari does it. Accepting invalid certificates in Safari always freaks me out

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

#148

Post by [deleted] »

remram wrote: post #82
Ajedi32 wrote: post #20

Earlier quoted context omitted.

It seems like this is primarily a performance optimization, at least for now. One less round trip when navigating to a site by typing the domain name when that site redirects to HTTPS (and isn't on the HSTS preload list).

It's a huge security improvement. The HTTP->HTTPS redirection is not secured in any way. [edit: it's not really because it falls back]

[deleted]

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

#149

Post by xg15 »

londons_explore wrote: post #134
simias wrote: post #127

Earlier quoted context omitted.

I develop broadcast TV equipments which are often rented all over the place for short amounts of time, often don't have any direct internet access etc... I simply cannot make any assumption about the network these devices will run, and can certainly not rely on any sort of DNS validation. Virtually 100% of the time the devices are addressed directly by IPv4. I really can't think of a solution for this situation. For…

DNS validation can entirely be done by a server on the internet, which does all the stuff necessary to get the certificate, and then gives the certificate to your end user device. All the end user device needs is a connection to the internet once per 90 days. The vast majority of networks have sufficient network connectivity for this.

I think the more frustrating point is that you need all this internet infrastructure (with running costs) at all - even if your device has nothing to do with the internet at all.

If the vendor of your dumb device goes out of business, you can just keep using the device until it breaks down.

If the vendor of a "smart" device - or now anything with a modern web interface - goes out of business, the device will have a broken UX at best and at worst turns into a brick 90 days later.

In the end, browsers are now a platform and you have to register and pay a subscription fee to make use of them.

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

#150

Post by j1elo »

alecbz wrote: post #144
j1elo wrote: post #136

Earlier quoted context omitted.

It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. What happens with offline LAN? And the ideal IoT devices that we would all want to have? (I mean those we dream about in all IoT HN posts, where the rants typically are that no internet connection should be needed for most of these kinds of devices) What about offlin…

> 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 their eyes and ignoring the use cases that are not interesting to them. The mandatory renewal timing is a good example: it used to be more than 1 year, now it is 90 days (and some would like to reduce it to mere weeks!) Absolutely great for the grand scheme of things and global security of the Internet, but dismaying for lots of other use cases.

Post reply on HN