Hacker News Reader

Comment by detaro | Hacker News Reader

What is "this"?

Likely they mean censorship via certificate revocation, which it isn't clear yet that this is, but they have a valid point. If you put control over your trust in a third party, you give them the power to do this kind of thing.

You can always manually trust certificates via various means, it's the basis for almost any corporate network, most browsers also offer a simply dialog to bypass certificate warnings.

You can also just use HTTP, since sci-hub doesn't force HTTPS.

Browsers seem to be moving towards making it harder to bypass, which is probably a good thing for the average user. I wouldn't be surprised to see the ability to ignore https errors (or access http sites at all) locked behind a developer setting or something.

On Chrome I can see that but I doubt Firefox would make that move.

Plus, they won't remove the functionality to manually trust a cert (Business Users would complain).

> On Chrome I can see that but I doubt Firefox would make that move.

Firefox has implemented the same rules around .dev tld's as google. I use vivaldi when accessing internal company .dev domains because firefox won't let me tell it to accept the self-signed certificate.

An option could be to use certificates signed by a self-signed CA added to your trust store.

That's exactly how it's set up. Doesn't help, I'm apparently not allowed to tell my browser what to do in this instance.

Firefox will happily accept self-signed certificates chaining to manually imported CAs. However, there are a lot of severely outdated guides on creating self-signed certificates out there, and many of the certificates produced that way won't be accepted by any modern browser. OpenSSL's terrible command-line UX certainly doesn't help matters. I've found easypki[1] to be the most convenient tool for this purpose.

[1]: https://github.com/google/easypki

The person you're replying to doesn't have any problem with certs. Their problem is that they (or their employer) hijack a TLD for whatever ludicrous reason, and HSTS pre-loading applies to their hijacked names the same as it would to real names.

Ah, got it.

Well, another argument in favor of not overloading TLDs for internal domains, then, and just buying an additional domain if you really want to have separate internal and external domains.

Are you sure? The initial post was about .dev being HSTS-preloaded, but the comment I was replying to was an answer to the suggestion that they could use self-signed certificates after importing them to the trust store.

Yeah, and having read over this thread about three times I'm actually less sure than I was. I'll be checking today.

IIRC that's because Mozilla sources their HSTS Preload List from Chromium

Chrome's already moving in this direction. Bypassing a HSTS error means you have to type "thisisunsafe", and they change the keyword sometimes (it used to be "badidea").

Firefox makes working around HSTS even harder. But to be fair, HSTS is the domain owner explicitly declaring "do require a valid certificate here!".

To disable HSTS permanently just do this: https://security.stackexchange.com/a/102315

As a user, it's hard to bypass, but as a developer, it is literally easier to "crack" the browser by patching the jump/value to always go to "cert is good" than try to find and make the corresponding changes in the source and then figure out how to recompile everything else identically. I'm not sure what to think of that...

Being wiped from the internet by a disagreeable CA authority. If that is what "this" is.

FWIW, onion addresses don't require a cert, they are end-to-end encrypted by design.

Technically, nothing requires a cert. It's just best practice to have one.

That is not what "this" is.

The grandparent comment is right. I am not going to mess with default browser settings, and almost nobody is.

http://sci-hub.tw/ is reachable no problem. Cut down on the hyperbole please.

Reply on news.ycombinator.com