Autor: Jacob Appelbaum Data: Dla: The Tails public development discussion list CC: tor-talk, Elly Fong-Jones Temat: Re: [Tails-dev] [tor-talk] secure and simple network time (hack)
adrelanos: > Jacob Appelbaum:
>> 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.
>
> Good point. Running tlsdate in the clear will therefore be
> fingerprintable and subsequently the whole client could get blocked in
> censored areas.
>
How so?
> What could be the solution? I don't know. Can there be ever any network
> time sync solution which works in the clear?
>
Yeah, a parasitic one? For example, I'd be happy to add a network
sniffer ( tlsdate-passive ) or a proxy for HTTPS connections
(tlsdate-clock-extraction-proxy) that just looks for tls sessions,
extracts the server time and generates no traffic at all.
> If many distributions jump on the tlsdate train by shipping tlsddate by
> default, that may help?
I feel like we're over thinking it - even in the most harsh networks, we
rarely see full https blocking endlessly. The fact is that we could
probably even set our clocks against a tls mitm device ( I do so against
captive portals somteimes ) and it would still work well enough. In the
cases when https is really blocked entirely, I believe that we can
instruct tlsdate to try to look up other services (eg: randomly pick an
alexa top domain, do an mx query or connect to pop.example.com or
imap.example.com to start a tls connection).
Again, another feature request - it is a property of tls, so we can use
things other than webservers.
For what it is worth, in Egypt, ntp was busted when the network went
down unless you had a local ntp server; the same was true for most services.
>
>>From ntp* manpage:
> "ntpd adjusts the clock in small steps so that the timescale is
> effectively continuous and without discontinuities"
>
> I haven't had any issues without that feature and therefore don't miss
> it. My speculation is, that mainstream distributions may care more.
>
adjtime is a reasonable feature enhancement. It is in the queue. I've
been working on porting tlsdate to a few other platforms over that
feature though. I'd like to have a hardened parasitic network time
client before I worry about how it doesn't optimally update the clock.
>> 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.
>
> This is a difficult topic, I hate being a nitpicker, don't have all the
> answers, but must say...
>
> Distinguishing the operating system should be prevented if somehow
> possible: otherwise achievements made by pluggable transports wouldn't
> last long.
We already fail this test, no? Hell, who is even testing for that except
potential censors?
