[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #14389 [Core Tor/Tor]: little-t-tor: Provide support for better TBB UI of hidden service client authorization
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs