Opened 6 years ago

Last modified 2 months ago

#13410 needs_information defect

Disable self-signed certificate warnings when visiting .onion sites

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

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 (45)

comment:1 Changed 5 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 5 years ago by vynX (previous) (diff)

comment:2 Changed 5 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 5 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 4 years ago by platypus

Cc: platypus added
Severity: Normal

comment:5 Changed 3 years 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 3 years ago by cypherpunks (previous) (diff)

comment:6 Changed 3 years 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 3 years ago by guido

Cc: guido@… added

comment:9 Changed 3 years ago by mrphs

Cc: mrphs added
Keywords: #ux-team added

comment:10 Changed 3 years ago by cypherpunks

Priority: MediumVery High

comment:11 Changed 3 years ago by cypherpunks

.onion is secure.

connection tranport is secure

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

comment:12 Changed 3 years ago by cypherpunks

Tor Browser
Orfox

Come on people. Just ignore HTTPS warning already.

comment:13 Changed 3 years ago by linda

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

comment:14 Changed 3 years ago by linda

Resolution: fixed
Status: newclosed

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

comment:15 Changed 3 years ago by cypherpunks

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

comment:16 in reply to:  13 Changed 3 years 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 3 years ago by linda

yawning: that sounds reasonable!

comment:18 Changed 3 years ago by tokotoko

Cc: fdsfgs@… added

comment:19 Changed 3 years ago by asn

Cc: asn added

comment:20 Changed 3 years 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.

comment:21 Changed 2 years ago by cypherpunks

Come on. You implemented "onion mixed content".

Why not allow people to activate|deactivate "Ignore HTTPS onion certificate"?
I really need it and I always had to see yellow security warning screen but hey, it's my onion!

HTTP onion = ok
HTTPS onion + AltMatch + DateNotExpired = MUST_PASS
HTTPS onion + Alt Mismatch = ERROR (show security warn)
HTTPS onion + Date Expired = ERROR

comment:22 Changed 2 years ago by cypherpunks

I spotted some V3 onions are using wildcard self-sign domain to sign their onions.

https://yawning.torv3onionnamehere.onion/
signed by: "*.torv3onionnamehere.onion"

Because OpenSSL can't sign "yawning.torv3onionnamehere.onion" due to its maximum character length.

comment:23 Changed 2 years ago by cypherpunks

@pastly

Your argument is not valid at all, because you're saying onion is MITMed somehow.
.onion is secure. If it's not secure, then why the Tor Project ignore mixed content for .onions?

If HTTP .onion is not secure, you should verify each connection.
HTTP .onion is secure >> then >> HTTPS .onion shall be secured because cert data is transported via HTTP channel.

comment:24 Changed 2 years ago by yawning

Cc: yawning removed

comment:25 Changed 17 months ago by gk

Cc: welkins added

Resolved #29163 as a duplicate.

comment:26 Changed 17 months ago by watt

Bring back the normal padlock icon for added exceptions! Now it's green as for valid certificates, which is nonsense!
(And, really, add a dumb "I'm a stupid noob that wants no warns on https onions" checkbox to the cert error page.)

comment:27 Changed 15 months ago by pili

Sponsor: Sponsor27

comment:28 Changed 14 months ago by gk

Sponsor: Sponsor27Sponsor27-must

Add Sponsor27-must items for Objective 2

comment:29 Changed 14 months ago by pili

Parent ID: #30025

comment:30 Changed 14 months ago by gk

Closed #30108 as duplicate.

comment:31 Changed 4 months ago by pili

Owner: changed from tbb-team to pospeselr
Status: reopenedassigned

comment:32 Changed 4 months ago by boklm

Cc: tbb-team added

comment:33 Changed 3 months ago by pospeselr

Keywords: TorBrowserTeam202002R added
Status: assignedneeds_review

A surprisingly small patch seems to work for the scenarios we care about, and does nothing to the existing vanilla HTTPS website handling.

Scenarios tested:

Scenario Name Result
HTTP Onion Onion Icon
HTTPS Onion Self-Signed Onion Icon
HTTPS Onion Unknown CA Onion Icon
HTTPS Onion EV Onion Icon + EV Name
HTTPS Onion Wrong Domain Onion Warning Icon, Warning Splash Screen
HTTPS Onion Expired Self-Signed Cert Onion Warning Icon, Warning Splash Screen
HTTP(S) Onion + HTTP Script Onion Slash Icon
HTTP(S) Onion + HTTP Content Onion Warning Icon
HTTP(S) Onion + HTTPS Content Onion Icon
HTTPS Onion + HTTP Form Onion Ion + Warning Popup on Form Submit

HTTP Onion + HTTP Form does not give the warning popup and is tracked to be fixed in #33298

tor-browser: https://gitweb.torproject.org/user/richard/tor-browser.git/commit/?h=bug_13410_v1

comment:34 Changed 3 months ago by tom

I would be inclined to but this up on bugzilla and ask dkeeler for review....

comment:35 Changed 3 months ago by pospeselr

comment:36 Changed 3 months ago by cypherpunks

comment:37 Changed 3 months ago by cypherpunks

comment:38 Changed 3 months ago by pospeselr

Actual Points: 7

comment:39 Changed 3 months ago by pili

Keywords: TorBrowserTeam202003R added; TorBrowserTeam202002R removed

We are no longer in February moving reviews

comment:40 Changed 3 months ago by pospeselr

So I took some time today and yesterday to investigate what it would take to implement alecmuffet's SOOC spec (which is basically a superset of the posted patch with additional limitations). It actually wouldn't be too terribly tricky to do and this is the general plan I'd follow to do so:

implement a new OnionTrustDomain that implements 1.1 through 1.6 in the SOOC spec

  • OnionTrustDomain : public NSSCertDBTrustDomain {}
  • override GetCertTrust and have the implementation first call NSSCertDBTrustDomain::GetCertTrust(), and only on Success override the trustLevel to TrustLevel::Anchor (some cert revocation checks happen here by default which I think we should *probably* keep)
  • override IsChainValid and have implementation first call NSSCertDBTrustDomain::IsChainValid(), and only on Success perform the additional checks on our cert listed in the SOOC spec

in CertVerifier::VerifyCert(), use the new OnionTrustDomain in a branch within the case certificateUsageSSLServer: block when hostname is an onion.

SOOC spec: https://github.com/alecmuffett/onion-dv-certificate-proposal/blob/master/text/draft-muffett-same-origin-onion-certificates.txt
Some previous discussion alecmuffet has had with Mozilla devs: https://docs.google.com/document/d/1xE5eaDMiOKphDxijK9tfIWHUB-h-fTG8tb3laofXLSc/edit#

Overall the new patch should be straight forward, with the bulk of the new checks living in OnionTrustDomain::IsChainValid().

Last edited 3 months ago by pospeselr (previous) (diff)

comment:41 Changed 3 months ago by sysrqb

Status: needs_reviewneeds_information

We should discuss this and make sure we implement the functionality we actually want.

comment:42 Changed 2 months ago by pili

Keywords: TorBrowserTeam202004 added

We are no longer in March

comment:43 Changed 2 months ago by pili

Keywords: TorBrowserTeam202008 added
Parent ID: #30025#33827

This will no longer be done as part of S27 O2A4.

Moving all onion service certificate related tickets to a new project to be implemented in future.

comment:44 Changed 2 months ago by pili

Sponsor: Sponsor27-mustSponsor27

comment:45 Changed 2 months ago by pili

Keywords: TorBrowserTeam202003R TorBrowserTeam202004 removed
Note: See TracTickets for help on using tickets.