Hey hey,
intrigeri:
> Hi,
>
> intrigeri wrote (25 Mar 2012 23:02:55 GMT) :
>> Jacob Appelbaum wrote (20 Feb 2012 20:30:08 GMT) :
>>> For a while I've been interested in secure network time that would
>>> be useful for Tor users. Tor users generally need accuracy to the
>>> hour in the local system clock.
>
>> Thank you for tackling this problem.
>
> ... and thank you for going on with it!
>
>>> As a result, I've also written another tool, tlsdate[1], that
>>> I regularly use for setting my own clock.
>
>> What network fingerprint does tlsdate currently display if I run it
>> in the clear, without forwarding its traffic through Tor?
>
> Jake asked me to have another look at tlsdate, which was uploaded to
> Debian, so here it goes :)
>
> (It's pretty clear I lack much of the background and intended usecase,
> so please correct whatever is wrong in what follows!)
>
> So, Jake tells me that ChromeOS will use tlsdate by default, and that
> this should solve the fingerprinting issue. Therefore, I assume this
> implicitly answer the (half-rhetorical, I admit) question I asked in
> March, and I assume there is indeed some fingerprinting issue. So, in
> the following I'll assume it's relatively easy, for a close network
> adversary (say, my ISP) to detect that I'm using tlsdate.
>
It isn't shipping yet, so we'll see what happens.
>>From what I remember from our past attempts to discuss this on IRC,
> I assume the intended usecase for Tails is to run tlsdate in the clear
> (that is, without going through Tor) so that the clock is set before
> Tor is started.
There are a few use cases - the first is to use it with the -t option -
this at least will skip the clock forward to a recent build time. So if
previously, the clock was in 1970, you're at least now in the same
decade as the tails release. Probably the same year and likely, with a
few releases a year, the same month. That has no network access at all.
The next use case is to use it over Tor - I haven't added direct proxy
support yet but I'll do so when it becomes a blocking issue. As it
stands now, you can easily just `usewithtor tlsdate` and it will work
fine. This gives you the ability to securely set your clock over Tor.
Another use case is to fire it up against any SSL/TLS enabled server,
including the Tor relay you were going to use anyway, and attempt to use
it as a time source. If you use a Tor relay, tlsdate currently lacks a
way to verify the key for that relay - so it's a leap of faith, rather
than a leap of cryptographic something or other. But at the very least,
you no longer need to involve any third party that you weren't already
going to connect to - it isn't more secure, it's just a cute hack.
The most common way for me to use tlsdate is to connect to a popular TLS
server and if I trust the CA, which can be pinned to a *single* CA that
isn't part of the traditional cartel, I can easily trust it. Generally,
I find that this works fine.
>
> If so, from the PoV of a close network adversary, if Tails starts to
> use tlsdate in the clear, as a Tails user, then I'm part of the set of
> people who run tlsdate and start Tor soon after, and in the current
> state of things, this set would almost exactly match the set of
> Tails users.
>
That might be true - that's a good reason to add Tor tls fingerprint
verification to tlsdate - however, I'd take this fingerprinting risk
over a older consensus or Tor simply not working at all.
> The fact that ChromeOS uses tlsdate forces this kind of adversaries to
> detect "tlsdate followed by Tor", instead of merely detecting tlsdate
> alone, in order to detect Tails users. (Looks like we have to convince
> Google to run Tor by default on ChromeOS? :)
>
Tor has been ported to ChromeOS as far as I know - I have talked with
them about adding a guest mode that uses Tor.
> Therefore, I'm not convinced tlsdate in the clear would be any better,
> on the fingerprinting side of things, than the "htpdate in the clear"
> system we eventually managed to escape in Tails 0.9 and later.
> Which means it looks quite worse, fingerprinting-wise, than what we
> currently ship.
>
The key difference with htpdate is that one has a cryptographic
signature. I'll take a subset of possible MITM attackers over fully
trusting something that anyone could MITM.
Furthermore, I think that you're making a trade-off between
fingerprinting on the network, which Tor does not even try to address by
default, and the ability for someone to try to use Tor with an incorrect
clock, something that explicitly doesn't work in the Tor design.
In an ideal world, Tor will learn the clock anonymously and not care
about the system time. We're not there yet; patches are always welcome!
> Thoughts?
>
> (Seriously, please prove me wrong, my life would be easier as
> a result :)
>
I generally think that shipping tlsdate makes sense, especially if Tor
is already running as you can then keep clocks securely in sync. It may
not make sense for first boot, other than to at least move it forward
with `tlsdate -t`; that's up to you guys, of course.
All the best,
Jake
