Opened 4 years ago

Last modified 4 months ago

#14389 needs_revision defect

Improve TBB UI of hidden service client authorization

Reported by: asn Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tor-hs, tbb-usability, ux-team
Cc: antonela, arthuredelstein, brade, mcs, gk, michael, special, erinn, patrick@…, lunar, linda, dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Attachments (2)

14389.png (392.2 KB) - added by antonela 5 months ago.
14389-2.png (413.5 KB) - added by antonela 5 months ago.

Download all attachments as: .zip

Change History (31)

comment:1 Changed 4 years ago by arthuredelstein

Cc: arthuredelstein added

comment:2 Changed 4 years ago by mcs

Cc: brade mcs added

comment:3 Changed 4 years ago by gk

Cc: gk added

comment:4 Changed 4 years ago by michael

Cc: michael added

comment:5 Changed 3 years ago by special

Cc: special added

comment:6 Changed 3 years ago by meejah

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.

comment:7 Changed 3 years ago by meejah

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)

comment:8 Changed 3 years ago by erinn

Cc: erinn added

comment:9 Changed 3 years ago by 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.

comment:10 Changed 3 years ago by asn

So as I understand it, the idea here is:

  1. User visits protected onion through TBB.
  2. Tor fetches the descriptor and learns its encrypted.
  3. Tor asks TBB through the control port for the shared secret of this onion.
  4. TBB presents user with an "enter your shared secret" dialog.
  5. User inputs secret, TBB passes secret back to Tor through control port.
  6. 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.

comment:11 in reply to:  10 Changed 3 years ago by arthuredelstein

Replying to asn:

  1. 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.

comment:12 Changed 3 years ago by arthuredelstein

Component: TorTor Browser
Keywords: tbb-usability added
Milestone: Tor: 0.2.???
Owner: set to tbb-team

comment:13 Changed 3 years ago by mcs

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.

comment:14 Changed 3 years ago by arthuredelstein

Status: newneeds_review

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

comment:15 in reply to:  14 ; Changed 3 years ago by asn

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.

comment:16 in reply to:  15 ; Changed 3 years ago by 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.

comment:17 in reply to:  16 Changed 3 years ago by arthuredelstein

Status: needs_reviewneeds_revision

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.

comment:18 Changed 2 years ago by gk

Cc: patrick@… lunar added
Severity: Normal

#8000 is a duplicate.

comment:19 Changed 15 months ago by linda

Cc: linda added

comment:20 Changed 15 months ago by linda

Keywords: ux-team added

comment:21 Changed 5 months ago by asn

Executive summary: The current patch worked, but causes needless descriptor fetches because Tor is not good at communicating encrypted HS descriptors to tor browser. We should figure out if we can do this with the BAD_DESC controller event, or we need to figure out another way to communicate this to Tor Browser.

comment:22 Changed 5 months ago by asn

Executive summary No2: v2 descriptors do not let us distinguish between descs where the auth is enabled or whether they are corrupted, so Tor keeps on trying new directories in hope of finding a non-corrupted desc. In this sense, the current approach of the patch is not bad.

However for v3, as long as we know the onion address, we can learn whether authorization is enabled and in that case we can be smarter and pause Tor from trying new directories all the time. We should think of what's the right way to inform Tor Browser using the control port, and then how Tor Browser should inform Tor that authorization details have been filled out and Tor should continue parsing the descriptor...

comment:23 Changed 5 months ago by antonela

Cc: antonela added

Changed 5 months ago by antonela

Attachment: 14389.png added

comment:24 Changed 5 months ago by antonela

Based on our discussion at Rome, I made a prop for this using Photon UI.

https://trac.torproject.org/projects/tor/attachment/ticket/14389/14389.png

The copy is up to review. If the UI is ok, I'll create the mobile version and the Settings approach for the "Save Credentials" flow.

comment:25 Changed 5 months ago by arthuredelstein

Thank you, Antonela! A couple of things occur to me:

  • I am reluctant to save a list of websites and passwords on the user's machine. On the other hand, it's inconvenient to have to repeatedly enter a password. So maybe we could allow saving the onion password behind a master password, using Firefox's password manager? (I don't know anything about Firefox's password manager yet. We would need the encrypted password database to hide the list of individual usernames and sites.)
  • I think it could be useful to mention in the UI that this is an Onion Authentication (distinct from an HTTP Basic Authentication). Maybe we even want a special logo. :) Also, it might help to include a "more info" button or similar.

comment:26 in reply to:  25 Changed 5 months ago by antonela

Thanks for your reply Arthur!

Replying to arthuredelstein:

  • I am reluctant to save a list of websites and passwords on the user's machine. On the other hand, it's inconvenient to have to repeatedly enter a password. So maybe we could allow saving the onion password behind a master password, using Firefox's password manager? (I don't know anything about Firefox's password manager yet. We would need the encrypted password database to hide the list of individual usernames and sites.)

