[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
Tue Apr 23 19:31:31 UTC 2019

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
 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:  #30237                               |         Points:  14-24
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must

Comment (by 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`
 2. A status code that is sent via the TCP connection interface (e.g.,
 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.

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

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

 Apologies if any of the above is nonsense... this space is new to Kathy
 and me and we are a little overwhelmed :)

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

More information about the tbb-bugs mailing list