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? All the best, Jacob _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev