little-t-tor: Provide support for better TBB UI of hidden service client authorization

**This is the network-team-side of ticket #30237 (moved). ** The current hidden service spec allows clients to authenticate themselves using auth-cookies. The future proposal 224 will allow clients to authenticate using username/password or pubkey.

Currently users have to edit their torrc and add HidServAuth lines for the hidden services that require authorization. In the future, it would be nicer if TBB had an interface for users to type in their authorization credentials.

Tor knows whether an HS needs authorization, because the intro list is encrypted. Tor would have to somehow transfer this knowledge to TBB, so that the browser can present a nice UI that the user can fill on the go.

Furthermore, with the future username/password authorization and this UI improvement, it won't be necessary for people to write on their torrc which hidden services they visit and what's their auth-cookie.

This is a ticket about finding out what mods need to happen in little-t-tor, and coordinating the development of this feature.

changed milestone to %Tor: 0.4.4.x-final

added 042-deferred-20190918 043-deferred component::core tor/tor hs-auth milestone::Tor: 0.4.4.x-final network-team-roadmap-2020Q1 network-team-roadmap-september owner::tbb-team parent::30000 points::24 priority::medium resolution::implemented severity::normal sponsor::27-must status::closed tbb-usability tor-hs type::defect ux-team labels

Trac:
Cc: N/A to arthuredelstein

Trac:
Cc: arthuredelstein to arthuredelstein, brade, mcs

Trac:
Cc: arthuredelstein, brade, mcs to arthuredelstein, brade, mcs, gk

Trac:
Username: michael
Cc: arthuredelstein, brade, mcs, gk to arthuredelstein, brade, mcs, gk, michael

Trac:
Cc: arthuredelstein, brade, mcs, gk, michael to arthuredelstein, brade, mcs, gk, michael, special

special and I were chatting on IRC, and thought that should be captured somewhere. That somewhere is here. I've removed some things from the below "log" to make it more clear.

13:52 < meejah> one thing tor-launcher lacks is a way to give it cookies for basic/stealth auth'd hidden-services
13:53 < meejah> ...would teaching it to understand http://thecookie@blarglyfoo.onion be a terrible idea? (obvious "con" is: people would probably copy/paste that and reveal their 
                seekrit)
13:54 < special> this would be ambiguous with standard HTTP authentication, for one
13:58 < special> I wonder how hard it would be to have the browser prompt for HS auth credentials..
13:58 < special> probably hard
13:59 < meejah> maybe just a static http://auth@blarglyfoo.onion could trigger popping a dialog for the cookie? pretty hacky though
13:59 < special> well, I think a tor client can request the descriptor and know that it needs credentials to use it
13:59 < special> it could, theoretically, ask for those credentials over the control port
14:00 < meejah> yeah. right now you have to SETCONF on HidServAuth ... which is fragile (as it's easy to destroy any other auths you might have set up manually)
14:01 < special> yes. I also mean that it could ask after requesting the descriptor, without knowing beforehand that credentials would be required
14:01 < special> just like visiting a website with HTTP auth enabled; you get a popup dialog
14:01 < meejah> true, that would be cool -- but unprecedented i think? (Are there any commands that do a request from tor->controller?)
14:03 < special> meejah: __LeaveStreamsUnattached works that way, I suppose.
14:04 < meejah> special: ah! yes, that's true!
14:04 < meejah> for consistency one probably needs "__QueryDescriptorCookies=1" or something ;)
14:05 < special> hmm
14:06 < special> meejah: if we're well behaved developers, we should summarize this conversation on a ticket somewhere. It sounds vaguely useful.

The TL;DR of the above is:

1. make Tor (optionally?) ask controllers for auth-cookies
2. teach tor-browser/launcher to use this API (and pop up a dialog)

Trac:
Cc: arthuredelstein, brade, mcs, gk, michael, special to arthuredelstein, brade, mcs, gk, michael, special, erinn

One thing I would suggest, in terms of UI, is to avoid having the auth cookie/string be something that can be passed along with the onion URL. This is mostly to avoid a situation where someone passes foo.onion:authblahblah to a tor2web site and it's then cached in some likely-public way without the site owner's knowledge.

So as I understand it, the idea here is:

i. User visits protected onion through TBB. ii. Tor fetches the descriptor and learns its encrypted. iii. Tor asks TBB through the control port for the shared secret of this onion. iv. TBB presents user with an "enter your shared secret" dialog. v. User inputs secret, TBB passes secret back to Tor through control port. vi. Tor is now able to decrypt descriptor and continue connecting.

This seems like it would require writing some control port functionality. And since I'm browser illiterate, I have no idea how easy it is to present such dialogs to the user, and whether they can be pinned down to a specific tab (so that the user knows which website is causing it).

