[tor-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 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).

 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?

 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.

 > **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:49>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online