Re: [tor-talk] secure and simple network time (hack)
adrelanos: Why was tlsdate written in C? There are a few reasons: The first prototype was in Python (patching tlslite) however, I wanted it to be portable without patching libraries Jailing and/or sandboxing is easier without a system wide interpreter eg: Python Droppings privileges is straight forward in C Setting capabilities is easier on a binary by binary basis This is easily solved for say, Golang programs. I wanted to directly interface with many relevant libraries Currently it supports polarSSL and OpenSSL - patches welcome C is a perfectly fine programming language - I've considered writing it again in Golang. I may make a feature for feature compatible version at some point in the future. 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] secure and simple network time (hack)
Gregory Disney: It's related to Linux NTP and SRTP. What? tlsdate has no relation to any such software. 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] secure and simple network time (hack)
Hi Elly, thanks for posting! The (slightly outdated now) time-sources design doc is here: https://docs.google.com/a/chromium.org/document/d/1ylaCHabUIHoKRJQWhBxqQ5Vck270fX7XCWBdiJofHbU/edit It has good thoughts. I am happy to answer any questions people have about this. I'll come back to that offer when questions come up. Cheers, adrelanos ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
It's related to Linux NTP and SRTP. On Fri, Apr 5, 2013 at 4:26 PM, intrigeri intrig...@boum.org wrote: Hi, Jacob Appelbaum wrote (19 Jul 2012 23:48:48 GMT) : intrigeri: So, Jake tells me that ChromeOS will use tlsdate by default, and that this should solve the fingerprinting issue. Therefore, I assume this implicitly answer the (half-rhetorical, I admit) question I asked in March, and I assume there is indeed some fingerprinting issue. So, in the following I'll assume it's relatively easy, for a close network adversary (say, my ISP) to detect that I'm using tlsdate. It isn't shipping yet, so we'll see what happens. I'm told ChromeOS ships it nowadays, so I'm excited at the idea to learn more about it, so that we can move forward a bit about the fingerprinting issue. I was not able to find any authoritative information about how they run it. Their time sources [1] design doc is quite clearly outdated. Where can I find up-to-date information on this topic? I assume one of the dozens of Chromius Git repositories [2], but which one? [1] http://www.chromium.org/developers/design-documents/time-sources [2] http://git.chromium.org/gitweb/ 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 mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
Hi, Jacob Appelbaum wrote (19 Jul 2012 23:48:48 GMT) : intrigeri: So, Jake tells me that ChromeOS will use tlsdate by default, and that this should solve the fingerprinting issue. Therefore, I assume this implicitly answer the (half-rhetorical, I admit) question I asked in March, and I assume there is indeed some fingerprinting issue. So, in the following I'll assume it's relatively easy, for a close network adversary (say, my ISP) to detect that I'm using tlsdate. It isn't shipping yet, so we'll see what happens. I'm told ChromeOS ships it nowadays, so I'm excited at the idea to learn more about it, so that we can move forward a bit about the fingerprinting issue. I was not able to find any authoritative information about how they run it. Their time sources [1] design doc is quite clearly outdated. Where can I find up-to-date information on this topic? I assume one of the dozens of Chromius Git repositories [2], but which one? [1] http://www.chromium.org/developers/design-documents/time-sources [2] http://git.chromium.org/gitweb/ 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
Re: [tor-talk] secure and simple network time (hack)
Den 19-07-2012 15:33, adrelanos skrev: grarpamp: Why don't we propose a clean solution for this time mess anyway? Is this that big of a deal? If a would be Tor user doesn't know what time it is and/or can't set their clock manually, they've got bigger issues to worry about. And given 90% of these users use windows, they're set via ntp by default (or rooted via other means) already. Yes, it's a big deal. First time asked System time in anonymity oriented LiveCDs. [1] Older than that: http://www.mail-archive.com/or-talk@freehaven.net/msg11031.html ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
Hi, adrelanos wrote (18 Jul 2012 18:37:18 GMT) : To make our life even worse... Sorry... But not using NTP and only emmiting Tor traffic is also pretty clearly Tails. Because that puts you in the group of users Uses Tor, nothing else, but does not use NTP? How many people act like this?. So you should at least emmit a fake NTP query (when others that usuaally do) and drop it. This is indeed true for a non-shared public IP, and is mitigated to some degree when sharing an IP (e.g. behind home router NAT, concurrently with others non-Tails systems). Looks like we'll need to think a bit more what kind of fingerprinting resistance a system like Tails can reasonably pretend to at this scale. (I'm re-adding the Cc to tails-dev, that was lost at some point. Please don't drop it again.) 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
Re: [tor-talk] secure and simple network time (hack)
Hi, Jacob Appelbaum wrote (19 Jul 2012 23:48:48 GMT) : The key difference with htpdate is that one has a cryptographic signature. I'll take a subset of possible MITM attackers over fully trusting something that anyone could MITM. I think this is wrong in the context of Tails. There are a few pieces of software called htpdate, and the one Tails uses only connects to HTTPS servers, and delegates to wget the X.509 certificates validation: https://tails.boum.org/contribute/design/Time_syncing/#index3h2 In addition, the pal/foe/neutral pool system Tails uses gives *some* protection against untrustworthy sources of time information, which limits what one can do with only a few illegitimate X.509 certificates they got from a trusted CA: https://tails.boum.org/contribute/design/Time_syncing/#index4h2 Thanks a lot for your detailed answer! I'll think about the rest later. 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
Re: [tor-talk] secure and simple network time (hack)
intrigeri: Hi, adrelanos wrote (18 Jul 2012 18:37:18 GMT) : To make our life even worse... Sorry... But not using NTP and only emmiting Tor traffic is also pretty clearly Tails. Because that puts you in the group of users Uses Tor, nothing else, but does not use NTP? How many people act like this?. So you should at least emmit a fake NTP query (when others that usuaally do) and drop it. This is indeed true for a non-shared public IP, and is mitigated to some degree when sharing an IP (e.g. behind home router NAT, concurrently with others non-Tails systems). Yes. Looks like we'll need to think a bit more what kind of fingerprinting resistance a system like Tails can reasonably pretend to at this scale. Don't give up too early. Man ntpdate says there is -q Query only - don't set the clock.. That's perfect for a fake NTP query. I just haven't found out how to tell ntpd to do the same. That is required for a good fake. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
intrigeri: There are a few pieces of software called htpdate, and the one Tails uses only connects to HTTPS servers, and delegates to wget the X.509 certificates validation: https://tails.boum.org/contribute/design/Time_syncing/#index3h2 Unfortunately wget (nor any other command line downloader) doesn't support to pin the certificate of the website. https://lists.gnu.org/archive/html/bug-wget/2012-07/msg7.html So it still depend on the flawed root CA system. (Don't take this too harsh. Although there is space for improvement I seriously consider adding tails_htp to aos. Thanks to the distributed trust model, I think it's currently the safest method.) In addition, the pal/foe/neutral pool system Tails uses gives *some* protection against untrustworthy sources of time information, which limits what one can do with only a few illegitimate X.509 certificates they got from a trusted CA: https://tails.boum.org/contribute/design/Time_syncing/#index4h2 If I understand correctly, you pick three random servers. One from each pool. And then build the mediate of the three. What's the point of asking the foe pool? (Servers which generally do not care about privacy.) Why doesn't tails_htp ask more than three servers for the time and build the mediate? Like 6, 9 or 12. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
Why don't we propose a clean solution for this time mess anyway? Is this that big of a deal? If a would be Tor user doesn't know what time it is and/or can't set their clock manually, they've got bigger issues to worry about. And given 90% of these users use windows, they're set via ntp by default (or rooted via other means) already. Yes, no UDP via Tor. So once said hapless user manages to get their clock set and strapped up, just scrape it off google or some internal consensus once a half interval and be done with it. In fact, since afaik Tor's entire trust is based on what the top level dir auths say, all other nodes besides auths likely have no need to consider time... just sigs. Even auths might not need to either... rather, just publish good timestamps for recordkeeping (exonerator, stats, etc) is all. Last, is using Tails (or any OS for that matter) somehow going to get you more blocked than blocked (or dead than dead) than for already using Tor? Doubt it. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
grarpamp: Why don't we propose a clean solution for this time mess anyway? Is this that big of a deal? If a would be Tor user doesn't know what time it is and/or can't set their clock manually, they've got bigger issues to worry about. And given 90% of these users use windows, they're set via ntp by default (or rooted via other means) already. Yes, it's a big deal. First time asked System time in anonymity oriented LiveCDs. [1] We can't solve the problems with Windows and compromised Windows machines. This solution is needed for pepole who really care about security / anonymity. People who are interested in Tails, Liberte Linux or aos. These projects are interested in a solution. Setting time manually is really inconvinient. In fact, since afaik Tor's entire trust is based on what the top level dir auths say, There is a ticket from a Tor dev to change this. all other nodes besides auths likely have no need to consider time... just sigs. Even auths might not need to either... rather, just publish good timestamps for recordkeeping (exonerator, stats, etc) is all. Time is important. Since (for example) javascript can read it, an adversary controlled time skew can de-anonymize. Also read Steven J. Murdoch's paper about clock skew. Good for introduction as well. [2] Last, is using Tails (or any OS for that matter) somehow going to get you more blocked than blocked (or dead than dead) than for already using Tor? Doubt it. What do you want to say with more blocked than blocked? I doubt Tails is dead given the number of users and dev activity. [1] https://lists.torproject.org/pipermail/tor-talk/2011-January/008849.html [2] https://tails.boum.org/contribute/design/Time_syncing/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
Hey hey, intrigeri: Hi, intrigeri wrote (25 Mar 2012 23:02:55 GMT) : Jacob Appelbaum wrote (20 Feb 2012 20:30:08 GMT) : For a while I've been interested in secure network time that would be useful for Tor users. Tor users generally need accuracy to the hour in the local system clock. Thank you for tackling this problem. ... and thank you for going on with it! As a result, I've also written another tool, tlsdate[1], that I regularly use for setting my own clock. What network fingerprint does tlsdate currently display if I run it in the clear, without forwarding its traffic through Tor? Jake asked me to have another look at tlsdate, which was uploaded to Debian, so here it goes :) (It's pretty clear I lack much of the background and intended usecase, so please correct whatever is wrong in what follows!) So, Jake tells me that ChromeOS will use tlsdate by default, and that this should solve the fingerprinting issue. Therefore, I assume this implicitly answer the (half-rhetorical, I admit) question I asked in March, and I assume there is indeed some fingerprinting issue. So, in the following I'll assume it's relatively easy, for a close network adversary (say, my ISP) to detect that I'm using tlsdate. It isn't shipping yet, so we'll see what happens. From what I remember from our past attempts to discuss this on IRC, I assume the intended usecase for Tails is to run tlsdate in the clear (that is, without going through Tor) so that the clock is set before Tor is started. There are a few use cases - the first is to use it with the -t option - this at least will skip the clock forward to a recent build time. So if previously, the clock was in 1970, you're at least now in the same decade as the tails release. Probably the same year and likely, with a few releases a year, the same month. That has no network access at all. The next use case is to use it over Tor - I haven't added direct proxy support yet but I'll do so when it becomes a blocking issue. As it stands now, you can easily just `usewithtor tlsdate` and it will work fine. This gives you the ability to securely set your clock over Tor. Another use case is to fire it up against any SSL/TLS enabled server, including the Tor relay you were going to use anyway, and attempt to use it as a time source. If you use a Tor relay, tlsdate currently lacks a way to verify the key for that relay - so it's a leap of faith, rather than a leap of cryptographic something or other. But at the very least, you no longer need to involve any third party that you weren't already going to connect to - it isn't more secure, it's just a cute hack. The most common way for me to use tlsdate is to connect to a popular TLS server and if I trust the CA, which can be pinned to a *single* CA that isn't part of the traditional cartel, I can easily trust it. Generally, I find that this works fine. If so, from the PoV of a close network adversary, if Tails starts to use tlsdate in the clear, as a Tails user, then I'm part of the set of people who run tlsdate and start Tor soon after, and in the current state of things, this set would almost exactly match the set of Tails users. That might be true - that's a good reason to add Tor tls fingerprint verification to tlsdate - however, I'd take this fingerprinting risk over a older consensus or Tor simply not working at all. The fact that ChromeOS uses tlsdate forces this kind of adversaries to detect tlsdate followed by Tor, instead of merely detecting tlsdate alone, in order to detect Tails users. (Looks like we have to convince Google to run Tor by default on ChromeOS? :) Tor has been ported to ChromeOS as far as I know - I have talked with them about adding a guest mode that uses Tor. Therefore, I'm not convinced tlsdate in the clear would be any better, on the fingerprinting side of things, than the htpdate in the clear system we eventually managed to escape in Tails 0.9 and later. Which means it looks quite worse, fingerprinting-wise, than what we currently ship. The key difference with htpdate is that one has a cryptographic signature. I'll take a subset of possible MITM attackers over fully trusting something that anyone could MITM. Furthermore, I think that you're making a trade-off between fingerprinting on the network, which Tor does not even try to address by default, and the ability for someone to try to use Tor with an incorrect clock, something that explicitly doesn't work in the Tor design. In an ideal world, Tor will learn the clock anonymously and not care about the system time. We're not there yet; patches are always welcome! Thoughts? (Seriously, please prove me wrong, my life would be easier as a result :) I generally think that shipping tlsdate makes sense, especially if Tor is already running as you can then keep clocks securely in sync. It may not make sense for first boot, other than to at least move it forward with `tlsdate -t`;
Re: [tor-talk] secure and simple network time (hack)
adrelanos: To make our life even worse... Sorry... But not using NTP and only emmiting Tor traffic is also pretty clearly Tails. Because that puts you in the group of users Uses Tor, nothing else, but does not use NTP? How many people act like this?. So you should at least emmit a fake NTP query (when others that usuaally do) and drop it. Indeed. 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] secure and simple network time (hack)
Hi, intrigeri wrote (25 Mar 2012 23:02:55 GMT) : Jacob Appelbaum wrote (20 Feb 2012 20:30:08 GMT) : For a while I've been interested in secure network time that would be useful for Tor users. Tor users generally need accuracy to the hour in the local system clock. Thank you for tackling this problem. ... and thank you for going on with it! As a result, I've also written another tool, tlsdate[1], that I regularly use for setting my own clock. What network fingerprint does tlsdate currently display if I run it in the clear, without forwarding its traffic through Tor? Jake asked me to have another look at tlsdate, which was uploaded to Debian, so here it goes :) (It's pretty clear I lack much of the background and intended usecase, so please correct whatever is wrong in what follows!) So, Jake tells me that ChromeOS will use tlsdate by default, and that this should solve the fingerprinting issue. Therefore, I assume this implicitly answer the (half-rhetorical, I admit) question I asked in March, and I assume there is indeed some fingerprinting issue. So, in the following I'll assume it's relatively easy, for a close network adversary (say, my ISP) to detect that I'm using tlsdate. From what I remember from our past attempts to discuss this on IRC, I assume the intended usecase for Tails is to run tlsdate in the clear (that is, without going through Tor) so that the clock is set before Tor is started. If so, from the PoV of a close network adversary, if Tails starts to use tlsdate in the clear, as a Tails user, then I'm part of the set of people who run tlsdate and start Tor soon after, and in the current state of things, this set would almost exactly match the set of Tails users. The fact that ChromeOS uses tlsdate forces this kind of adversaries to detect tlsdate followed by Tor, instead of merely detecting tlsdate alone, in order to detect Tails users. (Looks like we have to convince Google to run Tor by default on ChromeOS? :) Therefore, I'm not convinced tlsdate in the clear would be any better, on the fingerprinting side of things, than the htpdate in the clear system we eventually managed to escape in Tails 0.9 and later. Which means it looks quite worse, fingerprinting-wise, than what we currently ship. Thoughts? (Seriously, please prove me wrong, my life would be easier as a result :) 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
Re: [tor-talk] secure and simple network time (hack)
intrigeri: If so, from the PoV of a close network adversary, if Tails starts to use tlsdate in the clear, as a Tails user, then I'm part of the set of people who run tlsdate and start Tor soon after, and in the current state of things, this set would almost exactly match the set of Tails users. Yes. The fact that ChromeOS uses tlsdate forces this kind of adversaries to detect tlsdate followed by Tor, instead of merely detecting tlsdate alone, in order to detect Tails users. (Looks like we have to convince Google to run Tor by default on ChromeOS? :) (Even if, wouldn't help. That would put you into the group of users who run tlsdate followed by Tor followed by Tor traffic (Tails) compared to users who run tlsdate followed by Tor, with almost no traffic. :) Therefore, I'm not convinced tlsdate in the clear would be any better, on the fingerprinting side of things, than the htpdate in the clear system we eventually managed to escape in Tails 0.9 and later. Which means it looks quite worse, fingerprinting-wise, than what we currently ship. Thoughts? Better don't run any htp/tlsdate traffic in the clear. As a future proof solutoin... In future there might sophisticated steganograpic obfsproxy transports and the clear htp/tlsdate traffic would ruin that. Why don't we propose a clean solution for this time mess anyway? As first step can we open the neccessary tickets? And as a second step gsoc, sponsor, bounty or whatever. Idea... Can Tor code be changed to not to depend on clock? What other solutions exist do solve that cleanly? To make our life even worse... Sorry... But not using NTP and only emmiting Tor traffic is also pretty clearly Tails. Because that puts you in the group of users Uses Tor, nothing else, but does not use NTP? How many people act like this?. So you should at least emmit a fake NTP query (when others that usuaally do) and drop it. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
Hi, Jacob Appelbaum wrote (20 Feb 2012 20:30:08 GMT) : For a while I've been interested in secure network time that would be useful for Tor users. Tor users generally need accuracy to the hour in the local system clock. Thank you for tackling this problem. As a result, I've also written another tool, tlsdate[1], that I regularly use for setting my own clock. What network fingerprint does tlsdate currently display if I run it in the clear, without forwarding its traffic through Tor? 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] secure and simple network time (hack)
Hi, For a while I've been interested in secure network time that would be useful for Tor users. Tor users generally need accuracy to the hour in the local system clock. That kind of clock accuracy is pretty easy to achieve with a few different hacks. Some people have taken to setting clocks with HTTP headers but I think that's a nightmare - not only because people will parse the header with questionable code but also because of latency, amongst other things. I've implemented a bunch of network time checks[0] just for fun and the tool I wrote, teatime, is useful for looking at a server for timing information. It's just a tool for poking at systems and it's not meant to be more than an experimental tool. Feel free to submit patches for other ways to extract system time from servers types. I decided that the most reliable time channel worth using was SSL/TLS. As a result, I've also written another tool, tlsdate[1], that I regularly use for setting my own clock. It has some drawbacks. For example - it only has accuracy to the second and it uses an unintentional time channel in the TLS protocol itself. The TLS spec actually says that the ServerHello and ClientHello should contain the system time of the respective system. These records are covered by the TLS security properties - assuming the connection is somehow authenticated. Currently tlsdate only has one way to verify certificates to ensure that the connection is secure - namely, it's the usual CA racket. That's secure for certain values of secure and I think it's more secure than just running `ntpdate time.apple.com` or `rdate example.com`; any thoughts on this are welcome. Furthermore, tlsdate is parasitic - so you can easily set your clock off of https://encrypted.google.com or any other SSL/TLS enabled server. tlsdate has seen a lot of auditing and these days, it's been hacked on quite extensively by Christian Grothoff with a few minor patches from others - we'd love further people to audit the tool. I'd love some code review but also just some feedback. Would you want it to run as a system daemon? Would it be useful if it could take a list of hundreds of hosts or randomly test IP addresses? Should we extend the tool to work with STARTTLS services too? All the best, Jacob [0] https://github.com/ioerror/teatime [1] https://github.com/ioerror/tlsdate ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
On Mon, Feb 20, 2012 at 22:30, Jacob Appelbaum ja...@appelbaum.net wrote: Some people have taken to setting clocks with HTTP headers but I think that's a nightmare - not only because people will parse the header with questionable code but also because of latency, amongst other things. What questionable code? HTTP Date: header is standard (RFC 1123). HTPDate (C version) [1] does a rather good job of maintaining time from such headers, and with an obvious header parsing vulnerability fix and some improvements / feature additions [2] it is used in Liberté Linux without issues. The only downside is lack of https support. [1] http://www.clevervest.com/htp/ [2] https://github.com/mkdesu/liberte/blob/master/src/usr/local/portage/net-misc/htpdate/files/htpdate-1.0.4-robustness.patch Currently tlsdate only has one way to verify certificates to ensure that the connection is secure - namely, it's the usual CA racket. Does it mean that verification will fail if the clock is several years behind, for instance? I'd love some code review but also just some feedback. Does become_nobody() drop group privileges as well? Is operation over Tor supported (I don't see any proxy handling)? -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] secure and simple network time (hack)
On 02/20/2012 03:31 PM, Maxim Kammerer wrote: On Mon, Feb 20, 2012 at 22:30, Jacob Appelbaum ja...@appelbaum.net wrote: Some people have taken to setting clocks with HTTP headers but I think that's a nightmare - not only because people will parse the header with questionable code but also because of latency, amongst other things. What questionable code? HTTP Date: header is standard (RFC 1123). Whenever you parse a thing, there is code to do the parsing. That's the code that is questionable. For tlsdate, I cast a few bytes as an integer. It's well, quite straight forward to audit. HTPDate (C version) [1] does a rather good job of maintaining time from such headers, and with an obvious header parsing vulnerability fix and some improvements / feature additions [2] it is used in Liberté Linux without issues. The only downside is lack of https support. Totally unrelated to HTPDate - without https support, I think it suffers from a pretty serious problem: it isn't securely transfering the data from the server or authenticating it. I haven't audited HTPDate but I generally think that using the TLS data provides for all of the properties I'd want and almost zero issues that I don't. [1] http://www.clevervest.com/htp/ [2] https://github.com/mkdesu/liberte/blob/master/src/usr/local/portage/net-misc/htpdate/files/htpdate-1.0.4-robustness.patch Currently tlsdate only has one way to verify certificates to ensure that the connection is secure - namely, it's the usual CA racket. Does it mean that verification will fail if the clock is several years behind, for instance? It might. It depends. I have some things in the works to solve this issue. One idea that I've been toying with is to include a few hard coded times - compile time as an epoch, rather than 1970, recent time fetches rather than 1970 and so on. This will work securely with a clock drift of years but probably not forty years. I'd love some code review but also just some feedback. Does become_nobody() drop group privileges as well? It should eventually. It did at one point. I think right now that it does not. I think that's a vote for doing so again. :) Is operation over Tor supported (I don't see any proxy handling)? If you `usewithtor` it should work without issues. All the best, Jacob ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
