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 _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
