[tor-bugs] #14389 [Applications/Tor Browser]: Improve TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: Improve TBB UI of hidden service client authorization
--------------------------------------------+------------------------------
 Reporter:  asn                             |          Owner:  tbb-team
     Type:  defect                          |         Status:
                                            |  needs_revision
 Priority:  Medium                          |      Milestone:
Component:  Applications/Tor Browser        |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team  |  Actual Points:
Parent ID:                                  |         Points:
 Reviewer:                                  |        Sponsor:
--------------------------------------------+------------------------------

Comment (by asn):

 Replying to [comment:27 dgoulet]:
 > Replying to [comment:22 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14389#comment:28>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online