Hi,
intrigeri:
> 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.
I mean, I guess? It looks like a vanilla OpenSSL client connection to a
TLS service - it can be *any* TLS service - so you could pick domain
names at random and connect to their mx records, their pop/imap or
www/https ports, etc.
The list of hosts is the least interesting way to fingerprint it, I
guess is my thought - so we could try to make sure that tlsdate always
has the same cipher-suites for tlsdate on Tails and ChromeOS. Then the
main difference would be the host name - I suspect though that both will
vary and in any case, such variance isn't a bad thing per se.
I guess I sorta feel like this is being over thought.
>
> 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].
I'm happy to hear that. Proxy support works today - so we could easily
ship a tlsdated.conf in git master for tails. Send me one and I'll merge
it; perhaps even as the default?
>
> [1] https://tails.boum.org/contribute/design/Time_syncing/#index3h1
>
I think tordate should be integrated into tlsdate's timewarp feature -
that is - we may already slam the clock forward to the compile time for
tlsdate. We could also tell it where there might be a consensus and slam
it a second time as long as it is newer than the compile date.
I could either write a simple user tool that is basically the most
simple tordate like function inside of tlsdate, or I could spawn a
process that calls tordate with some arguments, or I could write a new
tordate like program (eg: tlsdate-tor-consensus-date-parser).
If I were to reinvent the wheel without having read any of tordate's
source, I would:
open the consensus or the cached-microdescs
parse the absolute minimum time
stat the respective file to see the last possible atime/mtime/ctime
pick the later time of the two
jump the clock forward again
I suspect that we'd also want to make sure that the consensus on disk
did verify and check out - I wouldn't want to trust it blindly until I
carefully checked out how those files are created.
I realize that Tails doesn't start with a consensus and I consider this
to be a bug. If I use persistence for example, I would like a consensus
cached so that I might have the protection of Guard nodes as well as a
forward moving clock, as an example.
>> 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?
We support multiple hosts in the configuration file. I'd be happy to
take a default config that sets against any set of hosts you'd like, I
bet. Would that satisfy your desire for a pool? I'm also happy to start
working on the TLSDATEPOOL idea that I've written up in the git repo.
I think though that it makes more sense to pick the top set of hosts
from the alexa top 1000, pick a host randomly and try a tls connection.
This gives us some entropy as the list changes, it also gives us the
ability to blend in with the overall large amount of traffic to those
sites and the list is largely neutrally collected without revealing much
about us.
> If Tails wants to move to tlsdate some day,
I don't mean to sound frustrated but really, what is the core set of
features that you would want added that would allow you to replace
htpdate? Do you want me to add an HTTP date parser helper or what? :)
> I guess a prerequisite would be not to lose the nice security
> properties this approach currently gives us.
I see that you'd like both multiple hosts by default and a way to pick
from a set, effectively to create a consensus. I generally think this is
a fine idea but really, I question the security properties if you're
worried about fingerprinting. If you're using it over Tor, I feel like
the fingerprinting is not worth serious consideration. If you're not, I
feel like a set of three host pools is extremely revealing. So in that
sense, if you want to settle for that - yeah, a consensus is a possible
enhancement I'd consider.
I'd like it even more if we pick a few different keys/root chains, burn
those into tlsdate, and add other stuff like DANE, convergence, CT, a
look aside via Tor and so on are added into tlsdate's tls verification
process.
That kind of verification feature set is a probably a bit off though as
most of that stuff doesn't really exist in a usable, large deployment
yet. :)
As an aside, I'd like to add hardening that Tails would find useful -
the AppArmor policy is not very useful, I guess. There is no SELinux
container as of yet, though I bet it would be fine to use the ntp
context over nothing; seccomp policies and minijail are available,
though the Debian package does not use them...
What kernel hardening does Tails currently support?
>
> [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?
Yes, I believe so.
>
> (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.)
>
I think it currently just uses clients3.google.com.
All the best,
Jacob
