[tbb-bugs] #14389 [Core Tor/Tor]: little-t-tor: Provide support for better TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
authorization
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:
  auth                                           |
Parent ID:  #30000                               |         Points:  14-24
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

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
 of tor?
 >

 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.

 Sounds reasonable.

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