Live data from Hacker News

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

blog.chromium.org

351–360 of 463 posts

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

#351
post #332

Earlier quoted context omitted.

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.

This is not true, you can set your host to trust a self signed certificate without much difficulty. Check out this tool for example https://github.com/FiloSottile/mkcert (prev discussion at https://news.ycombinator.com/item?id=17748208 )

Self signing doesn’t let the world access my website without some scary warning.

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

#352
post #336

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 )

Thanks!

Edit: strange that this change is not listed on that page.

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

#353
post #332
post #294

Earlier quoted context omitted.

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.

Letsencrypt provide a really good service.

I can recommend the docker image made by linuxserver in particular [0]. Makes Https a (tax free) breeze.

[0] https://docs.linuxserver.io/general/swag

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

#354
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 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. Don't use the browser? I understand the temptation to use the browser, but this is the price you pay for using someone else's platform: They're free to close whatever door they want. HTML renderers are dime a dozen. Electron is a thin…

Telling users that, in order to connect their new router to the internet they must first download your native app from the internet... sounds like a non-ideal design?

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

#355

Earlier quoted context omitted.

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 f…

I would be substantially surprised if 10% of people had logged into a router EVER and even those folks spend 99.999% of their time on actual websites.

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

#356
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 wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN

There almost is! Instead of self signed certificates, use a certificate authority, and install that on the LAN's machines. https://github.com/devilbox/cert-gen

You can use macOS Server or Active Directory to push out the Certificate as trusted.

It's not perfect, but it's close enough for a LAN.

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

#357

Earlier quoted context omitted.

Repeat every 3 months or whenever the root certs expire.

Why would the certs you create for this purpose be made to expire?

It needs to expire before 397 days, because otherwise the CA will not be valid, even if it is marked as trusted. https://www.zdnet.com/article/google-wants-to-reduce-lifespa...

edit: a word

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

#358
post #136
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…

I wonder if a scheme could be invented where your router could be responsible for issuing certs to local devices. Forgetting about the impossibilities of industry adoption, would such a scheme be possible?

E.g. your router/DHCP controller/AD box gives an IoT device a DHCP ip and maybe a DNS address, and additionally it will provision a cert+key to that device by some standard protocol (keeping this secure might be impossible?). Router has an internal CA cert+key to do this.

Your PC then (handwavy) "knows" to retrieve the CA cert of your router by some standard protocol (dhcp extension?), and "knows" to trust it for devices on the router's subnet.

Is a scheme like this possible?

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

#359
Regarding the complaints about IOT devices and LAN local services: I wonder if it would be possible, and reasonable, to define some sort of LAN certificate authority protocol, which behaves a bit like Let's Encrypt, but only for services that are on LAN local subnets.

Normally, something like your WiFi router would fulfil this role, local services would poll it to obtain signed certs, and, browsers would poll it for a CA cert which they would apply as a trust root for LAN local subnets only.

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

#360

what about http://neverssl.com/ ? I use that all the time to force a wifi connect dialog to pop up.

Looks like it'll still work:

> For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails (including when there are certificate errors, such as name mismatch or untrusted self-signed certificate, or connection errors, such as DNS resolution failure).

The name mismatch is the key point for those captive wifi portals that respond on HTTPS with an invalid certificate.

Post reply on HN