[tbb-bugs] #14389 [Core Tor/Tor]: little-t-tor: Provide support for better TBB UI of hidden service client authorization
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri May 3 10:06:26 UTC 2019
#14389: little-t-tor: Provide support for better TBB UI of hidden service client
Reporter: asn | Owner: tbb-
Type: defect | Status:
Priority: Medium | Milestone: Tor:
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs, tbb-usability, ux-team, hs- | Actual Points:
Parent ID: #30000 | Points: 14-24
Reviewer: | Sponsor:
Comment (by asn):
Replying to [comment:49 mcs]:
> Replying to [comment:48 asn]:
> > Please let us know what kind of info you would need from such an
asynch control-port event to associate it with a browser tab, and any
other thing you need, and we will write it up for you.
> Kathy and I did some experimentation with Arthur's patch from
comment:14. We adapted it to work with a multiprocess browser and made
some other fixes to get it to work (but only for v2 auth, not v3).
> Relying on a control port event as his code does can be made to work
with some limitations, e.g., we probably can only make it work for HTTP
GETs where the .onion is the top-level / first party URL. Kathy and I
think it will be too difficult to handle odd cases such as a non-onion
page that contains a .onion sub-resource (e.g., in an iframe) which
requires client auth).
Hmm, perhaps that's good enough for this use case since we mainly care
about visiting websites that are client authed , and not subresources.
That said, as GeKo said, we should remember that whatever decision we take
in this ticket might shape the path in o2a2 (#30022) and o2a4 (#30025).
So since we ended up ditching HTTPCONNECT, we won't be able to use that in
those tickets, so we are restricted to SOCKS or control port. In
particular, if we choose control port events for this ticket, perhaps we
should stick to control port events for those activities as well. Would
that work well for o2a2 and o2a4?
> One surprising thing we encountered is that after using `SETCONF` to add
a `HidServAuth` line, we had to restart tor before they key was used. We
were testing with tor 0.4.0.4-rc. Is this a regression in recent versions
Hmm, that's weird. Not sure if this is a regression or not, but filed a
ticket for it #30378. Not sure how much priority this should get given
that it's a v2 bug.
> Another problem is that the an `HS_DESC FAILED ... REASON=BAD_DESC`
event is only emitted the first time we try to connect to a .onion. It
would be nice if we could have an event for v3 auth that:
> 1. Is emitted each time we try to connect.
> 2. Is an unambiguous message that tells us that client auth is required.
Yes, there is a bunch of negative things to `BAD_DESC`. Also the fact that
it gets issue only after the client has done 6 failed HSDir queries
already. We should think of how the new event should work to also maintain
the properties you are asking for.
> > **As a further thing**, we need to figure out how we are gonna be
setting the client auth key on the client side. Right now, Tor asks you to
create a file with the key details. Is this something that Tor Browser
could do? Or does it want a control port interface? This is important
because it also decides if the client auth is permanent, or gets forgotten
after shutting down TB (related to comment:1:ticket:30237).
> I do not know what other people think, but unless there is a security
reason to do otherwise it seems best if tor manages its own data. That
means having a control port interface and probably an option for temporary
(in memory) vs. permanent (on disk) storage. We would need to build UI in
Tor Browser to allow people to add/view/remove keys, which means we need
control port primitives for all of those things.
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14389#comment:50>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs