Re: [Tails-dev] Risks of enabled/disabled TCP timestamps?
Hi, I was a bit sad that the TCP timestamps thing went nowhere, after the energy we've put into discussing it, so I've built an ISO with the corresponding branch merged in, and successfully run the automated test suite on it. So, at least we now know it doesn't break too much stuff in obvious ways. Good! But that's not enough to merge this branch: intrigeri wrote (07 Jan 2014 23:12:31 GMT) : I'll come back to you and Jacob for the design doc phrasing, as I'm still not convinced we can put statements as bold as tracking the clock down to the millisecond in there, without thinking a bit about how an attacker is affected by the network lag between the time a TCP timestamp was created, and the time when they get to see the packet. I mean, I'm weak at stats and all and you probably know better, but learning that some unknown time ago, the system clock was T with a millisecond precision does not really give me the current system clock with a millisecond precision, does it? This still needs some input. Now known as #6581. This is still waiting for some input from those who are confident that disabling TCP timestamps buys us much, and feel able to phrase it in a way that's suitable for our design doc. Once we have that phrasing, I volunteer to integrate it into the design doc and propose a branch. Any taker? 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] Risks of enabled/disabled TCP timestamps?
On 7/27/14, intrigeri intrig...@boum.org wrote: Hi, I was a bit sad that the TCP timestamps thing went nowhere, after the energy we've put into discussing it, so I've built an ISO with the corresponding branch merged in, and successfully run the automated test suite on it. So, at least we now know it doesn't break too much stuff in obvious ways. Good! Ok. Great! But that's not enough to merge this branch: intrigeri wrote (07 Jan 2014 23:12:31 GMT) : I'll come back to you and Jacob for the design doc phrasing, as I'm still not convinced we can put statements as bold as tracking the clock down to the millisecond in there, without thinking a bit about how an attacker is affected by the network lag between the time a TCP timestamp was created, and the time when they get to see the packet. I mean, I'm weak at stats and all and you probably know better, but learning that some unknown time ago, the system clock was T with a millisecond precision does not really give me the current system clock with a millisecond precision, does it? This still needs some input. Now known as #6581. Ok. I'll comment on #6581 shortly. This is still waiting for some input from those who are confident that disabling TCP timestamps buys us much, and feel able to phrase it in a way that's suitable for our design doc. Once we have that phrasing, I volunteer to integrate it into the design doc and propose a branch. Any taker? Yes, I'm on it. All the best, Jacob ___ 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] Risks of enabled/disabled TCP timestamps?
Hi, jvoisin started doing it -- now known as #6580. Julien made it clear on IRC that he won't be able to take care of this in time for 0.23. Any taker? Julien, do you think you can handle that in time for 1.2 (likely freezing in September or October), e.g. during the HackFest? 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] Risks of enabled/disabled TCP timestamps?
On 06/21/2014 04:00 PM, intrigeri wrote: Hi, jvoisin started doing it -- now known as #6580. Julien made it clear on IRC that he won't be able to take care of this in time for 0.23. Any taker? Julien, do you think you can handle that in time for 1.2 (likely freezing in September or October), e.g. during the HackFest? First, I (we?) need to fix the Vagrant building process ;) 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] Risks of enabled/disabled TCP timestamps?
Patrick Schleizer wrote (16 Feb 2014 18:44:07 GMT) : TCP timestamps are created using the systems clock, is that correct? That's also my understanding. Would it make sense to, - when Tails starts: save system clock - before Tor starts: randomize system clock (+/- a random amount of milliseconds [and seconds?]) - when Tails is shut down: undo system clock randomization ? That should at least prevent linkage between Tails and non-Tails sessions? ... but it would not prevent linkability between different actions done in a single Tails session. More generally, I doubt it's worth working on this before $someone has tried running Tails with TCP timestamps disabled, since it would be a trivial way to solve all this and more. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ 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] Risks of enabled/disabled TCP timestamps?
Hi, TCP timestamps are created using the systems clock, is that correct? Would it make sense to, - when Tails starts: save system clock - before Tor starts: randomize system clock (+/- a random amount of milliseconds [and seconds?]) - when Tails is shut down: undo system clock randomization ? That should at least prevent linkage between Tails and non-Tails sessions? Cheers, Patrick ___ 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] Risks of enabled/disabled TCP timestamps?
Hi, intrigeri wrote (07 Jan 2014 23:12:31 GMT) : intrigeri wrote (05 Jan 2014 12:09:06 GMT) : intrigeri wrote (23 Dec 2013 09:15:53 GMT) : Care to file a ticket, drop a tcp_timestamps.conf into config/chroot_local-includes/etc/sysctl.d/, and test the resulting ISO? Anyone? jvoisin started doing it -- now known as #6580. Julien made it clear on IRC that he won't be able to take care of this in time for 0.23. Any taker? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ 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] Risks of enabled/disabled TCP timestamps?
intrigeri wrote (05 Jan 2014 12:09:06 GMT) : intrigeri wrote (23 Dec 2013 09:15:53 GMT) : Care to file a ticket, drop a tcp_timestamps.conf into config/chroot_local-includes/etc/sysctl.d/, and test the resulting ISO? Anyone? jvoisin started doing it -- now known as #6580. I'll come back to you and Jacob for the design doc phrasing, as I'm still not convinced we can put statements as bold as tracking the clock down to the millisecond in there, without thinking a bit about how an attacker is affected by the network lag between the time a TCP timestamp was created, and the time when they get to see the packet. I mean, I'm weak at stats and all and you probably know better, but learning that some unknown time ago, the system clock was T with a millisecond precision does not really give me the current system clock with a millisecond precision, does it? This still needs some input. Now known as #6581. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Risks of enabled/disabled TCP timestamps?
intrigeri wrote (23 Dec 2013 09:15:53 GMT) : Care to file a ticket, drop a tcp_timestamps.conf into config/chroot_local-includes/etc/sysctl.d/, and test the resulting ISO? Anyone? I'll come back to you and Jacob for the design doc phrasing, as I'm still not convinced we can put statements as bold as tracking the clock down to the millisecond in there, without thinking a bit about how an attacker is affected by the network lag between the time a TCP timestamp was created, and the time when they get to see the packet. I mean, I'm weak at stats and all and you probably know better, but learning that some unknown time ago, the system clock was T with a millisecond precision does not really give me the current system clock with a millisecond precision, does it? This still needs some input. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Risks of enabled/disabled TCP timestamps?
jvoisin wrote (22 Dec 2013 19:46:18 GMT) : I agree with Jacob: I don't think Tails needs this features. TCP timestamps are defined in [RFC 1323](http://www.ietf.org/rfc/rfc1323.txt), entitled TCP Extensions for High Performance. Timestamps are used for: - Protection Against Wrapped Sequence Numbers, but in our case, I don't think that a normal Tails user could ever trigger a wrap, because as said in [RFC 1700](http://www.ietf.org/rfc/rfc1700.txt): The current recommended default time to live (TTL) for the Internet Protocol (IP) [45,105] is 64.. A user would need to send roughly 2^32 packets in one minute. - Round-Trip Time Measurement, only useful when the user manage to saturate the his connection. I don't think that the limiting factor for transmission speed is the capacity of the user connection when using Tails. I think timestamps can be safely disabled :) Thanks a lot for doing this research! Care to file a ticket, drop a tcp_timestamps.conf into config/chroot_local-includes/etc/sysctl.d/, and test the resulting ISO? I'll come back to you and Jacob for the design doc phrasing, as I'm still not convinced we can put statements as bold as tracking the clock down to the millisecond in there, without thinking a bit about how an attacker is affected by the network lag between the time a TCP timestamp was created, and the time when they get to see the packet. I mean, I'm weak at stats and all and you probably know better, but learning that some unknown time ago, the system clock was T with a millisecond precision does not really give me the current system clock with a millisecond precision, does it? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Risks of enabled/disabled TCP timestamps?
On 12/19/2013 10:56 PM, Jacob Appelbaum wrote: intrigeri: Hi, it was brought to our attention (thanks Jacob!) that TCP timestamps (net.ipv4.tcp_timestamps) are enabled in Tails, and this might be a problem. No problem. Glad to help, if it is actually helpful! In a nutshell, we're said that the risks that go with the current setting are: 1. The system uptime can be inferred from this information. That is correct. 2. The system clock can be tracked down to the millisecond. That is also correct. As far as I understand it, in the context of Tails, this can be done by an attacker who monitors the network somewhere between the attacked Tails system and the Tor entry nodes being used. Right? Yes. And due to a Tor issue (TLS itself), the absolute clock on the system is also leaked in the handshake. Nick has been working on fixing this - both in the IETF working group on TLS, in patches for OpenSSL and in other places, I think. When Nick finishes killing the gmt time leak in TLS, we'll still have one left in Tails: the TCP timestamp itself... :( This can be fixed upstream, in the kernel. The RFC says that the only requirement is that the timestamps must be incremented, but says nothing about the initial value. This will prevent the leak of the uptime. I must admit that I did not look closely enough, so in what follows, I'm assuming that this information is not forwarded by the three Tor hops to the other side of the connection. Please correct me if I'm wrong. Given such an attacker anyway knows the public IP used by the attacked system, I don't really get why Jacob calls this a Major privacy info leak. May you please clarify what exact threat you have in mind? I think the inverse issue is important to consider: look for clocks that match an expected value to _find_ the public IP used by a user. Off the top of my head, I can think of: a. Finding out how long a given Tails system has been running: if an attacker in this position got to watch the network (close enough to the attacked system) when it was bootstrapping Tor, then they can learn this too. I'm not overly concerned by this threat. There are currently two ways to do this that come to mind - one is by watching Tails traffic (first bootstrap, etc), the other is by looking at every TCP connection setup. This also ensures that non-Tails clients or different Tails clients behind a NAT will be distinguishable. It would be nice if a network of Tails machines behind a NAT looked like a single Tails machine other than the bootstrapping phase. b. Distinguishing several Tails systems running behind NAT and using the same IP address: I would call this a minor issue, and the same reasoning as in (a) applies. If there are four Tails clients behind a NAT, an attacker can probably distinguish them by TCP timestamp alone. A very quick web search seems to indicate that disabling TCP timestamps brings its own share of issues: first, disabling TCP timestamps also disables the TCP protection against wrapped sequence numbers mechanism; second, TCP timestamps seem to be a pretty useful performance feature of TCP. Do we need those features? I would prefer to not leak anything about the system at all. Currently, to recap: we leak the full clock and then millisecond offsets. This allows for unique tracking across the internet as well as unique host counting behind a NAT or similar networks that proxy traffic in various ways. I agree with Jacob: I don't think Tails needs this features. TCP timestamps are defined in [RFC 1323](http://www.ietf.org/rfc/rfc1323.txt), entitled TCP Extensions for High Performance. Timestamps are used for: - Protection Against Wrapped Sequence Numbers, but in our case, I don't think that a normal Tails user could ever trigger a wrap, because as said in [RFC 1700](http://www.ietf.org/rfc/rfc1700.txt): The current recommended default time to live (TTL) for the Internet Protocol (IP) [45,105] is 64.. A user would need to send roughly 2^32 packets in one minute. - Round-Trip Time Measurement, only useful when the user manage to saturate the his connection. I don't think that the limiting factor for transmission speed is the capacity of the user connection when using Tails. I think timestamps can be safely disabled :) That's why I am reluctant to disable this feature without knowing what exact problem we would solve. I'm all ears :) We'll make it harder to count Tails users behind a NAT, we'll make it so that Tails users who sleep their machines won't be tracked across networks, we'll make Nick's removal of gmt time from TLS complete for the Tails picture, and we'll remove a general side channel. All the best, Jacob ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev ___ tails-dev
Re: [Tails-dev] Risks of enabled/disabled TCP timestamps?
intrigeri: Hi, it was brought to our attention (thanks Jacob!) that TCP timestamps (net.ipv4.tcp_timestamps) are enabled in Tails, and this might be a problem. No problem. Glad to help, if it is actually helpful! In a nutshell, we're said that the risks that go with the current setting are: 1. The system uptime can be inferred from this information. That is correct. 2. The system clock can be tracked down to the millisecond. That is also correct. As far as I understand it, in the context of Tails, this can be done by an attacker who monitors the network somewhere between the attacked Tails system and the Tor entry nodes being used. Right? Yes. And due to a Tor issue (TLS itself), the absolute clock on the system is also leaked in the handshake. Nick has been working on fixing this - both in the IETF working group on TLS, in patches for OpenSSL and in other places, I think. When Nick finishes killing the gmt time leak in TLS, we'll still have one left in Tails: the TCP timestamp itself... :( I must admit that I did not look closely enough, so in what follows, I'm assuming that this information is not forwarded by the three Tor hops to the other side of the connection. Please correct me if I'm wrong. Given such an attacker anyway knows the public IP used by the attacked system, I don't really get why Jacob calls this a Major privacy info leak. May you please clarify what exact threat you have in mind? I think the inverse issue is important to consider: look for clocks that match an expected value to _find_ the public IP used by a user. Off the top of my head, I can think of: a. Finding out how long a given Tails system has been running: if an attacker in this position got to watch the network (close enough to the attacked system) when it was bootstrapping Tor, then they can learn this too. I'm not overly concerned by this threat. There are currently two ways to do this that come to mind - one is by watching Tails traffic (first bootstrap, etc), the other is by looking at every TCP connection setup. This also ensures that non-Tails clients or different Tails clients behind a NAT will be distinguishable. It would be nice if a network of Tails machines behind a NAT looked like a single Tails machine other than the bootstrapping phase. b. Distinguishing several Tails systems running behind NAT and using the same IP address: I would call this a minor issue, and the same reasoning as in (a) applies. If there are four Tails clients behind a NAT, an attacker can probably distinguish them by TCP timestamp alone. A very quick web search seems to indicate that disabling TCP timestamps brings its own share of issues: first, disabling TCP timestamps also disables the TCP protection against wrapped sequence numbers mechanism; second, TCP timestamps seem to be a pretty useful performance feature of TCP. Do we need those features? I would prefer to not leak anything about the system at all. Currently, to recap: we leak the full clock and then millisecond offsets. This allows for unique tracking across the internet as well as unique host counting behind a NAT or similar networks that proxy traffic in various ways. That's why I am reluctant to disable this feature without knowing what exact problem we would solve. I'm all ears :) We'll make it harder to count Tails users behind a NAT, we'll make it so that Tails users who sleep their machines won't be tracked across networks, we'll make Nick's removal of gmt time from TLS complete for the Tails picture, and we'll remove a general side channel. All the best, Jacob ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
