[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tails-dev
Subject:    [Tails-dev] Please review and test feature/tordate
From:       anonym () lavabit ! com (anonym)
Date:       2011-10-10 11:52:40
Message-ID: 4E92DC88.1070801 () lavabit ! com
[Download RAW message or body]

10/06/2011 04:44 PM, intrigeri:
> 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.

You're absolutely right :)

>> 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?

I was under the impression that Tor didn't case about the
"dir-key-published" (otherwise I'm not sure how the "clock in the past"
case worked when I tested it in 469020d). Whatever. This was not really
intended as a proper fix. A better approach would be to actually look at
the certs' expiry/publish dates and check whether a majority of them are
fine with the system time...

>> 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?

Yeah, I suppose that serves as best effort, and as you may see in my
patch, that was my line of thinking. 7d869d2 is perhaps as good as it
gets without totally overcommitting ourselves to this issue.

>> 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

There's still I2P (and Freenet, Gnunet etc. if we ever feel like adding
more alternatives to Tor).

>> 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.

True.

> 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?

Mostly because this doesn't reliably tell us the reason *why* the
verification failed. For instance, it'd be nice to know if the system
time is after the certs expiration date. There are also other reasons
for it to fail than time-related ones. But as you said, trying to cover
all cases will likely drive us insane.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: </pipermail/tails-dev/attachments/20111010/45fba8ae/attachment.pgp>

[prev in list] [next in list] [prev in thread] [next in thread]