Opened 3 years ago

Last modified 5 weeks ago

#13410 reopened defect

Disable self-signed certificate warnings when visiting .onion sites

Reported by: tom Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team
Cc: platypus, guido@…, mrphs, yawning, fdsfgs@…, asn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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?

Child Tickets

Change History (20)

comment:1 Changed 3 years ago by vynX

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.

Last edited 3 years ago by vynX (previous) (diff)

comment:2 Changed 3 years ago by yawning

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

comment:3 Changed 3 years ago by vynX

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.

comment:4 Changed 23 months ago by platypus

Cc: platypus added
Severity: Normal

comment:5 Changed 6 months ago by cypherpunks

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.

Last edited 6 months ago by cypherpunks (previous) (diff)

comment:6 Changed 6 months ago by arma

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

comment:8 Changed 6 months ago by guido

Cc: guido@… added

comment:9 Changed 6 months ago by mrphs

Cc: mrphs added
Keywords: #ux-team added

comment:10 Changed 5 months ago by cypherpunks

Priority: MediumVery High

comment:11 Changed 5 months ago by cypherpunks

.onion is secure.

connection tranport is secure

HTTPS is secure!!!!!!!!!!!!!!!!!

comment:12 Changed 5 months ago by cypherpunks

Tor Browser
Orfox

Come on people. Just ignore HTTPS warning already.

comment:13 Changed 4 months ago by linda

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

comment:14 Changed 4 months ago by linda

Resolution: fixed
Status: newclosed

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

comment:15 Changed 4 months ago by cypherpunks

Keywords: ux-team added; #ux-team removed
Resolution: fixed
Status: closedreopened

comment:16 in reply to:  13 Changed 4 months ago by yawning

Cc: yawning added

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.

comment:17 Changed 4 months ago by linda

yawning: that sounds reasonable!

comment:18 Changed 2 months ago by tokotoko

Cc: fdsfgs@… added

comment:19 Changed 5 weeks ago by asn

Cc: asn added

comment:20 Changed 5 weeks ago by pastly

If people want certificates for their onion services, they should go through the process of getting a valid one. Hopefully someday there will be an easy way to do so like Let's Encrypt. Until then, by removing the warning we're appeasing the users in this ticket but potentially hurting many more.

Assumption: effectively no one checks the certificates they are served, even if they are self-signed.

Scenario 1: the connection is MiTM'ed somehow (there's a bad guy between the user and his Tor process or there's a bad guy between the web server and the webmaster's Tor process). The bad guy can replace the cert without detection because either (1) the onion service was using a self-signed cert and no one checks that they continue to get the same self-signed cert, or (2) because the browser has disabled cert errors. BAD.

Scenario 2: the onion service has a valid cert, but the connection is MiTM'ed somehow. Again, the bad guy can replace the cert without detection. BAD. With current behavior, there's at least a chance that the user will realize something is wrong and do something about it.

Replying to vynX

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

No, let's keep the legacy crap security assumptions so that users know their transport layer has been confirmed secure by a chain of trust. Tor secures between Tor processes. TLS secures between browser and web server. Let's not lie to users about the latter.

Yes: boooooo CAs suck. Down with the system. Etc. Etc. But this is silly. What is more intelligent is encouraging users and onion service operators to run Tor as close as possible to the end software (AKA "just use Tor Browser" to users and "run Tor on the same machine as the webserver in most cases, or on a very secure access-controlled network if you're a big corporate machine" to onion service operators).

Replying to tom

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

I suspect users don't type either one.

Note: See TracTickets for help on using tickets.