01/28/2012 10:40 PM, Maxim Kammerer: > On Sat, Jan 28, 2012 at 20:52, anonym <[email protected]> wrote: >> When Tor shuts down it writes the consensus to the data dir even if it >> is unverified. When Tor starts it will load the saved consensus, and now >> it will find that it's valid, and hence *NOT* download a new consensus. >> All should be well from here on. > > It will download a new consensus after an hour. If htpdate fails, > that's where Tor stops working.
Hmm, I think you are partially correct. I now see that there is an issue with consensus *updates* (i.e. when we fetch a new, fresher one) that can occur when you have a clock that is too slow (but this doesn't seem like what you meant?): (This is a quite lengthy analysis, but the TL;DR is: Let's revert back to vmid = middle of [valid-after,valid-until] because clocks that are E minutes back in time may cause issues (temporarily Tor outages) after consensus updates that happen at the (60-E):th minute or later during any hour.) Let's first note that the first consensus we get (the one tordate uses to set the time according to) will always be valid and Tor should work, so problems can only occur when Tor fetches a new consensus to get a fresher one at a later time (sometime after fresh-until but before valid-until). So the problems will not hit the user immediately, and it will not hit the user at all if htpdate succeeds. But let's assume htpdate fails for unknown reasons, so the time is only set by tordate. A clock set by tordate to the middle of [valid-after, fresh-until] can only be up to 30 minutes incorrect. If our clock is in the future any new consensus we fetch will still be valid for at least a couple of hours so it is ok. If there was a problem with a clock in the future our previous vmid would only make things worse since it always gives us a clock that is 30 to 90 minutes in the future. (This also explains why htpdate failures imply that hidden services doesn't work (hidden services running on Tors prior to the current alpha require a clock that is no more than 30 minutes incorrect).) What remains is a slow clock which is E minutes back in time, with 0 < E <= 30 (we skip seconds for simplicity). Say we fetch a consensus at H:X:00, that is 60-X minutes before our current consensus' fresh-until when the authorities makes a new consensus (with valid-after H+1:00:00) available. Then we have two cases: If X < 60-E both our clock and the real time is before fresh-until so we get a consensus with valid-after H:00:00 which is fine since our clock is H:X:00. If X >= 60-E our clock is before fresh-until but real time has past beyond it, so there is a new consensus with valid-after H+1:00:00 while our time is just H:X:00. The consensus will not be valid for another 60-X minutes. So the question is at what times a Tor client tries to download a consensus update. I ran a test for some hours starting at around 00:55:00 UTC yesterday, where I set the time to 00:30:00, so E=25 which means that fetches that occur after the ~35th minute should result in Tor outages due to invalid consensuses. I got the following results (all times below are in UTC too): Tor log: Jan 29 03:56:28.191 [Warning] Our clock is 3 minutes, 32 seconds behind the time published in the consensus network status document (2012-01-29 04:00:00 GMT). Tor needs an accurate clock to work correctly. Please check your time and date settings! Jan 29 03:56:28.194 [Notice] Our directory information is no longer up-to-date enough to build circuits: We have no recent network-status consensus. Jan 29 03:56:28.194 [Notice] I learned some more directory information, but not enough to build a circuit: We have no recent network-status consensus. Jan 29 04:00:03.305 [Notice] We now have enough directory information to build circuits. Jan 29 04:00:04.352 [Notice] Tor has successfully opened a circuit. Looks like client functionality is working. (Plus a similar series of log entries at around 7:00:00) I was also logging changes to cached-consensus: Sun Jan 29 00:30:59 UTC 2012: valid-after 2012-01-29 00:00:00 fresh-until 2012-01-29 01:00:00 valid-until 2012-01-29 03:00:00 Sun Jan 29 02:08:16 UTC 2012: valid-after 2012-01-29 02:00:00 fresh-until 2012-01-29 03:00:00 valid-until 2012-01-29 05:00:00 Sun Jan 29 03:56:28 UTC 2012: valid-after 2012-01-29 04:00:00 <-- Not valid yet fresh-until 2012-01-29 05:00:00 valid-until 2012-01-29 07:00:00 Sun Jan 29 05:31:51 UTC 2012: valid-after 2012-01-29 05:00:00 fresh-until 2012-01-29 06:00:00 valid-until 2012-01-29 08:00:00 Sun Jan 29 06:53:25 UTC 2012: valid-after 2012-01-29 07:00:00 <-- Not valid yet fresh-until 2012-01-29 08:00:00 valid-until 2012-01-29 10:00:00 Sun Jan 29 08:31:47 UTC 2012: valid-after 2012-01-29 08:00:00 fresh-until 2012-01-29 09:00:00 valid-until 2012-01-29 11:00:00 Sun Jan 29 10:23:27 UTC 2012: valid-after 2012-01-29 10:00:00 fresh-until 2012-01-29 11:00:00 valid-until 2012-01-29 13:00:00 Sun Jan 29 12:41:52 UTC 2012 <-- Since X = 41 >= 60-E = 60-25 = 35 valid-after 2012-01-29 12:00:00 <-- we should've got 13:00:00. Weird. fresh-until 2012-01-29 13:00:00 valid-until 2012-01-29 15:00:00 Sun Jan 29 14:45:17 UTC 2012: <-- Weird valid-after 2012-01-29 14:00:00 <-- again. fresh-until 2012-01-29 15:00:00 valid-until 2012-01-29 17:00:00 Sun Jan 29 16:36:35 UTC 2012: <-- Weird valid-after 2012-01-29 16:00:00 <-- again. fresh-until 2012-01-29 17:00:00 valid-until 2012-01-29 19:00:00 Sun Jan 29 18:40:58 UTC 2012: <-- Weird valid-after 2012-01-29 18:00:00 <-- again. fresh-until 2012-01-29 19:00:00 valid-until 2012-01-29 21:00:00 So it seems Tor can fetch a new consensus pretty close to fresh-until and then we expecience problems with our consensus. Something is weird, though, because several other of the above logged consensus fetches should have failed but didn't. Since consensus updates (i.e. every consensus fetch except the first) are not necessarily fetched from authorities directly, but may be fetched from directory mirros, I suspect there may be delays before a new consensus reaches all mirrors. In the weird cases we just happened to find one with the old consensus. However, besides logging the consensus changes I also tried a wget fetch over Tor every minute, and none of them failed. Maybe Tor had old circuits that were usable for a long enough time to avoid problems. Or maybe polipo's cache messed things up. I modified the script so that the cache is cleared etc, but I did that only after the last not-yet-valid consensus was downloaded. Whatever. Now, in Tails this error only occurs if htpdate fails (and this should be unlikely nowadays) but I think this potential problem still warrants for us not setting time to the middle of [valid-after, fresh-until]. Setting it to fresh-until (time error 0 to 60 minutes in the future) or up to one hour later would be safe though. I guess it's best to have a margin in both ways, so our old middle of [valid-after,valid-until] seems like the safest choice. If everyone agree, let's revert. > Also, won't other nodes treat another Tor node with clock time before > their consensus differently? No idea. Cheers!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
