[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:42 mcs]:
 > Replying to [comment:39 asn]:
 > > Here are the tasks that need to happen from the network-team side
 here:
 > >
 > > - How does TB learn that a page needs client auth? It's likely there
 is no proper way for the TB to learn that a page needs client auth, that
 won't generate a huge log file error dump or extra HSDir queries. This is
 related to comment:15 and comment:27. We should figure out the right
 interface here. This might even be related to the error interface we've
 been discussing in #30022 since there is no standard way to carry errors
 from Tor to TBB right now. (points: 9)
 >
 > For the above, the options we are considering seem to be:
 > 1. Asynchronous notification via control port events, e.g., `BAD_DESC`
 events.
 > 2. A status code that is sent via the TCP connection interface (e.g.,
 SOCKS or HTTP CONNECT).
 > My concern with option 1 is that it may be difficult in the browser to
 associate a `BAD_DESC` event with the browser tab that is trying to access
 the .onion.
 >

 Little-t-tor could do either control port event or HTTP CONNECT. From a
 small conversation in #tor-dev it seems like HTTP CONNECT should be the
 way forward for now, and perhaps we can add control events in the future
 (for apps that don't support httpconnect).

 FWIW, `BAD_DESC` should not be used for this ticket, because by the time
 `BAD_DESC` is issued, little-t-tor has already done needless HSDir retry
 queries. So if we wanted a control port event, we would need to make a new
 one.

 So, I guess the plan here is to use HTTP CONNECT for this, and define a
 new error code for HTTP CONNECT that says that a destination needs client
 auth. I guess we would need a proposal for that. Who wants to write this?

 > > - Network-team needs to help TB/UX team with the proper UX for v3
 client auth. This ticket contains mockups and info about v2, but v3 is
 different. In particular, in v3, the client needs to input two keys
 (x25519/ed25519) to Tor for client auth to work, or it can load the keys
 from a .key file. We should figure out how that should work in general.
 e.g. inputting two keys is messy and confusing. perhaps we can unite them
 into a single string? (points: 3)
 >
 > Kathy and I have experimented with v3 client auth and read parts of
 rend-spec-v3.txt. Are two keypairs required today or is that a future
 thing? We used
 https://gist.githubusercontent.com/mtigas/9c2386adf65345be34045dace134140b/raw/c95955cc9bab28e5afce656d1333b9efccba2e10
 /onion-svc-v3-client-auth.sh to generate configuration data and it seemed
 to work... but that script only generates one x25519 keypair as far as we
 can tell.
 >

 Yes, you are absolutely right. We currently have only one x25519 keypair
 for client auth... There is no need for a second keypair. Our doc is so
 bad here, that even I got confused. Sorry about this.

 > > - In v3 client auth, clients can generate public keypairs that they
 pass to the onion service. We currently have some super hacky scripts to
 do that (e.g. https://github.com/pastly/python-
 snippits/blob/master/src/tor/x25519-gen.py), but we've been discussing
 writing a proper tor-keygen program to do that (#18098). Interfacing (the
 nonexistent) tor-keygen with TB and making the UX will certainly be some
 effort. This might be an optional part of this deliverable for later if we
 have time (points: 10).
 >
 > It is worth keeping in mind that in Tor Browser it is inconvenient to
 fork and exec a program and capture output (possible, but not convenient).
 I think it would better to have control port commands for everything: key
 generation, adding a client side key, listing keys, removing a key.
 >

 Interesting. That's worth noticing indeed.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14389#comment:44>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online