From f77d56b93eb8aada52e9098213778d047f47c665 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Fri, 26 Jan 2007 06:08:05 +0000 Subject: r11521@catbus: nickm | 2007-01-26 01:07:55 -0500 Split tor-spec-v2 and dir-voting into component proposals. svn:r9417 --- proposals/105-handshake-revision.txt | 74 ++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 proposals/105-handshake-revision.txt (limited to 'proposals/105-handshake-revision.txt') diff --git a/proposals/105-handshake-revision.txt b/proposals/105-handshake-revision.txt new file mode 100644 index 0000000..b718ec4 --- /dev/null +++ b/proposals/105-handshake-revision.txt @@ -0,0 +1,74 @@ + + Version negotiation for the Tor protocol. + + +1.0. Version numbers + + The node-to-node TLS-based "OR connection" protocol and the multi-hop + "circuit" protocol are versioned quasi-independently. (Certain versions + of the circuit protocol may require a minimum version of the connection + protocol to be used.) + + Version numbers are incremented for backward-incompatible protocol changes + only. Backward-compatible changes are generally implemented by adding + additional fields to existing structures; implementations MUST ignore + fields they do not expect. + + +2.1. VERSIONS cells + + When a Tor connection is established, both parties normally send a + VERSIONS cell before sending any other cells. (But see below.) + + NumVersions [1 byte] + Versions [NumVersions bytes] + + "Versions" is a sequence of NumVersions link connection protocol versions, + each one byte long. Parties should list all of the versions which they + are able and willing to support. Parties can only communicate if they + have some connection protocol version in common. + + Version 0.1.x.y-alpha and earlier don't understand VERSIONS cells, + and therefore don't support version negotiation. Thus, waiting until + the other side has sent a VERSIONS cell won't work for these servers: + if they send no cells back, it is impossible to tell whether they + have sent a VERSIONS cell that has been stalled, or whether they have + dropped our own VERSIONS cell as unrecognized. Thus, immediately after + a TLS connection has been established, the parties check whether the + other side has an obsolete certificate (organizationName equal to "Tor" + or "TOR"). If the other party presented an obsolete certificate, + we assume a v1 connection. Otherwise, both parties send VERSIONS + cells listing all their supported versions. Upon receiving the + other party's VERSIONS cell, the implementation begins using the + highest-valued version common to both cells. If the first cell from + the other party is _not_ a VERSIONS cell, we assume a v1 protocol. + + Implementations MUST discard cells that are not the first cells sent on a + connection. + +2.2. MITM-prevention and time checking + + If we negotiate a v2 connection or higher, the first cell we send SHOULD + be a NETINFO cell. Implementations SHOULD NOT send NETINFO cells at other + times. + + A NETINFO cell contains: + Timestamp [4 bytes] + This OR's address [variable] + Other OR's address [variable] + + Timestamp is the OR's current Unix time, in seconds since the epoch. If + an implementation receives time values from many validated ORs that + indicate that its clock is skewed, it SHOULD try to warn the + administrator. + + Each address contains Type/Length/Value as used in Section 6.4. The first + address is the address of the interface the party sending the VERSIONS cell + used to connect to or accept connections from the other -- we include it + to block a man-in-the-middle attack on TLS that lets an attacker bounce + traffic through his own computers to enable timing and packet-counting + attacks. + + The second address is the one that the party sending the VERSIONS cell + believes the other has -- it can be used to learn what your IP address + is if you have no other hints. -- cgit v1.2.3-54-g00ecf