Got it. Saving credentials were something we talked about, but I can understand the risks of it. If we are not going to offer this feature to users, maybe an HTTP Basic Auth dialog box is fair enough. A UI like this could work better -> https://trac.torproject.org/projects/tor/attachment/ticket/14389/14389-2.png

  • I think it could be useful to mention in the UI that this is an Onion Authentication (distinct from an HTTP Basic Authentication). Maybe we even want a special logo. :) Also, it might help to include a "more info" button or similar.

I'd love to include an onion+lock icon. I'll work on it :)

Last edited 5 months ago by antonela (previous) (diff)

Changed 5 months ago by antonela

Attachment: 14389-2.png added

comment:27 in reply to:  22 ; Changed 5 months ago by dgoulet

Replying to asn:

Executive summary No2: v2 descriptors do not let us distinguish between descs where the auth is enabled or whether they are corrupted, so Tor keeps on trying new directories in hope of finding a non-corrupted desc. In this sense, the current approach of the patch is not bad.

Indeed... and not only that but a warning will be emitted because we'll try to parse the introduction point using a binary blob (encrypted).

Proposition:

Upon receiving a descriptor from the HSDir, if we can parse it (passes rend_parse_v2_service_descriptor()) but unable to decode intro points, we actually keep it in the client cache. Meaning that once Tor browser (or tor client) comes back with the authentication token, we don't have to refetch it. We'll probably to patch couples things here to make sure that we can use a descriptor in our cache with client auth but also that if the auth token is invalid, we trigger a BAD_DESC event.

Another approach would be to have a control port option (or torrc) to tell tor to keep any invalid but parseable descriptor which TB would enable. But honestly, for the sake of simplicity, I think we could easily keep it in the client cache which is bound to expire after a while normally.

That being said, TB does need to check for the BAD_DESC event of HS_DESC mentioned in comment:11. Once you get that, you should prompt for a client authorization. If you don't see that event after, it should be connecting. Else, tor should trigger the event again and TB should ask again for the auth code.

comment:28 in reply to:  27 Changed 5 months ago by asn

Replying to dgoulet:

Replying to asn:

Executive summary No2: v2 descriptors do not let us distinguish between descs where the auth is enabled or whether they are corrupted, so Tor keeps on trying new directories in hope of finding a non-corrupted desc. In this sense, the current approach of the patch is not bad.

Indeed... and not only that but a warning will be emitted because we'll try to parse the introduction point using a binary blob (encrypted).

Proposition:

Upon receiving a descriptor from the HSDir, if we can parse it (passes rend_parse_v2_service_descriptor()) but unable to decode intro points, we actually keep it in the client cache. Meaning that once Tor browser (or tor client) comes back with the authentication token, we don't have to refetch it. We'll probably to patch couples things here to make sure that we can use a descriptor in our cache with client auth but also that if the auth token is invalid, we trigger a BAD_DESC event.

Another approach would be to have a control port option (or torrc) to tell tor to keep any invalid but parseable descriptor which TB would enable. But honestly, for the sake of simplicity, I think we could easily keep it in the client cache which is bound to expire after a while normally.

That being said, TB does need to check for the BAD_DESC event of HS_DESC mentioned in comment:11. Once you get that, you should prompt for a client authorization. If you don't see that event after, it should be connecting. Else, tor should trigger the event again and TB should ask again for the auth code.

Hmmm, that does seem like a plan. However it's only approximately specified how it would work. And looking at the codebase it's quite hairy at those parts and the interfaces are not obvious to me. And also it's the legacy v2 codebase that we would ideally not touch a lot.

Another approach would be: Do nothing on the little-t-tor side and just use Arthur's approach of checking for BAD_DESC events. The tradeoffs:

+ No extra complexity on the Tor side (no chance for extra bugs, complicated code, review process, etc.)
- Some extra network load from users of this feature

The pros are quite obvious, so let's try to estimate the extra load we impose:

First let's assume that regular users don't stumble on random HSes with client auth, and even if they did, they would impose the same network load with this feature and without it (6 HSDir requests for unparseable descriptors). So it's safe to assume that the extra load comes from people who want to use this feature:

So when a person wants to use this feature (with the right password), they will cause 6 HSDir requests on the network, until TB realizes that it needs to try client auth. Then it will need to do one additional HSDir request to properly decrypt it. This means that legit users of this feature cause 6 useless HSDir requests. Basically the same load as mistyping an onion address. OTOH, when a person wants to use this feature with the wrong password, they will cause 12 useless HSDir requests.

It's unclear to me whether this tradeoff is worthwhile, however I do feel bad about spending time to reengineer the v2 codebase just for this, since the effort seems far from trivial. Then in v3 we can do it the right way.

I'm not actually sure this is a good idea, but I'll just throw it here for now.

comment:29 Changed 4 months ago by dmr

Cc: dmr added
Note: See TracTickets for help on using tickets.