Another more pragmatic approach could be a menu that can be accessed by the TBB user at any time, where the user can put the onion address and the shared secret, and TBB will use that credential every time it encounters that onion address. In this case TBB could maybe just do SETCONF HidServAuth directly, without writing more control port functionality, but more thinking is needed.

For further bikeshedding, maybe we could also have an option on whether the user wants to save the secret on disk.

Replying to asn:

3. Tor asks TBB through the control port for the shared secret of this onion.

I set up a test hidden site requiring basic authorization, and then attempted to make various connections with Tor Browser, watching HS_DESC events in the Control Port. Here are the results:

With the correct onion address but no credentials I saw several of: 650 HS_DESC FAILED [onion address] NO_AUTH [relay] REASON=BAD_DESC

with an incorrect onion address (note different final character): 650 HS_DESC FAILED [wrong onion address] NO_AUTH [relay] REASON=NOT_FOUND

and with the correct onion address and setting the proper credentials using setconf HidServAuth="[onion address] [passcode]" I got 650 HS_DESC RECEIVED [onion address] BASIC_AUTH [relay]

So it seems Tor already lets a controller know that credentials are needed for an onion site when an attempt to connect without credentials fails. If HS_DESC FAILED ... REASON=BAD_DESC is encountered, we can pop up the dialog in the browser UI asking the user for credentials, and then attempt to connect again if they enter some.

Trac:
Keywords: N/A deleted, tbb-usability added
Component: Tor to Tor Browser
Owner: N/A to tbb-team
Milestone: Tor: 0.2.??? to N/A

I am not sure what the prompt should look like, but hopefully we can use Mozilla's Prompt Service, a notificationbox, or another existing prompt mechanism to add this feature. The harder part will be modifying Torbutton to receive the HS_DESC notifications and associating them with the correct browser tab.

Here's my attempt at a patch:

https://github.com/arthuredelstein/torbutton/commit/4ca161b6f3fcdb7a2cdfbffd1701ea974f1b1863

You can test it with http://xbzlzdvocm6hiate.onion/ and key 5NAYKf3w3QEln9jpP2tJVA To test with an incorrect key, try 3NAYKf3w3QEln9jpP2tJVA

Trac:
Status: new to needs_review

Replying to arthuredelstein:

Here's my attempt at a patch:

https://github.com/arthuredelstein/torbutton/commit/4ca161b6f3fcdb7a2cdfbffd1701ea974f1b1863

You can test it with http://xbzlzdvocm6hiate.onion/ and key 5NAYKf3w3QEln9jpP2tJVA To test with an incorrect key, try 3NAYKf3w3QEln9jpP2tJVA

This seems to work!!!

BTW, I noticed that we get the following message 6 times before we get the password dialog:

Mar 14 23:39:33.000 [warn] Failed to parse introduction points. Either the service has published a corrupt descriptor or you have provided invalid authorization data.
Mar 14 23:39:33.000 [warn] Fetching v2 rendezvous descriptor failed. Retrying at another directory.

which means that Tor asks for the descriptor on all 6 HSDirs before Firefox timeouts and asks for the secret. Ideally, we should ask for one descriptor, and if it's encrypted ask for the password, instead of spending tiem on getting it 5 more times.

I wonder why this we ask for it many times since in connection_dir_client_reached_eof() we have:

          case RCS_BADDESC:
          case RCS_NOTDIR: /* Impossible */
            log_warn(LD_REND,"Fetching v2 rendezvous descriptor failed. "
                     "Retrying at another directory.");
            /* We'll retry when connection_about_to_close_connection()
             * cleans this dir conn up. */
            SEND_HS_DESC_FAILED_EVENT("BAD_DESC");
            break;

which means that BAD_DESC is sent directly after that log message, so it should have sent 6 of them right? According to torbutton's handleBadOnionSiteDescriptors shouldn't the dialog trigger on the first one?

All in all, this seems to work nicely so far. I think with a few little-t-tor hacks we might be able to get it to work perfectly.

Replying to asn:

All in all, this seems to work nicely so far. I think with a few little-t-tor hacks we might be able to get it to work perfectly.

Could you open a child ticket describing what is still needed on the tor side? Might be nice to get this fixed early in the 0.2.7.x cycle to have a well-tested new feature in Tor Browser 5.0.

Replying to gk:

Replying to asn:

All in all, this seems to work nicely so far. I think with a few little-t-tor hacks we might be able to get it to work perfectly.

Could you open a child ticket describing what is still needed on the tor side? Might be nice to get this fixed early in the 0.2.7.x cycle to have a well-tested new feature in Tor Browser 5.0.

I'm still unsure if any tor patches will be needed -- I think we'll have to investigate more first.

Trac:
Status: needs_review to needs_revision

#8000 (moved) is a duplicate.

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A
Reviewer: N/A to N/A
Cc: arthuredelstein, brade, mcs, gk, michael, special, erinn to arthuredelstein, brade, mcs, gk, michael, special, erinn, patrick@zajda.fr, lunar