[tbb-bugs] #23545 [Applications/Tor Browser]: UX improvement: Tor Browser should handle bogus HSv3 addresses

[Tor Bug Tracker & Wiki]

#23545: UX improvement: Tor Browser should handle bogus HSv3 addresses
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, prop224, ux-team,            |  Actual Points:
  034-triage-20180328, 034-removed-20180328      |         Points:
Parent ID:  #30022                               |  network-team: 5-10
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by sysrqb):

 Replying to [comment:17 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 [https://tools.ietf.org/html
 /draft-nottingham-proxy-status-00 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 URL: <https://trac.torproject.org/projects/tor/ticket/23545#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online