On 02/20/2012 03:31 PM, Maxim Kammerer wrote: > On Mon, Feb 20, 2012 at 22:30, Jacob Appelbaum <[email protected]> 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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
