IIRC, the intent is that no one should be doing this and anyone doing it should be at least technical enough to figure out what they're doing and be reminded that it's a bad idea.

On the other hand these stupid dialog tricks are why I stopped using Chrome. I'm not an idiot and I know what I'm doing. It's pretty arrogant to assume that I shouldn't be visiting my router's configuration page just because it uses a self-signed certificate. I don't care to set up an X.509 infrastructure at my house, thank you. Please stop mollycoddling me.

Firefox continues to do a good job of just letting me visit the damn website after warning me.

I'm confused - Firefox and Chrome act completely identically to a self signed cert for me. Both let me click through after looking at the cert or expanding a section. I have never been "blocked" by some hidden modal unless the site chooses to be HSTS-enforcing, and in that case Firefox does not allow a clickthrough either.

Both examples on latest current, taken right now:

Firefox: https://i.imgur.com/4VMjDZ4.png

Chrome: https://i.imgur.com/YosvXEu.png

For HSTS, both Firefox and Chrome act identically and do not allow clickthrough: https://i.imgur.com/WPCTep1.png

Youre confused because you're not using Chrome on OSX: on osx there's no "Proceed to <website>" option.

I'm now even more confused: https://i.imgur.com/jl9agwG.png

You’re right to be confused because I’ve never seen a rhyme or reason to it either. I generated a cert using OpenSSL’s command line tools and told Django’s manage.py to use my self-generated cert and it works in Firefox but not Chrome.

It did work in Chrome. And then after an update it didn’t work anymore. I don’t know why and it seems like no one else here does either.

I was literally going to say that at one point that screen didn't look like that, and it appears it still doesn't but only sometimes.

Your router's self-signed cert can be imported into your browser and trusted from thereon — that will also stop any potential attacks from someone pretending to be your wifi ap nearby because I am pretty sure you are not double-checking the cert fingerprint every time you visit the router's admin interface. Provided you were not MITMed once you added the cert in the first place :)

At least Chrome lets you use that trick to bypass an hsts error message. Firefox won't let you.

And instead many people will just do a Google search for "Chrome [insert error here]" and run the first command they find, while people like me will say "okay I'll just Firefox where I can click past this warning".

For what it's worth I've always been able to click straight through a self-signed cert on Chrome - in fact I just did it right now to log in to something internal. I am a nearly 50-50 split Firefox/Chrome user.

Are you sure you aren't sending HSTS headers that demand the site be TLS in some way?

Also, have you considered the slightly-saner way of doing it, which is making an internal self-signed CA, trusting that internal CA, and then having it sign the rest of your "self dev stuff" certs?

If it was HSTS it wouldn't load in Firefox, would it?

If it was HSTS it would not load in both, with no button to bypass.

If it was not HSTS you can click through a non-obvious button in both.

Well Chrome has no button and Firefox has a button, so...

Yeah, I actually think these sorts of strategies are clever. They're a way to protect normal users without outright barring power users from doing as they wish.

macOS operates in a similar way. I really like how the difficulty increases depending on the task:

• Want to allow one app through Gatekeeper? Instead of double-clicking the app icon directly, right click it and select "open".

• Want to turn off Gatekeeper for all apps? You need to open the Terminal and execute a command.

• Want to turn off System Integrity Protection? You need to reboot your computer into recovery mode and execute a Terminal command there.

Except for those of us who are finding out about it only via a Hacker News comment. As happened with this user, who seems, you know, sufficiently a power user to need that info. Even a "if you know this site to be safe, please read this knowledge base article (link)" and buried in that, amidst all the reasons you shouldn't use untrusted certs, are the instructions.

> Even a "if you know this site to be safe, please read this knowledge base article (link)" and buried in that, amidst all the reasons you shouldn't use untrusted certs, are the instructions.

I don't think that's a bad way to go about it either, if it's sufficiently buried.

I'm primarily just thankful there's a workaround, hidden or not, given how many tech companies seem to respond to these things by disallowing them completely.

> I don't think that's a bad way to go about it either, if it's sufficiently buried.

Just put it in the manual. If experience has taught me anything, it's that "normal users" never read the manual.

If you keep up to date with commits on the chromium code repo, you'd see them change it from time to time. For a while it was 'youshallnotpass'.

You probably shouldn't be using an opensource project without at least a cursory glance at the code anyway, especially as a power user.

You're kidding right? You look at every commit of every open source app you use, or that a closed source app is built atop? For me, off the top of my head, that would mean, yes, Chrome, Firefox, the Linux Kernel, Libre Office, Android, VLC...probably plenty more that I am unaware are open source, and that's not even considering the dev tools to do my job. When would I actually have time to have a life?

Exactly. Reading the source of every program you used was certainly possible back in the 80's when the FOSS movement started; but nowadays, with every program being millions of lines of code, it's implausible to get through all that and still have time to actually use the software.

Not to mention background updating. I don't even know when Chrome has updated half the time, unless something stops working.

If you're on OSX/macOS (what a silly rebrand) then if you look in ~/Library/LaunchAgents (and possibly /Library/LaunchAgents and /Library/LaunchDaemons) for any .plist from Google (or Keystone) in there and add

    <key>Disabled</key><true/>

under the first <dict> and then unload each file, e.g.

    launchctl unload ~/Library/LaunchAgents/com.google.keystone.*

The auto-updating stops and stop them reloading after a reboot/logon.

Im not sure a cursory glance at the 25 millions lines of code will do much if you dont already know what to search.