When I visit a V3 onion that supplies a invalid certificate, torbrowser will lookup the onion when the get certifice button is clicked

When I visit a V3 onion that supplies a invalid certificate, torbrowser will lookup the onion when the get certifice button is clicked. This may leak the secret onion address. I attached a photo showing the issue.

Trac:
Username: Dbryrtfbcbhgf

added component::applications/tor browser owner::tbb-team priority::high reporter::Dbryrtfbcbhgf severity::major sponsor::27-can status::new type::defect labels

Trac:
Username: Dbryrtfbcbhgf

Trac:
Username: Dbryrtfbcbhgf

Trac:
Username: Dbryrtfbcbhgf
Priority: Medium to High
Severity: Normal to Major

You guys need to add an exception to all FQDN which ends with ".onion".

.onion$

That's because if you code "V2 and V3 only .onion", you might need to update the code again when Tor-V4, TorDNS starts in the future.

related for "insecure onion" BS: https://trac.torproject.org/projects/tor/ticket/13410

Replying to cypherpunks:

You guys need to add an exception to all FQDN which ends with ".onion".

.onion$

That's because if you code "V2 and V3 only .onion", you might need to update the code again when Tor-V4, TorDNS starts in the future.

But that means that onions won't be able to revoke SSL certs anymore. Since we consider SSL certs something that onions might need (and in the case of your onion, it's even trying to use it), we should probably also support its various functionalities, including revocation?

Alternatively, we could add a scary message saying that the onion will get leaked, but I doubt most users understand the trade offs here...

Trac:
Cc: N/A to asn

In general, if you are an onion operator and you want your onion address to be secret, you shouldn't configure SSL with an OCSP provider. Does self-signed certs use OCSP?

I think handling this on the onion side and not on the client-side makes sense here.

After talking with ahf a bit I think we can do something smarter. We could require OCSP-must-stapling for .onions and otherwise just prevent it. Firefox is supporting it since ESR 45 at least:

https://blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-must-staple-and-short-lived-certificates/ https://tools.ietf.org/html/rfc7633

Dbryrtfbcbhgf: The button is not necessarily the issue. The OCSP request goes as already out when you are requesting the domain.

See: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/ for some info about what OCSP stapling achieves.

For the server-side state of the art see: https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html

https://bugzilla.mozilla.org/show_bug.cgi?id=901698 is the bug where OCSP-must-stable got implemented.

Will we lose any security by only supporting OCSP-must-staple and ditching normal OCSP requests?

Replying to gk:

See: https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/ for some info about what OCSP stapling achieves. When the button is pressed, will Tor browser leak the onion address to some server? I’m referring to the button shown in the photo issue.png

Trac:
Username: Dbryrtfbcbhgf

Trac:
Sponsor: N/A to Sponsor27

Adjusting sponsor tag.

Trac:
Sponsor: Sponsor27 to Sponsor27-can

moved to tpo/applications/tor-browser#24192