[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

#14389: Improve TBB UI of hidden service client authorization
-----------------------------+-----------------------------------
     Reporter:  asn          |      Owner:  tbb-team
         Type:  defect       |     Status:  needs_review
     Priority:  normal       |  Milestone:
    Component:  Tor Browser  |    Version:
   Resolution:               |   Keywords:  tor-hs, tbb-usability
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-----------------------------------

Comment (by asn):

 Replying to [comment:14 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14389#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs