UX improvement: Tor Browser should handle bogus HSv3 addresses

HS v3 addresses are big but also contain a checksum. This means that Tor Browser could catch mistyped addresses and warn the user.

With current master and current Tor browser, if you mistype an hsv3 address you go to the Unable to connect page:

Unable to connect

Firefox can’t establish a connection to the server at 4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqeflock.onion.

    The site could be temporarily unavailable or too busy. Try again in a few moments.
    If you are unable to load any pages, check your computer’s network connection.
    If your computer or network is protected by a firewall or proxy, make sure that Tor Browser is permitted to access the Web.

In the logs you can see a parsing error:

[warn] Invalid onion hostname [scrubbed]; rejecting

which is a bit generic.

I wonder what's the best way to offer better UX here. How should the user be warned?

Also how should we implement this? Should the Browser do the checksum check itself? Or should Tor do the checksum check and inform Tor Browser somehow?

How to do this best?

changed milestone to %Tor: unspecified

added 034-removed-20180328 034-triage-20180328 TorBrowserTeam202004 component::applications/tor browser milestone::Tor: unspecified owner::brade parent::30022 points::1 priority::medium prop224 resolution::fixed severity::normal sponsor::27-must status::closed tor-hs type::defect ux-team labels

Trac:
Keywords: ux deleted, ux-team added

Redundant: tbb-team is already the owner.

Trac:
Keywords: tor-browser deleted, N/A added

I think tor doing the checksum check and informing the browser seems to be a good way as I can imagine other applications might want that feature as well. I can imagine that we patch the browser part showing some custom error page or amending the one currently shown.

Trac:
Cc: linda, geko, arthuredelstein to linda, gk, arthuredelstein

Trac:
Cc: linda, gk, arthuredelstein to linda, gk, arthuredelstein, brade, mcs

Replying to gk:

I think tor doing the checksum check and informing the browser seems to be a good way as I can imagine other applications might want that feature as well. I can imagine that we patch the browser part showing some custom error page or amending the one currently shown.

+1, I think that showing a custom error page for .onion sites would be a good option.

Trac:
Cc: linda, gk, arthuredelstein, brade, mcs to antonela, linda, gk, arthuredelstein, brade, mcs

deferring to 0.3.4 on Tor's; this will need feature design. TB folks -- how should Tor tell you about this? With HTTP CONNECT tunneling it would be trivial, but for SOCKS we are pretty limited.

Trac:
Milestone: Tor: 0.3.3.x-final to Tor: 0.3.4.x-final

Replying to nickm:

deferring to 0.3.4 on Tor's; this will need feature design. TB folks -- how should Tor tell you about this? With HTTP CONNECT tunneling it would be trivial, but for SOCKS we are pretty limited.

What options could you think of (not sure what "limited" means here)?

Trac:
Keywords: N/A deleted, 034-triage-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

Trac:
Keywords: N/A deleted, 034-removed-20180328 added

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Trac:
Milestone: Tor: 0.3.4.x-final to Tor: unspecified

Trac:
Cc: antonela, linda, gk, arthuredelstein, brade, mcs to antonela, linda, gk, arthuredelstein, brade, mcs, dmr
Keywords: N/A deleted, tor-hs added

Trac:
Sponsor: N/A to Sponsor27

Add Sponsor27-must items for Objective 2

Trac:
Sponsor: Sponsor27 to Sponsor27-must

Trac:
Parent: N/A to #30022 (moved)

On UI/UX land, we should follow the excellent work did by Firefox folks here. We should check if those updates are available on ESR.

https://blog.mozilla.org/ux/2019/03/designing-better-security-warnings/

We talked with GeKo and nickm today about this. The Right Way to do this is to use the HTTPTunneLPort option which provides an HTTP CONNECT proxy, which is more extensible than the SOCKS proxy we are currently using when it comes to errors etc.

Unfortunately, currently TB does not use the HTTP CONNECT proxy, so we would need to do some tinkering especially when it comes to first-party isolation etc. Supposedly the little-t-tor side supports first-party isolation using the X-Tor-Stream-Isolation header or the Proxy-Authorization header, but it's been widely untested.

Furthermore we would need to start a spec file (maybe on the tbb side) defining the new error codes that we would use for this deliverable and also for o2a4.

Trac:
Points: N/A to network-team: 5-10

Replying to asn:

Unfortunately, currently TB does not use the HTTP CONNECT proxy, so we would need to do some tinkering especially when it comes to first-party isolation etc. Supposedly the little-t-tor side supports first-party isolation using the X-Tor-Stream-Isolation header or the Proxy-Authorization header, but it's been widely untested.

I think this should generally just-work, as long as firefox implements HTTP CONNECT correctly without leaking DNS queries. (I've used HTTP Connect with other applications without any noticeable problems, personally). I also found in my inbox a new draft RFC for standardizing an HTTP response header from a proxy, some of them seem nearly appropriate for this use case (Destination IP Unroutable?). Maybe we can take this opportunity and get a more general error status added for our use case now, instead.

One other thought I had was tor can emit a controller event with information about a malformed onion address, too. This may be a way for providing error handling for applications using SOCKS, too. It'll be asynchronous, so the application/controller will need to correlate the request with the controller event.

Ticket #32546 (moved) has been merged to little-t-tor so the TB team is now ready to work on this.

Added points estimate (assumes reuse of error page framework that is being developed for #19251 (moved)).

Trac:
Points: network-team: 5-10 to 1

Trac:
Cc: antonela, linda, gk, arthuredelstein, brade, mcs, dmr to tbb-team, antonela, linda, gk, arthuredelstein, brade, mcs, dmr
Owner: tbb-team to brade
Status: new to assigned

Trac:
Keywords: N/A deleted, TorBrowserTeam202002 added

We are no longer in February, moving tickets

Trac:
Keywords: TorBrowserTeam202002 deleted, TorBrowserTeam202003 added

See ticket:19251#comment:38 for patches that also address this ticket.

We are no longer in March

Trac:
Keywords: TorBrowserTeam202003 deleted, TorBrowserTeam202004 added

The #19251 (moved) patches have been merged, so this ticket is also fixed.

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

closed

changed time estimate to 8h

mentioned in issue #23547 (moved)

mentioned in issue #33035 (moved)

mentioned in issue #30022 (moved)

moved to tpo/applications/tor-browser#23545 (closed)

mentioned in issue tpo/applications/tor-browser#33035 (closed)