nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-10 13:13:44 +01:00
Code Issues Packages Projects Releases Wiki Activity

update spec: OR/OR and OP/OR handshakes have merged

Browse Source 
svn:r346
This commit is contained in:
Roger Dingledine 2003-06-23 09:44:35 +00:00
parent 76117b3f18
commit 59633aeddd
1 changed files with 54 additions and 74 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

112
doc/tor-spec.txt
View File

@ -48,31 +48,42 @@ which reveals the downstream node.
2. Connections
2.1. Establishing OR connections
2.1. Establishing connections to onion routers (ORs)
When one onion router opens a connection to another, the initiating
OR (called the 'client') and the listening OR (called the 'server')
perform the following handshake.
[or when an op wants to connect to or]
There are two ways to connect to an OR. The first is as an onion
proxy (OP), which allows any node to connect without providing any
authentication or name. The second is as another OR, which allows
strong authentication. In both cases the initiating party (called
the 'client') sets up shared keys with the listening OR (called the
'server').
Before the handshake begins, the client and server know one
another's (1024-bit) public keys, IPV4 addresses, and ports.
Before the handshake begins, assume all parties know the {(1024-bit)
public key, IPV4 address, and port} triplet of each OR.
1. Client connects to server:
The client generates a pair of 8-byte symmetric keys (one
The client generates a pair of 16-byte symmetric keys (one
[K_f] for the 'forward' stream from client to server, and one
[K_b] for the 'backward' stream from server to client.
The client then generates a 'Client authentication' message [M]
containing:
(If client is an OP)
The number 1 to signify OP handshake [2 bytes]
Maximum bandwidth (bytes/s) [4 bytes]
Forward key [K_f] [16 bytes]
Backward key [K_b] [16 bytes]
[Total: 38 bytes]
(If client is an OR)
The number 2 to signify OR handshake [2 bytes]
The client's published IPV4 address [4 bytes]
The client's published port [2 bytes]
The server's published IPV4 address [4 bytes]
The server's published port [2 bytes]
The forward key (K_f) [16 bytes]
The backward key (K_f) [16 bytes]
The forward key [K_f] [16 bytes]
The backward key [K_b] [16 bytes]
The maximum bandwidth (bytes/s) [4 bytes]
[Total: 50 bytes]
@ -83,22 +94,32 @@ which reveals the downstream node.
the 128-byte RSA-encrypted data to the server, and waits for a
reply.
2. Server authenticates to client:
2. The server receives the first handshake
Upon receiving a TCP connection, the server waits to receive
128 bytes from the client. It decrypts the message with its
private key, and checks the PKCS1 padding. If the padding is
incorrect, or if the message's length is other than 50 bytes,
the server closes the TCP connection and stops handshaking.
The OR waits for 128 bytes of data, and decrypts the resulting
data with its private key, checking the PKCS1 padding. If
the padding is invalid, it closes the connection. If the tag
indicates the client is an OP, and the message is 38 bytes long,
it performs step 2a. If the tag indicates the client is an OR,
and the message is 50 bytes long, it performs step 2b. Else,
it closes the connection.
The server then checks the list of known ORs for one with the
address and port given in the client's authentication. If no
such OR is known, or if the server is already connected to
that OR, the server closes the current TCP connection and
stops handshaking.
2a. If client is an OP:
For later use, the server sets its keys for this connection,
setting K_f to the client's K_b, and K_b to the client's K_f.
The connection is established, and the OR is ready to receive
cells. The server sets its keys for this connection, setting K_f
to the client's K_b, and K_b to the client's K_f. The handshake
is complete.
2b. If the client is an OR:
The server checks the list of known ORs for one with the address
and port given in the client's authentication. If no such OR
is known, or if the server is already connected to that OR, the
server closes the current TCP connection and stops handshaking.
The server sets its keys for this connection, setting K_f to
the client's K_b, and K_b to the client's K_f.
The server then creates a server authentication message [M2] as
follows:
@ -153,50 +174,9 @@ which reveals the downstream node.
cells to one another. Otherwise, the server closes the TCP
connection.
2.2. Establishing OP-to-OR connections
2.2. Sending cells and link encryption
[wrap this with the above]
When an Onion Proxy (OP) needs to establish a connection to an OR,
the handshake is simpler because the OR does not need to verify the
OP's identity. The OP and OR establish the following steps:
1. OP connects to OR:
First, the OP generates a pair of 8-byte symmetric keys (one
[K_f] for the 'forward' stream from OP to OR, and one
[K_b] for the 'backward' stream from OR to OP).
The OP generates a message [M] in the following format:
The number 1 to signify OP handshake [2 bytes]
Maximum bandwidth (bytes/s) [4 bytes]
Forward key [K_f] [16 bytes]
Backward key [K_b] [16 bytes]
[Total: 38 bytes]
The OP encrypts M with the OR's public key and PKCS1 padding,
opens a TCP connection to the OR's TCP port, and sends the
resulting 128-byte encrypted message to the OR.
2. OR receives keys:
When the OR receives a connection from an OP [This is on a
different port, right? How does it know the difference? -NM],
[Correct. The 'or_port' config variable specifies the OR port,
and the op_port variable specified the OP port. -RD]
it waits for 128 bytes of data, and decrypts the resulting
data with its private key, checking the PKCS1 padding. If the
padding is invalid, or the message is not 38 bytes long, the
OR closes the connection.
Otherwise, the connection is established, and the OR is ready
to receive cells.
The server sets its keys for this connection, setting K_f to
the client's K_b, and K_b to the client's K_f.
2.3. Sending cells and link encryption
Once the handshake is complete, the ORs or OR and OP send cells
Once the handshake is complete, the two sides send cells
(specified below) to one another. Cells are sent serially,
encrypted with the 3DES-OFB keystream specified by the handshake
protocol. Over a connection, communicants encrypt outgoing cells