[tor-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
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: #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`
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.
> - 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.
> - 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 tor-bugs
mailing list