Re: [tor-talk] [Tails-dev] secure and simple network time (hack)

[adrelanos <adrelanos@xxxxxxxxxx>]

Jacob Appelbaum:
> 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?

Not necessarily. This is a difficult question.

Tails:
(For your ISP or local network administrator)
https://tails.boum.org/doc/about/fingerprint/index.en.html

Whonix (since interested in this topic as well):
https://sourceforge.net/p/whonix/wiki/Fingerprint/#for-your-isp-or-local-network-administrator

My point is, even if the answer is at the moment "we fail that test",
it's hopefully "possible to fix" as well. And, we should try to prevent
adding new factors, which could worsen the current status, if that
appears (already) attractive and doable.

Of course, the already existing (or new) operating system fingerprinting
by ISP issues could still get fixed when they get real world issues. For
example, Tails could mimic a mainstream operating system, by running one
untorified in a VM or chroot; and letting pluggable transports doing the
obfuscation for Tor traffic.

> Hell, who is even testing for that except
> potential censors?

Potential censors, yes. Other, I don't have an answer.
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk