[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #20700 [Core Tor/Tor]: prop224: Implement standard client authorization
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs