You're not the only one. I hypothesised about this before in previous SciHub discussions, and SciHub isn't the only site that is/will be affected. Security is the ostensible benefit, and it's the one they advertise the most; easier censorship and centralised access control is the other---something which a lot of the pro-(traditional)-HTTPS advocates don't advertise. Make HTTPS mandatory (so no more HTTP), make it near impossible to bypass in browsers, and you have created a very effective censorship system controlled by the CAs and whatever interests they serve.

Slowly ostracising and forcing "compliance" of those who don't toe the line is easier than before. They want you to be obedient sheep, living in an illusion of security and safety while continuing to mindlessly consume under their control.

I will resist the urge to post that memorable Franklin quote.

Let's not pretend the real reason google isn't so gung-ho about https everywhere is to prevent the ISPs from muscling into their businesses:

* ads on page

* seeing all internet traffic to enhance targeting

You make it sound like this is a bad thing. Regardless of if it also benefits Google's business model, both of these things benefit users and website owners. The only thing that benefits from injecting ads into a page or deeper ISP tracking is some ISP executive's bonus.

Challenge: Next person that downvotes me, also leave a comment explaining why.

But then you have the other issue of your ISP having the ability to meddle with what it's sending you and silently injecting or removing content from the page. Really, I don't see a great solution either way.

This reads like a conspiracy theory. Who are the pro HTTPS everywhere people that are _also_ secretly trying to further censorship? This would have to be a fairly vast conspiracy, but, you don't provide any evidence.

It's a simple fact. It doesn't need to be planned or conspirated. The fact that root CAs are at the top, modulo self signed certs exchanged person to person IRL, is certainly no secret. The conspiracy would be that they might use the fact to censor or listen, whoever they are. The conspiracy would be not to tell anyone beforehand, because otherwise it wouldn't be a conspiracy anymore. What kind of exhaustive evidence do you expect for the claim that they are not saying something? And maybe you are right, this is extremely hypothetical, they would never take action to invalidate certs... Hey, wait a second!!!

The real conspiracy would be to know a better system and not tell anyone. Which is like sponsoring scientific discoveries and then hiding those behind a pay wall. Oh wait again.

Who are "they"? Google? Mozilla? Microsoft? Apple? The 100s of CAs? And, are they all working together? And there hasn't been a single whistleblower to expose this?

What do you mean "listen"? CAs can invalidate certs at will, but, they have no mechanism to listen on communications (unless you give them your private key, but, then anyone you give your private key to can eavesdrop).

The CA system has lots of issues. It would be a pretty big conspiracy if there were thousands of people that knew of something better and said nothing. But, there is absolutely no proof that anyone has any idea how to do better than the CA system. Do you know of such a system or have any evidence that someone else does? Google, despite their flaws w.r.t. privacy, has done quite a bit of work to improve the CA situation - Certificate Transparency, for example.

> Who are "they"?

A court seizing a domain thereby invalidating a cert.

> What do you mean "listen"?

If I accept a custom cert, but don't validate the key, I might as well use none, basically. That's the extent of my knowledge, I don't know what Certificate Transparency is doing, for example.

> The CA system has lots of issues. It would be a pretty big conspiracy if there were thousands of people that knew of something better and said nothing. But, there is absolutely no proof that anyone has any idea how to do better than the CA system. Do you know of such a system or have any evidence that someone else does?

> It would be a pretty big conspiracy

Exactly, so why do you expect that twitter sized post could it explain it convincingly?

> if there were thousands of people that knew of something better and said nothing

Ironically, it might be the ability to censor communication to suppress such voices, however hypothetical that is, that triggered the GP.

> But, there is absolutely no proof that anyone has any idea how to do better than the CA system.

PGP is used with key exchange in real live. I'm not using it, just arguing for the sake of the argument. It has problems, too, but "better" is not a binary value , except in the limited scope of the specific problem. PGP doesn't need root CAs.

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.

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.

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

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

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.

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.

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.

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

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

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

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

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.

How exactly do you see Google doing anything here, outside of a general "they encourage HTTPS" (but the site still works fine over HTTP)?