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

331–340 of 463 posts

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

#331

Post by zaarn »

heinrichhartman wrote: post #291
chpatrick wrote: post #259

Earlier quoted context omitted.

You can set up the users' machines so that they trust your certificate.

I have tried to do just that but ran into all kinds of difficulties: 1. Overhead: I have 5 devices that I own 3 of my wife and a smart TV. Setting all this us takes a lot of time, even if it worked fine. 2. What about visitors to my home, that I want to give access? They need the cert as well together with lengthy instructions on how to install it. 3. How do I even install certs on an iPhone? 4. Firefox uses it's own…

If you keep your CA secure, no reason that you can't set the expiration of the root cert to something like 10 years.

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

#332

Post by jussij »

chc wrote: post #294
forgotmypw17 wrote: post #241

Earlier quoted context omitted.

I AM against it, because it puts more centralized censorship power in the hands of the certificate authority. Also, it completely cuts out "legacy" devices, basically anything more than 5 years old. The Web is once again splitting into AOLized mainstream and "indie underground" that you have to make an effort to access.

Who is "the certificate authority" you're referring to here?

The OP means that in using https (and being forced to used https) you are also being forced into paying a 'third party' an annual fee just to get a valid certificate.

That 'third party' is one of the recognized 'certificate authorities'.

But the OPs point is by going https, you don't have a choice, you have to pay the certificate tax.

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

#333

Post by zaarn »

xg15 wrote: post #308
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…

> 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). More than a bit. For HTTPS-only sites, the site could serve a stub HTTP endpoint on port 80 that redirects to HTTPS. The redirect causes maybe some milliseconds to a few seconds (worst case) of latency. HTTP-only on the other hand can't do a HTTPS stub as easily…

You can simply send a ICMP Rejected Message, which should direct your browser to immediately try any fallbacks or other hosts.

Timeouts occur when you incorrectly configure your firewall to drop packets instead of rejecting.

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

#334

Post by staticassertion »

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…

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

70% of the scenarios impact 99.99% of users as well as the project's intended scenario.

> being limited to the same host.

Yes, that's the point, of course.

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

#336

Post by v3v3 »

mastre_ wrote: post #293

I feel like I'm asking the obvious, but.. is it that hard to mention a date when you're going to break a bunch of stuff, so those affected at least know how long they have to look for contingency plans? For those who don't know how long it takes for a Chrome version to move from dev (v90 is there now) to prod it would be nice to have an idea, is it a week/month/90 days?

https://www.chromestatus.com/features/schedule

Stable in 21 days ( Apr 13 )

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

#337

Post by Wowfunhappy »

jodrellblank wrote: post #292
tsimionescu wrote: post #244

Earlier quoted context omitted.

Repeat every 3 months or whenever the root certs expire.

3 months? I must have updated FireFox / Discord / VS Code /etc. about a hundred times in last 3 months. Plenty for them to add renewed SSL whatevers inside one of the updates.

> 3 months? I must have updated FireFox / Discord / VS Code /etc.

I think this state of affairs is nuts. With the exception of Firefox, because web browsers have an inordinate number of security issues to contend with.

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

#338

Post by kevin_thibedeau »

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…

You can get embedded devices with TLS running in 200K of RAM. Cypress has WiFi MCUs based on Cortex M4 running their WICED stack which is a customized FreeRTOS, LwIP, and MbedTLS. I can't wholeheartedly recommend it as a platform because their modifications to reduce memory consumption break the MbedTLS API in subtle ways that make porting code more difficult than it needs to, but it is possible to get secure networking on something less capable than an RPi.

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

#339

Post by Wowfunhappy »

dan-robertson wrote: post #303
j1elo wrote: post #263

Earlier quoted context omitted.

That number was totally made up, of course :) that's why I quoted it... didn't really want to be too pedant and explicitly say it, but maybe I should have.

But the number matters to your point. Focusing on 70% of users to the detriment of 30% seems a lot less defensible than focusing on 99.9% of users to the detriment of 0.1%. The claim you made was “chrome is hurting a large minority of users and they should make a browser in a more fair way” but this changes when you change your made up numbers to something more like “chrome is hurting a tiny minority of users with we…

> Focusing on 70% of users to the detriment of 30% seems a lot less defensible than focusing on 99.9% of users to the detriment of 0.1%.

Ah, but now you’re measuring a different thing than the GP, users vs scenarios!

I’d hazard a guess that at least 30% of users need to log into a router at some point or another. I hope it’s more than 30%, because everyone else is likely paying ridiculous prices for a crappy router from their ISP.

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

#340

Post by maxboone »

jiehong wrote: post #323
netsec_burn wrote: post #240

Earlier quoted context omitted.

I've always thought reversing the order makes sense.

Yep, that’s called the FQDN (with a leading dot, so it’s .com.example)

It is the FQDN, but the .com.example notation specifically is generally called big-endian notation (it puts the most significant part first), the UK used to use this with JANET's NRS opposed to DNS.

We notate IP-addresses like that as well: - (MSB) fe80::1 (LSB) - (MSB) 10.0.0.1 (LSB)

However, while the TLD is the most significant tree-wise, it is probably not the most significant to the end-user, who is going to "news (in) ycombinator (in) com" instead of "com's ycombinator's news".

Post reply on HN