Re: [Tails-dev] Secure way to set time using Hidden Service descriptors
Hi, [please don't Cc me, I read the list] It seems that this has slipped through the cracks... sorry! ban...@openmailbox.org wrote (12 Sep 2014 01:04:41 GMT) : The current secure timesyncing solution has some serious implications for security because they rely on an untrusted model using clearnet servers. Even though SSL is used, the broken CA model negates its protection and the adversary could easily MITM requests and send fake replies or potentially exploit the time synchronizer process running on the system. I assume you're talking of the htpdate part of our current time synchronization solution, since it's the only part where your note about the CA cartel makes sense as far as I understand it. Note that those connections go through a Tor SocksPort that thas the IsolateDestAddr and IsolateDestPort options enabled. So, to perform such an attack via MitM against htpdate's connections, an adversary will need to do that in several places at the same time; quoting the corresponding bits of our design doc: It also uses several different pools of time sources, and if there are too many that fail for any given pool, e.g. because of failed certificate checking or being unreachable, the pool is considered to be potentially compromised and htpdate aborts. I easily admit I didn't think very hard about it, but given this, I fail to see how an attacker can easily MITM those requests in a way that effectively affects a running Tails much. Am I missing something, or did you overlook this aspect? Use of Hidden Service descriptors to obtain more accurate time: [...] Thanks a lot for thinking through this potential other solution. How does it play with the next-generation (ahem) time sync'ing design we have in mind? It's described there: https://tails.boum.org/blueprint/robust_time_syncing/ Note that in this new design, htpdate is only used to detect replayed Tor consensus. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Secure way to set time using Hidden Service descriptors
Hi Intrigeri, a lot has happened in this space since I last posted. The Hidden Service descriptor proposal didn't make sense so we query Hidden services directly and extract timestamps from their HTTP headers. At the moment in Whonix, we use reputable Onion Sites exclusively for time syncing purposes. The reason we stayed away from clearnet + HTTPS is because its almost certain NSA and friends have burrowed their way into CAs trusted by browsers. These guys bribe their way into companies and deploy field gents to sabotage and steal keys. Its a given that they go after CAs. With clearnet SSL being useless, they can manipulate system time, or worse, exploit the system if there’s a bug in sdwdate/htpdate. You can see the list of sites we are now using over here: https://github.com/Whonix/sdwdate/blob/master/etc/sdwdate.d/30_sdwdate_default We integrated anondate (our version of tordate) in our timesync process but only as an extra plugin for time sanity checking. The plugin is not operational yet AFAIK. On 06/10/2015 04:48 PM, intrigeri wrote: Hi, [please don't Cc me, I read the list] It seems that this has slipped through the cracks... sorry! ban...@openmailbox.org wrote (12 Sep 2014 01:04:41 GMT) : The current secure timesyncing solution has some serious implications for security because they rely on an untrusted model using clearnet servers. Even though SSL is used, the broken CA model negates its protection and the adversary could easily MITM requests and send fake replies or potentially exploit the time synchronizer process running on the system. I assume you're talking of the htpdate part of our current time synchronization solution, since it's the only part where your note about the CA cartel makes sense as far as I understand it. Note that those connections go through a Tor SocksPort that thas the IsolateDestAddr and IsolateDestPort options enabled. So, to perform such an attack via MitM against htpdate's connections, an adversary will need to do that in several places at the same time; quoting the corresponding bits of our design doc: It also uses several different pools of time sources, and if there are too many that fail for any given pool, e.g. because of failed certificate checking or being unreachable, the pool is considered to be potentially compromised and htpdate aborts. I easily admit I didn't think very hard about it, but given this, I fail to see how an attacker can easily MITM those requests in a way that effectively affects a running Tails much. Am I missing something, or did you overlook this aspect? Use of Hidden Service descriptors to obtain more accurate time: [...] Thanks a lot for thinking through this potential other solution. How does it play with the next-generation (ahem) time sync'ing design we have in mind? It's described there: https://tails.boum.org/blueprint/robust_time_syncing/ Note that in this new design, htpdate is only used to detect replayed Tor consensus. Cheers, ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Secure way to set time using Hidden Service descriptors
On Wed 2015-06-10 15:07:17 -0400, bancfc wrote: The Hidden Service descriptor proposal didn't make sense so we query Hidden services directly and extract timestamps from their HTTP headers. Which hidden service operators do you query? what counts as a reputable Onion Site ? Do those operators know that you're relying on their HTTP headers? At the moment in Whonix, we use reputable Onion Sites exclusively for time syncing purposes. The reason we stayed away from clearnet + HTTPS is because its almost certain NSA and friends have burrowed their way into CAs trusted by browsers. These guys bribe their way into companies and deploy field gents to sabotage and steal keys. Its a given that they go after CAs. With clearnet SSL being useless, they can manipulate system time, or worse, exploit the system if there’s a bug in sdwdate/htpdate. Far be it from me to defend the CA system (i agree that it is broken, though i'm not convinced that it's broken in the ways you're describing), but i'm not sure that the solution you're advocating as an alternative is a significant improvement, given the state of hidden services and the risk of correlation attacks against their users. Have you read: https://conference.hitb.org/hitbsecconf2015ams/sessions/non-hidden-hidden-services-considered-harmful-attacks-and-detection/ If your concern is about malicious CA certifications, why not instead restrict your https-based date updates to https sites that use HPKP to protect against attacks from non-pinned CAs? If your concern is attacks from the pinned CAs, you could add an increased dependence on certificate-transparency as well, though that would likely take more engineering effort. Regards, --dkg ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Secure way to set time using Hidden Service descriptors
The current secure timesyncing solution has some serious implications for security because they rely on an untrusted model using clearnet servers. Even though SSL is used, the broken CA model negates its protection and the adversary could easily MITM requests and send fake replies or potentially exploit the time synchronizer process running on the system. To overcome this, here is a suggestion for a reassessment of the tordate approach, to overcome the problems mentioned above and the shortcomings. Use of Hidden Service descriptors to obtain more accurate time: There are some problems with using Directory Authority consensus data, the only one IMO is the fuzzy window of three hours which makes it harder to set a realistic time. My proposal is to have a time synchronizer daemon query the DHT for specific Hidden Service descriptors from the HSDir Authorities without actually connecting to them and calculate a more finegrained time to set. Here is why i think its a good idea: * Descriptors contain a timestamp field which shows the time they are generated. Time reported is number of microseconds since 1970. * Descriptors are signed by the HS and cannot be spoofed by the HSDirAuth. * Descriptors are refreshed hourly. [1] * A malicious HS that want to fool our time check has to go out of its way and forge the timestamp in its descriptor. If they are doing this by just running with a wrong clock, they will make themselves inaccessible. * According to rend-spec, the damage is much limited (only and 18 hour window) before HSDir Authorities reject these forgeries. [2] * There does exist stable, available and friendly HS besides the TPO one that was taken down. The only addresses that will be used are those of trusted organizations that will not carry out the forging attacks described above. These will be Whistleblowing and Freedom friendly sites. Some suggestions: Wikileaks, RiseUp (each service they provide has a unique HS address assigned), TheNewyorker's SecureDrop service and probably more. * The way to go about this is to fetch descriptors without connecting. * The timestamps will be averaged to get a more accurate reading. A high time resolution is possible, we can pinpoint within that one hour range the probable time because each server was started at a different time than the other so it uploads its descriptor at asynchronously. With 1400 HSAuth Dirs on the network, I don't think there will be much of a load problem. Problems and solutions: Couldn't the consensus data be replayed? Not possible if forcing Tor to depend only on verified consensus data. Tor doesn't depend on CAs and SSL is safe from cryptanalysis meaning no MITM attack is possible when communication with DirAuths But what if a bridge feeds the client a stale consensus? We have come up with a technique to check against this very kind of attack. In short, it involves fetching consensus data through the Tor bridge connection and cross referencing it with what the bridge gave us. If its off, the user will be warned and the stale data will be replaced by the fresh set. Then after Tor connects the time is further adjusted using HS descriptors. Won't this give off a fingeprintable network pattern when Tor restarts after a failed connection because the fresh consensus hadn't been fetched? There is no reason to believe that these actions are different from any Tor that is used in common setups. If someone suspends their machine and Tor is running, there will be TCP connections are frozen in the middle. And by the time they continue after a resume, the other side will receive unexpected packets and reject them. (It thought the other side timed out, now suddenly a closed connection wants to continue as if nothing happened.) Freezing a TAILS session should result in the same situation as freezing TBB on any other supported host. [1] http://donncha.is/2013/05/trawling-tor-hidden-services/ [2] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.txt ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
