Provide control port commands to ADD/REMOVE/VIEW v3 client-auth
We need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see #30382 (moved)).
Activity
changed milestone to %Tor: 0.4.3.x-final
Trac:
Parent Ticket: #14389 (moved)
Child Ticket(s): #32667 (moved)added 042-deferred-20190918 actualpoints::5 component::core tor/tor hs-auth milestone::Tor: 0.4.3.x-final network-team-roadmap-september owner::asn parent::14389 points::6 priority::medium resolution::fixed reviewer::dgoulet severity::normal sponsor::27-must status::closed tbb-usability tor-hs type::enhancement ux-team labels
Trac:
Description: We need control port commands so that TB can add/remove/view client auth credentials.Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache.
to
We need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see #30382 (moved)).
-
An initial torspec draft: https://lists.torproject.org/pipermail/tor-dev/2019-May/013798.html
-
Pushed branch here: https://github.com/torproject/tor/pull/1070
It's based on david's #30382 (moved) branch so that I can use his 'decrypt pending descriptors upon add' functionality. That's also the only part that is not unittested.
I also pushed a fixup commit to my spec patch based on the latest implementation: https://github.com/torproject/torspec/pull/81/commits/dafda3944241e4ab6dfe0fee90d2e97979ac8f94
Trac:
Status: assigned to needs_review 
Trac:
tor-os-auth-crash.txt-
Kathy and I are trying to integrate our work-in-progress Tor Browser code with a tor we built from the code at https://github.com/asn-d6/tor/tree/bug30381. Unfortunately, when we access a v3 onion service that requires client auth we encounter an assertion failure inside tor. See the attached file tor-os-auth-crash.txt. Please let us know if you need any more info in order to debug the problem.
Oh no... that is currently fixed in #30382 (moved)... Let me do an updated branch for you to work with:
Try to use this branch:
ticket30381_042_01https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=ticket30381_042_01It is not clean or anything but will have the latest code we have for your testing. Hopefully, should help you go forward!
-
Replying to dgoulet:
Oh no... that is currently fixed in #30382 (moved)... Let me do an updated branch for you to work with:
Try to use this branch:
ticket30381_042_01https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=ticket30381_042_01Thanks; this works much better. We now receive the correct SOCKS error code (after a 120 second delay, which is a problem asn already mentioned in his review of your #30382 (moved) pull request). Kathy and I should be able to make more progress using this branch though. Next we will experiment with
ONION_CLIENT_AUTH_ADD. -
OK I pushed fixes to David's comments in: https://github.com/torproject/tor/pull/1070
The branch needs to be rebased to latest master, and also incorporated withe fixes of comment:13. I will do that when David fixes up #30382 (moved) and we have a final branch from that side.
-
OK here is branch based on David's updated #30381 (moved): https://github.com/torproject/tor/pull/1483
This is meant to be used by the Tb team for testing since it includes all features.
-
We need a version based on the latest master once #30382 (moved) gets merged. Moving to
needs_revisionuntil then.Trac:
Status: needs_review to needs_revision -
OK now that #30382 (moved) is merged upstream, here is the #30381 (moved) branch rebased to latest master: https://github.com/torproject/tor/pull/1550
Trac:
Status: needs_revision to needs_review -
Replying to mcs:
Flags=Permanentdoes not seem to have any effect. Is there another ticket for that or should someone open one?Wow you are right!
CLIENT_AUTH_FLAG_IS_PERMANENTis not used in the HS client code. We need to open a ticket for this. I've pinged asn about it. Thanks mcs! -
Hm, I opened #32562 (moved) for this. Is this something we want to support as part of s27?
-
Replying to asn:
Hm, I opened #32562 (moved) for this. Is this something we want to support as part of s27?
Kathy and I have been working under the assumption that we need this functionality. Without it, someone who users an onion that requires client authentication will (obviously) need to re-enter their key every time they restart their browser... and that would be very inconvenient. But I admit that I do not know how people use onion services in the "real world." Antonela (or anyone) — any thoughts on this?
-
Good to know. We will make it in 043 for sure soon. So, assume it is there :).
The gist of this feature is that a default
ClientOnionAuthDirwill be used to write the file in unless it is specified ofc.So as Tor Browser, you might want to set that torrc value to the place you want those client auth file(s) to be written.
IMHO, I think this should be treated the same way as HTTP “Basic Auth”.
Ideally, I'd like a checkbox “Save this key” and then I should be able to look it up in Tor Browser “Saved logins” like other passwords.
Maybe this is worth more research, but I don't see why conceptually this should be treated differently than other passwords. :)
-
Replying to lunar:
IMHO, I think this should be treated the same way as HTTP “Basic Auth”.
Ideally, I'd like a checkbox “Save this key” and then I should be able to look it up in Tor Browser “Saved logins” like other passwords.
Kathy and I envision something very similar, although at least for now we do not plan to integrate the list of saved v3 onion service keys with the browser's "Saved logins" UI (while that might be possible, it would require some complex and difficult-to-maintain patches to Firefox). Our vision is to add a checkbox to the client auth prompt along with a text box where the user can enter an optional nickname, and we will add a management interface to about:preferences that allows people to view, remove, and possibly add additional keys.
But if this is not needed, we can save a lot of development time :)
IMHO, I think this should be treated the same way as HTTP “Basic Auth”.
+1 to lunar's comment. Ideally, recurrent users can save the passphrase, so they don't need to paste it every time.
Altho, this is not a blocker for this objective. If we don't have capacity to work on it for this delivery, we can aim to reach it for the next iteration.
-
Kathy and I experimented with this API today. Very cool stuff! Unfortunately, there is one problem: the
ONION_CLIENT_AUTH_VIEWresponse needs to be changed to include the HS address. Otherwise, we cannot present a management interface and allow users to remove keys, etc. (they won't know what .onion each key is associated with). -
Please find torspec branch here: https://github.com/torproject/torspec/pull/97 and little-t-tor branch here: https://github.com/torproject/tor/pull/1582
Since this hasn't been released I guess we don't need a changes file?
Trac:
Actualpoints: 4.5 to 5
Status: reopened to needs_review mentioned in issue #30382 (moved)
mentioned in issue #32016 (moved)
mentioned in issue #32667 (moved)
moved to tpo/core/tor#30381 (closed)
mentioned in issue tpo/core/tor#30382 (closed)
mentioned in issue tpo/core/tor#32016 (closed)
