#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
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
