Disable self-signed certificate warnings when visiting .onion sites

I suspect it's fairly common (or at least, we hope it's common) for users to type https:// instead of http://.

If an onion site doesn't support HTTPS, the user gets an error page because it can't connect. If it does, the user gets an invalid certificate or mismatched certificate warning. CAs do not (yet?) issue certificates for .onion domains, so there are no valid certificates.

But the security of the .onion URL ensures we're talking to the valid so, so ignoring SSL mis-configurations should be safe, as we already have authenticity, integrity, and confidentiality. Right? Or am I missing something?

added TorBrowserTeam202008 actualpoints::7 component::applications/tor browser owner::pospeselr parent::33827 priority::very high severity::normal sponsor::27 status::needs-information type::defect ux-team labels

Yes, I was about to open the same feature enhancement request. The addresses of hidden services are a much stronger guarantee of authenticity than any damn certificate. It is completely irrelevant which certificate the website is offering and in fact it apparently takes special bribing to have a valid cert issued for an .onion although there is no reason for that. CAs could give out onion certs with zero checks since only the owner of the private key can make any use of it.

Please make use of the technological advantages of Tor. Don't let legacy crap impede us from fully enjoying end-to-end TLS (which is relevant when your Tor router isn't the same machine as your Tor browser). In fact all browser vendors should suppress certificate checks for .onion. It is a perverse disregard of the nature of Tor to expect it to comply with X.509.

Trac:
Username: vynX

CAs do not (yet?) issue certificates for .onion domains, so there are no valid certificates.

They do now. As much as I have deep seated hatred for the CA mafia, closely matched by my burning hatred for spacebook and bitcoin (which IIRC are the 2 places that do have CA certs for .onions currently), something like this seems dangerous because without careful design it would allow me to throw an obnoxious amount of CUDA at getting "facebookcorewwii.onion", creating a self-signed cert, and mounting a fishing attack on user credentials.

(Yes, I am aware that I shouldn't click on the bad, and if I pay the CA people enough I can probably get a CA cert for my site of evil anyway, but implementing this lowers the bar for entry considerably).

Browsers must not attempt to resolve .onion via DNS. If that is a given, then MITM attempts using DNS + fake .onion certificates while there is no Tor onion involved at all are incapable of succeeding. So the work to be done is to get all browser vendors to implement .onion in a failsafe way. I believe @ioerror's and @grothoff's IETF drafts for .onion TLD mention that... it's also important that .onion isn't the only pseudo-TLD that gets excluded from the X.509 monstrosity since we don't want to get stuck on .onion for all times.

Trac:
Username: vynX

Trac:
Username: platypus
Cc: N/A to platypus
Sponsor: N/A to N/A
Severity: N/A to Normal

Before TBB 7.0, user can bypass this check by installing "SkipCertError" addon. Now it is not possible.

I want TBB to say "secure" when I visit HTTPS on .onion websites.

"Connection is not secure" is just wrong.

Trac:
Reviewer: N/A to N/A

See also https://blog.torproject.org/comment/268891#comment-268891 where a user (maybe the same user) has the same problem.

related https://trac.torproject.org/projects/tor/ticket/21767

Trac:
Username: guido
Cc: platypus to platypus, guido@dis.tur.bio

Trac:
Keywords: N/A deleted, #ux-team added
Cc: platypus, guido@dis.tur.bio to platypus, guido@dis.tur.bio, mrphs

https://trac.torproject.org/projects/tor/ticket/22935

Trac:
Priority: Medium to Very High

.onion is secure. == connection tranport is secure == HTTPS is secure!!!!!!!!!!!!!!!!!

Tor Browser Orfox

Come on people. Just ignore HTTPS warning already.

After triaging, the ux team agrees that this warning should be removed.

It turns out this is being addressed already, see: #21321 (moved)

Trac:
Status: new to closed
Resolution: N/A to fixed

No. See https://j6uhdvbhz74oefxf.onion/

Trac:
Keywords: #ux-team deleted, ux-team added
Status: closed to reopened
Resolution: fixed to N/A

Replying to linda:

After triaging, the ux team agrees that this warning should be removed.

In the event that the warning is removed, the sandboxing team, requests that the removal be feature gated via a pref, so the new behavior can be disabled.

Trac:
Cc: platypus, guido@dis.tur.bio, mrphs to platypus, guido@dis.tur.bio, mrphs, yawning

yawning: that sounds reasonable!

Trac:
Username: tokotoko
Cc: platypus, guido@dis.tur.bio, mrphs, yawning to platypus, guido@dis.tur.bio, mrphs, yawning, fdsfgs@krutt.org

Trac:
Cc: platypus, guido@dis.tur.bio, mrphs, yawning, fdsfgs@krutt.org to platypus, guido@dis.tur.bio, mrphs, yawning, fdsfgs@krutt.org, asn