Proposal 176: Proposed version-3 link handshake for Tor

[Adam Langley]

On Mon, Jan 31, 2011 at 9:50 PM, Nick Mathewson <nickm at 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 agl at imperialviolet.org http://www.imperialviolet.org