[tor-bugs] #20700 [Core Tor/Tor]: prop224: Implement standard client authorization

[Tor Bug Tracker & Wiki]

#20700: prop224: Implement standard client authorization
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  haxxpop
     Type:  enhancement                          |         Status:
                                                 |  needs_revision
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  0.3.5.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  prop224, tor-hs, 035-roadmap-        |  Actual Points:
  master, 035-triaged-in-20180711                |
Parent ID:  #25955                               |         Points:  3
 Reviewer:  dgoulet                              |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by asn):

 Replying to [comment:36 dgoulet]:
 > I've commented on the new PR. Very very good stuff :). Minor easy-to-fix
 things I pointed it out.
 >
 > There is an issue that I've been discussing with haxxpop on IRC so I'll
 summarize it here. If the client gets the descriptor but can't decrypt it,
 there are two cases:
 >
 > 1. Client has *no* client authorization configured for the .onion.
 >
 >  What happens in this case is that we end up with many scaring warnings:
 > {{{
 > Aug 22 14:07:03.704 [warn] Encrypted service descriptor MAC check failed
 > Aug 22 14:07:03.704 [warn] Decrypting encrypted desc failed.
 > Aug 22 14:07:03.704 [warn] Service descriptor decryption failed.
 > Aug 22 14:07:03.704 [warn] Could not parse received descriptor as
 client.
 > }}}
 >
 >  ... and then the client will refetch the descriptor on _all_ HSDir
 leading to 8 times these failures. So the question is what to do if
 decryption fails? My opinion is:
 >
 >  * Downgrade the logs to info(). Then, iff the client can't decrypt the
 descriptor, then log info that it probably doesn't have a valid
 authorization for the service and *stop* the refetch. Creating a
 thundering herd on all HSDir because the first can't be decrypted is not
 good imo.
 >

 Sounds plausible. Perhaps we should still log a single line in notice that
 the client tried to access an HS with client authorization? So that the
 user "learns" why the connection failed, otherwise it's completely hidden.

 > 2. Client has client authorization configured for the .onion but not
 working.
 >
 >  In this case, same will happen as above *but* we do know in this case
 that the client has an authorization for the .onion but it simply didn't
 worked. So same as above, I would not make the client refetch but this
 time log *notice* that their configured authorization is not working.

 Sounds plausible.

 The ''underlying assumption'' here is that all HSDirs will serve the same
 descriptor, so if one can't satisfy us, the others can't satisfy us
 either, so no point in trying. I think that's a reasonable assumption for
 now.

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