Re: [tor-bugs] #2991 [Tor]: Confusing log messages when a DA starts using a new key

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#2991: Confusing log messages when a DA starts using a new key
------------------------+---------------------------------------------------
 Reporter:  rransom     |          Owner:                  
     Type:  defect      |         Status:  new             
 Priority:  normal      |      Milestone:  Tor: unspecified
Component:  Tor         |        Version:                  
 Keywords:  tor-client  |         Parent:                  
   Points:              |   Actualpoints:                  
------------------------+---------------------------------------------------

Comment(by sysrqb):

 Replying to [comment:9 nickm]:
 > The field name "signed_descriptor_digest" is a little misleading -- it
 refers to the signed digest of whatever directory object we're talking
 about -- in this case, that's a certificate.

 Thanks, that makes more sense.


 > I think it's looking at two digests in this case because it's possible
 for the certificate to change without the signing key changing, but what
 tells us to download a new cert is encountering a signature using a
 signing key that we don't recognize.

 Right...now that I've actually looked at the cert parsing code this makes
 a lot more sense!


 > I suspect that a client bootstrapped between the time that a DA upgraded
 its signing key and the time that it used that key to sign a new consensus
 would emit these confusing messages as well.

 If the client was bootstrapping then this would make sense, but it doesn't
 appear that it was, and #5595 had been running for just under 5 days.


 Per nickm's comment on #5595:
 > The right solution here will probably involve looking very hard at the
 code that currently makes certificate downloads get attempted and/or
 reattempted, and seeing what, if anything, rate-limits attempts to re-
 download a certificate that has failed, then figuring out why this is
 happening.


 The downloads are rate-limited by download failures only, not by
 requesting and receiving multiple duplicates. A possible solution to this
 is to catch this edge-case by only allowing N attempts that result in
 "duplicate" downloads and then skip subsequent download attempts until
 after the current consensus' fresh-until time at which point we should
 hopefully retrieve a new consensus that was signed with the new key.

 Or we can modify networkstatus_check_consensus_signature to take into
 account the case where the consensus' valid-after date/time is before the
 given cert's published-on date/time and we have reached the threshold of
 duplicate downloads. In this case, we can ignore the signature on the
 consensus entirely. There are currently enough active DAs that such an
 action should not invalidate the consensus. If more than hald of the DAs
 change their certs within the same hour however, then clients will fail to
 accept a consensus for at most(?) an hour until the newer consensus is
 voted on and distributed.

 We can modify authority_certs_fetch_missing to ensure it does not attempt
 to redownload a cert for which it has already received N duplicates, in
 effect ignoring the sig (or invalidating it).


 I'll keep looking to see if there's a better way to handle this. I was
 thinking maybe request the cert from a mirror because it may still have
 the old cert, but finding such a mirror would be extremely difficult.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2991#comment:10>
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