Hacker News Reader

Comment by kstrauser | Hacker News Reader

Fine, as long as they don't eventually make it difficult or impossible to ignore the warnings (as they've done with SSL sites with invalid certs). I have numerous devices with web interfaces that are 100% internal to my network and not reachable from the open Internet, but Chrome still refuses to let me access them (side note: thanks, Firefox, for respecting my decision as a user!). I can envision a near future where Chrome treats HTTP sites the same way.

View on HN

You can still visit websites that have an invalid CA or invalid certificate DNS match, but if the website is set up for HSTS/HSTS preload then chrome respects the website's decision to not allow insecure connections.

I was accessing an internal router with firmware from the distance past of 2011. Note that this is an internal-only router that connects a couple of trusted subnets, so security isn't an issue and there's no requirement to replace it yet. The problem that bit me yesterday was that I literally could not find a way to get Chrome to open https://ro.ut.er.ip/ because the router's ancient cert is invalid.

I would have been perfectly fine with Chrome alerting me to that fact and providing a "click here to continue anyway" link, but that seems to no longer be an option. FWIW, Safari did the exact same thing. Only Firefox gave me the "I promise that's really what I want to do step aside plz" button I needed.

Pro-tip: On Chrome's certificate error page, you can type "badidea" (or "thisisunsafe" in 66 or later) to force it to let you through.

I hope you’re joking...? An interface that forbids you from working unless you know an easter-egg/“insider” password is almost a fascist concept. I guess that’s another reason not to use Chrome...

For HSTS, it’s based on the spec. There’s not supposed to be a user-accessible override for HSTS errors, which is why Chrome hides it behind that easter egg. Firefox has no override of any kind.

It's just a shortcut to avoid clicking on two buttons.

No it isn't, for certain certificate errors this is the only way.

That freaking worked?! Thank you so much for this!

Yeah, it's annoying having to older versions. However there's good reason they disabled the ability via a config or launch parameter. Many organisations were not making upgrades to internal systems and websites as they could allow their browsers to bypass validation.

Still sucks for consumer grade stuff. I'm surprised your router offers SSL at all though.

>Many organisations were not making upgrades to internal systems and websites as they could allow their browsers to bypass validation.

That's like shutting down all roads because some drivers break the speed limit. If Google isn't taking collateral damage into their decisions that impact everyone, they need to stop controlling the web.

The old dirt roads we used with horse and buggies are still there.

I had this problem with a firewall (sonicwall) and I ended up SSHing into the firewall and then allowing regular http traffic (because literally none of the browsers on my computer: ie11, firefox, or chrome would load it.)

The problem is when Google goes and throws a commonly used internal-only TLD like .dev in their HSTS list. And of course, the whole problem that HSTS is the hosts file all over again.

That being said, the real fault in that incident is ICANN selling .dev in the first place. They should've been well aware of it's common use, and opted not to sell it.

I have a theory that ICANN did this too tell developers to use designated domains for internal uses.

I think you're putting too much thought into it. It's very simple: .dev is a massively easy to monetize TLD, it was guaranteed to get multiple companies trying to buy it, and when they had multiple offers, they got auctioned.

I think .dev was just too much money for ICANN to say no.

Of course, it looks like ICANN may have gotten screwed, because Amazon and Google appear to have privately arranged to figure out who was going for which TLDs: https://icannwiki.org/.dev

Can you self-sign a certificate from the internal server and install it as trusted on the work computers? Or does Chrome only trust certificates that Google trusts?

Generally speaking, Chrome uses whatever is in the OS trust store, with certain exceptions for CAs that have been naughty (e.g. StartCom, WoSign, Symantec) or subCAs that were revoked via CRLSets. Private CAs present in the OS trust store will generally just work, the only exceptions being things like Superfish.

Not sure about Chrome, but you can absolutely install a local CA into Firefox.

You definitely can in Chrome. Tons of corporations need the ability to trust their internal PKI.

You can install your own CA, yes. But's it's easier to just use HTTP.

Reply on news.ycombinator.com