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