Hi,
anonym wrote (05 Oct 2011 16:41:23 GMT) :
> The approach in 1319c1c is safe for Tor, but it can cause troubles
> *outside* of Tor when we use the consensus for setting the time. It
> seems handling this edge case gets us into more and more trouble.
> Everything below refers to 1319c1c.
I think we should deal with this edge case in a "best effort" way,
without making our code too complex because of it, and without
spending too many hours on it. Seriously.
> Problem 1: is_clock_way_off() isn't really what we want.
> Ponder upon this: there can be a window of time less than 6 months since
> the Tails release where a majority of the authority certs are expired.
> Tor can't verify the consensus so we get an unverified-consensus, but
> maybe_set_time_from_tor_consensus doesn't look at that one so it will
> fail in an ugly way since cached-consensus doesn't exist.
> I guess we instead just want to check if the consensus we got is old,
> e.g. something like [ $consensus_valid_until -lt $current_time ].
This proposal indeed improves the handling of the "clock in the
future" case. But it does not deal with the "clock in the past"
situation anymore. Shouldn't it?
> Problem 2: a malicious authority could still arbitrarily set our time.
> If we get an unverified-consensus we set the system time to the release
> date, then maybe_set_time_from_tor_consensus will (*definitely*, not
> maybe :)) set the time according to cached-consensus -- we just renamed
> unverified-consensus to this and somehow that magically allows us to
> trust it... bad idea.
What kind of malicious authority is able to feed such a consensus to
the Tor client running in Tails, in a way that the latter saves it to
unverified-consensus?
Anyway, once we have tried to fix the time by setting it to the
release date, instead of renaming unverified-consensus to
cached-consensus, what about simply deleting this file before
restarting Tor and waiting for a cached-consensus again?
> Sure, Tor will not use the unverified-consensus if it can't be
> verified, so that is safe, but we could still end up setting a time
> set by by the attacker. Not nice.
I may be missing something, but I think this is a compromise we can
make if we have no better ways.
Since no connection to the Internet will work once this attack is
successful, traces of the time chosen by the attacker may only be left
on local storage (and we do not seriously pretend to "anonymize" the
timestamps left on files written there - well, we could, and it would
make sense to try, but this is not something we guarantee yet) or on
the LAN - and we don't make any guarantee wrt. traces left on the LAN
(could make sense too, but we're not there yet). Also, even this kind
of local area leaks seem to affect only someone who started Tails in
order to *only* work on local files without accessing the Internet;
else, what happens is "it doesn't work", and Tails is likely to be
restarted or shutdown before any leak happens. I'm not saying the
possibility of an exploitable leak does not exist, only trying to
assess how serious it is.
> Problem 3: what should we do when we get an unverified-consensus but
> the time is correct? I suppose this kinda implies something went
> terribly wrong. I guess we could just skip setting the time and let
> Tor run -- it will be unusable. But the user should be notified, no?
I agree we should just let Tor run in this case, just as we've always
done until now I think. I'm not fully opposed to notifying the user
(because at this point we do know something is wrong) but I don't
think the added complexity is worth it as this seems to me a corner
case. And, well, if this happens, I don't think this is something we
should deal with ourselves using a NM hook: it's a Tor problem, that
shall be reported by the Tor UI we are shipping, i.e. Vidalia. If we
start to try detecting the many cases when Tor cannot connect to the
Tor network, and notifying the user accordingly, I think we're going
to lose our minds and build very fragile pieces of software.
In the end, I think this class of issues belongs to an FAQ "What to do
if Tor does not manage to connect to the Tor network?", possibly
displayed by a late NM hook if Tor is not connected; that FAQ would
suggest to fix the system time by hand before retrying.
> I think the main problem stems from this: currently our only means
> for tordate to verify that a consensus is OK is if Tor itself writes
> a cached-consensus, and that is awkward.
I fail to see why this is awkward. Care to explain?
Bye,
--
intrigeri <intrigeri@???>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| We're dreaming of something else.
| Something more clandestine, something happier.
