Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
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
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
intrigeri: Jacob, are you interested in implementing something like our current multiple pool -based approach [2], or something else with similar security properties? What version of htpdate are you shipping currently? I've just been reading the source for htpdate-1.0.4 - is that the right version? I didn't find an htpdate package in Debian, where is the version Tails uses? Is it the perl version? Or perhaps htpdate-1.0.5? My initial thoughts from reading 1.0.4 very quickly are: It is written for HTTP services only I thought surely that it used TLS, am I auditing the wrong version? It is trivial to fingerprint It isn't written with defense in depth as a solid programming paradigm It looks like it might leak DNS (which in Tails probably won't matter) It has a static and easy to fingerprint user-agent: 'User-Agent: htpdate/VERSION' If called with long urls/host names: the HTTP HEAD request will be truncated It has a hand rolled HTTP parser It assumes no day light savings time Is this absolutely certain? It doesn't appear to be optimized for speed it creates and initializes data structures while parsing HTTP It has an interesting way of doing rtt calculation: rtt * 1e-6 It may use adjtime which is kinder and gentler it also uses settimeofday() htpdate_adjtimex() is a reasonably interesting idea It does basically everything setting euid/guid as 0 it doesn't really privsep It runs as root by default why not ensure that an unprived user/group is required? the code allows for dropping to user:group root:root The priv dropping code is not safe: 641 »·if ( sw_uid ) seteuid( sw_uid ); 642 »·if ( sw_gid ) setegid( sw_gid ); The programmer is funny: 750 »·if ( goodtimes ) I didn't see anything obviously exploitable but I did see that if some things fail to happen... all bets are off about things like not being root and there are no checks to catch such failures. All the best, Jacob ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
Hi, Jacob Appelbaum wrote (17 Apr 2013 08:58:32 GMT) : What version of htpdate are you shipping currently? This is documented there: https://tails.boum.org/contribute/design/Time_syncing/#index2h2 Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] tails_htp additions - was: secure and simple network time (hack)
Hi, it may or may not be of interest. I expanded tails_htp with bash scripts for Whonix. - starting tails_htp every hour after a sane random delay to avoid fingerprinting from ISP view - intrusive notification if it fails after boot - non-intrusive notification if it succeeds after boot - intrusive notification if it fails when running every hour (never happened so far unless test wise included network problems) - no notification if it succeeds every hour - combined graphical and text user interface for manual execution with status report - supervising tails_htp (if script wouldn't run at all, no pid, anything what could in theory go wrong will be caught) - never caught a bug yet The files are linked here: https://sourceforge.net/p/whonix/wiki/Design-Shared/#timesync Works very well. Thanks for tails_htp! Cheers, adrelanos ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Cicpa
CiCpa just passed the house. Overwhelming support. Now it goes to the Senate. If this law passes, will it affect Tor? Well we loose right to use Tor? I don't know if this the right place for this, if not please tell me and I will post in the appropriate spot. Thank for your opinion Andrew ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
intrigeri: Hi, adrelanos wrote (17 Apr 2013 19:33:23 GMT) : Why not build the required features into Tor itself? (Let's assume this is no rhetorical question.) My best guess is that nobody had 1. enough interest in this topic; 2. the right set of skills; 3. enough free time. In my experience, this is a correct answer to most why not? questions about wishlist tickets in the free software world. I have a proposal that is half written on the topic. Once I write the proposal, I will probably build it into Tor if no one else beats me to it. It will however require a bit of work as we don't want to keep such time setting capabilities forever, etc. Please don't refrain yourself from doing as much of the work as you can (write a proposal, discuss it, implement it) and from finding someone else to do the rest. I, for one, will be very grateful if this happens. Sure. Of course. However - the goal here is to for tlsdate to work everywhere - it will work anywhere where openssl works and that is even more places than Tor, sadly. I also want it to be used by groups that are not Tor - even if tor could set the time in this way, I'd want a way to check that confirms it. Trust but verify, right? All the best, Jacob ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
adrelanos: Jacob Appelbaum: 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 What in case the directory authority is not reachable (censored area)? Well, if we have a file on the disk, we don't even have to touch the network to jump the clock, right? Is the parasitic approach future proof anyway? Won't that cost the remote server admins cpu load and traffic? Probably and probably not? What if the remote server admins install some intelligent filter, which blocks Tor? (for other unrelated spam/ddos issues) Which server admins? People offering TLS? Why trust and get the time of some remote server admins who are not really willing to run a network time server? They most likely get their own time over unauthenticated NTP. Getting time from TLS is more a hack than a replacement for non-existing tcp, authenticated and distributed NTP. Yeah, I'm aware. Really, well aware. People keep telling me over and over again - it's not demotivating though as zero of those people suggest replacements, write the code and then show that it is actually as secure or more secure. Whenever a less friendly person gives me a hard time about the obvious futility of tlsdate, I think: Let me know how your ntp replacement project goes and I'll gladly use it when my shitty one trick pony isn't beating the pants off of your arm chair hacking. I'd say I'm kidding but really, we need a secure network time client and we need one badly. If we don't have one, we can't hold certain assumptions to be correct and entire systems can be broken. There is also the attack surface and architecture of other ntp/ntp-like clients. Instead I can imagine a better approach. The Tor network and Tor client itself are a good base for an alternative, safe, non-SSL-CA-dependant, Tor-safe, authenticated time server network. Sure - We have discussed extending the Tor protocol specifically and also with a small set of changes we can already extract the remote server time. We can even do this anonymously and quite easily. That won't solve it for everyone else using who isn't using Tor... which is basically the entire planet! :) Parse Tor consensus approach... Well, what if that format changes in future? Why not build the required features into Tor itself? I'll update tlsdate and fix it? The stat of the file will give us a time reference in any case - that won't change unless posix changes and if that happens, I am fine with porting tlsdate to this future system. :) My suggestions are here: https://trac.torproject.org/projects/tor/ticket/6894 https://trac.torproject.org/projects/tor/ticket/8170 If Chrome OS where to connect to Tor because of the new time sync feature of Tor, that makes connections to Tor less suspicious and adds more Tor clients. That isn't happening - they can't figure out a UX way to offer a full Tor client. They did ship Tor in their base OS for a while but basically the UI/UX issues made them remove the binary from the system - elly, my co-author on tlsdate was the one who ported it over and maintained it. Just sharing my thoughts. Not complaining. Whatever you decide, thanks for your work! :) I've commented on https://trac.torproject.org/projects/tor/ticket/6894 and I'll try to implement it after I write a proposal. All the best, Jacob ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Cicpa
On 04/17/2013 05:47 PM, krishna e bera wrote: On Wed, 17 Apr 2013 20:33:21 + andrewfriedman andrewfriedman...@gmail.com wrote: CiCpa just passed the house. Overwhelming support. Now it goes to the Senate. If this law passes, will it affect Tor? Well we loose right to use Tor? I don't know if this the right place for this, if not please tell me and I will post in the appropriate spot. I'm not sure if you're talking about the CyberSecurity bill (HR 624 or CISPA) but, if you are, it doesn't look like it passed today. They voted on a few amendments to it but not the main bill (unless I'm reading it totally wrong). http://clerk.house.gov/evs/2013/index.asp -- Anthony Papillion Advanced Data Concepts www.adcl.us ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [Tails-dev] secure and simple network time (hack)
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 ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
