13/01/11 04:28, Roger Dingledine: > If your Tor fetches its consensus from a directory authority, you're > in better shape, insofar as the directory authorities are probably not > your adversaries. But if we'd force this, we'd be distinguishable from other Tor clients to some extent, I suppose. > Relays do these directory fetches in the clear, though, due to an > earlier bug: https://trac.torproject.org/projects/tor/ticket/827 > so we're back to the authentication and integrity question there. Clients > set up a TLS connection first and tunnel their directory fetches over it, > so they're in slightly better shape. Do your LiveCD users always have > both ORPort set to 0? Yes, ORPort is set to 0 per default. However, a user could easily become and OR by fiddling around in Vidalia. > The better answer is for Tor clients to read the time out of the NETINFO > cells that are part of the v2 connection handshake we added in Tor > 0.2.0.x. See section 4.2 of tor-spec.txt: > https://git.torproject.org/tor/doc/spec/tor-spec.txt You mean that we should read this value when our Tor client makes its very first try to establish a connection to a directory server/mirror? How is this any safer than checking the consensus' valid-after/until values? The mirror we connect to could be compromised, and send us an appropriate timestamp and then replay any old consensus. > Using the data in NETINFO cells has been sitting on the todo list for > a while: > https://git.torproject.org/tor/doc/spec/proposals/149-using-netinfo-data.txt > but nobody's moved it forward. Perhaps somebody wants to pick this up > and do it? :) I'm not sure I understand this proposition (alternatively I don't understand NETINFO cells). It says we don't want to simply trust the NETINFO cell timestamp and IP address blindly, but instead we want some sort of majority "vote" based on the NETINFO cell values of several nodes. I can understand how that makes sense for the timestamp, but the IP address? My understanding is that when a node sends a NETINFO cell, its IP address value should be the sending node's real IP address. Hence, how can looking at other nodes' NETINFO cells help validating the IP address? They should all be pair-wise different. > Also, ideally you want to get an opinion from more than one directory > authority. One design that I could imagine would be to, if we find a > directory mirror or entry guard whose time disagrees with us, connect > to a directory authority to get a stronger opinion. If the directory > authority also disagrees, connect to a threshold of directory authorities > and then memorize our relative clock skew based on the majority vote. How do you propose we'd do this? Remember: we have no directory information when we want to set the time, and the time needs to be set before we get the consensus (otherwise we cannot trust it). Is this a catch-22?
Attachment:
signature.asc
Description: OpenPGP digital signature