Re: [Tails-dev] tordate: why is it safe to set time fromunve…

01/20/2012 08:53 PM, Maxim Kammerer:
> On Thu, Jan 19, 2012 at 23:09, intrigeri <intrigeri@???> wrote:
>> On October 9th, a commit of yours (58cc2dd) in Liberté Linux Git
>> repository made the very move we were unsure of. So I guess this
>> approach seemed safe enough to your eyes. May we know why?
>
> Well, as I see it, the difference between verified and unverified
> consensus matters to Tor, but not to the distribution that already
> decided to set the time from the consensus header. By setting the time
> from "cached-consensus", you are risking a replay attack on Tor, fine
> — but by setting the time from "unverified-consensus", you are
> additionally risking — what exactly? Tor will handle bad signatures,
> after all (which are the reason for consensus being unverified — e.g.,
> expired certificates), so the additional risk is letting an adversary
> set an incorrect time on the system? But time is only critical to Tor,
> because of the risk of replay attacks, which we are already ignoring.
>
> Maybe I am missing something, but for a distribution, both verified
> and unverified consensus are of equal value — getting some (not
> necessarily trusted) idea of what to set the clock to, if Tor says
> that the clock is wrong. Both cached and unverified consensus could be
> the result of an attack, but I don't see how setting the time from
> unverified consensus allows for new attack vectors.

I agree with this reasoning. My only concern before was that Tor maybe
behaves differently when it only has an unverified-consensus that it
later on manages to verify. I can't find anything in the Tor sources
that suggests that the name should matter, so I guess my earlier
concerns were unfounded.

Intrigeri, I say we implement this and try to push it into devel, test
the hell out of it, and if tests are good also push it into stable so it
ends up in the next point release.

Cheers!