Re: [Tails-dev] [tor-talk] secure and simple network time …

Delete this message

Reply to this message
Autor: Jacob Appelbaum
Data:  
A: The Tails public development discussion list
CC: tor-talk, Elly Fong-Jones
Assumpte: Re: [Tails-dev] [tor-talk] secure and simple network time (hack)
Elly Fong-Jones:
> On Tue, Apr 16, 2013 at 01:03:27PM +0200, intrigeri wrote:
>> Hi Jacob and Elly,
>>
>> Thanks for your answers! See more questions bellow.
>>
>> Jacob Appelbaum wrote (11 Apr 2013 06:56:18 GMT) :
>>> Basically - tlsdate in Tails would be a minor set of users compared to
>>> the much larger user base of ChromeOS.
>>
>> Sure.
>>
>> I doubt we can blend in this "anonymity" set, though: unless Tails
>> wants to forever copy the set of hosts ChromeOS queries (which I don't
>> think we would want to rely upon on the long run), then Tails' use of
>> tlsdate will probably be fingerprintable at least by the ISP if the
>> connections are made in the clear, so we probably would want to run
>> tlsdate over Tor anyway.
>
> Even if not, there are other easyish ways to distinguish a Chrome OS device,
> such as the autoupdate behavior.
>


I assume over time one would be able to distinguish it - though we
mostly care about getting a correct clock and then if someone tries to
guess our OS, we might be fine with them then filtering us or trying to
attack us. However, if we haven't set our clock correctly, we might have
some issues with actual attacks like replaying a consensus, etc.

>> So, I'm now considering this (tlsdate over Tor) to replace our use of
>> htpdate, and not to replace our initial time guess based on the Tor
>> consensus [1].
>>
>> [1] https://tails.boum.org/contribute/design/Time_syncing/#index3h1
>>
>>> I'd like to settle on a list of hosts that it uses by default which may
>>> include a Google host or not. I haven't yet decided.
>>
>> OK.
>>
>> Jacob, are you interested in implementing something like our current
>> multiple pool -based approach [2], or something else with similar
>> security properties? If Tails wants to move to tlsdate some day,
>> I guess a prerequisite would be not to lose the nice security
>> properties this approach currently gives us.
>>
>> [2] https://tails.boum.org/contribute/design/Time_syncing/#index4h2
>>
>> Elly Fong-Jones wrote (08 Apr 2013 03:06:02 GMT) :
>>> The (slightly outdated now) time-sources design doc is here:
>>> <https://docs.google.com/a/chromium.org/document/d/1ylaCHabUIHoKRJQWhBxqQ5Vck270fX7XCWBdiJofHbU/edit>
>>
>> Elly, is this design doc correct that tlsdate queries
>> clients3.google.com only in ChromeOS?
>
> Correct.
>


Do you happen to have a pcap of tlsdate on a recent ChromeOS device
doing a handshake? I wouldn't mind considering it a design goal that all
Tails tlsdate builds should have matching cipher suites. With some other
hackery we can probably make it identical for the data in a given
tlsdate flow.

>> (Given you implemented the multi-host feature, I'd be surprised that
>> you don't use it, but I could not find what /etc/tlsdate/tlsdated.conf
>> ChromeOS is using, so I don't know.)
>
> We are supposed to be using it, but are not yet. Open bug :)
>


If we made that set of hosts the default set of hosts - would anyone
mind? :)

All the best,
Jacob