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 in Legacy / Trac actualpoints::7 in Legacy / Trac component::applications/tor browser in Legacy / Trac owner::pospeselr in Legacy / Trac parent::33827 in Legacy / Trac priority::very high in Legacy / Trac severity::normal in Legacy / Trac sponsor::27 in Legacy / Trac status::needs-information in Legacy / Trac type::defect in Legacy / Trac ux-team in Legacy / Trac 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: legacy/trac#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

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 [comment:1 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 [ticket:13410 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.

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

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.

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

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

Resolved legacy/trac#29163 (moved) as a duplicate.

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

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

Trac:
Username: watt

Trac:
Sponsor: N/A to Sponsor27

Add Sponsor27-must items for Objective 2

Trac:
Sponsor: Sponsor27 to Sponsor27-must

Trac:
Parent: N/A to legacy/trac#30025 (moved)

Closed legacy/trac#30108 (moved) as duplicate.

Trac:
Status: reopened to assigned
Owner: tbb-team to pospeselr

Trac:
Cc: platypus, guido@dis.tur.bio, mrphs, fdsfgs@krutt.org, asn, welkins to platypus, guido@dis.tur.bio, mrphs, fdsfgs@krutt.org, asn, welkins, tbb-team

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 legacy/trac#33298 (moved)

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

Trac:
Status: assigned to needs_review
Keywords: N/A deleted, TorBrowserTeam202002R added

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

Filed a ticket requesting review: https://bugzilla.mozilla.org/show_bug.cgi?id=1618382

comment:16

comment:26

Trac:
Actualpoints: N/A to 7

We are no longer in February moving reviews

Trac:
Keywords: TorBrowserTeam202002R deleted, TorBrowserTeam202003R added

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

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

Trac:
Status: needs_review to needs_information

We are no longer in March

Trac:
Keywords: N/A deleted, TorBrowserTeam202004 added

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.

Trac:
Parent: legacy/trac#30025 (moved) to legacy/trac#33827 (moved)
Keywords: N/A deleted, TorBrowserTeam202008 added

Trac:
Sponsor: Sponsor27-must to Sponsor27

Trac:
Keywords: TorBrowserTeam202003R, TorBrowserTeam202004 deleted, N/A added

added 56h of time spent

mentioned in issue legacy/trac#22792 (moved)

mentioned in issue legacy/trac#22935 (closed)

mentioned in issue legacy/trac#27636 (moved)