On Mon, Jan 31, 2011 at 9:50 PM, Nick Mathewson <ni...@freehaven.net> wrote: > certificates. The security properties of this protocol are just > fine; the problem was that our behavior of sending > two-certificate chains made Tor easy to identify.
Actually, two (or more) certificates are very common when talking to HTTPS servers. (See mail.google.com:443 for example.) > And the cell-based part of the V3 handshake, in summary, is: > > C<->S: TLS handshake where S sends a "v3 certificate" > > In TLS: > > C->S: VERSIONS cell > S->C: VERSIONS cell, CERT cell, AUTH_CHALLENGE cell, NETINFO cell > > C->S: Optionally: CERT cell, AUTHENTICATE cell Forgive my ignorance here. I have only a passing knowledge of the Tor protocol these days. If you wish to prevent scanning for Tor nodes then you could have the client put the SHA256 of the server's identity key in its initial cell. This supposes that the client always knows the identity of the server that it's connecting to; which may not be the case. If the client doesn't care about authenticating to the server, then it could optimistically send cells predicated on a correct version prediction. SSH does this (see RFC 4253, section 7.1, 'first_kex_packet_follows'). The server will know if the prediction was correct once it sees the client's version and can discard optimistic cells. AGL -- Adam Langley a...@imperialviolet.org http://www.imperialviolet.org
