|
@@ -48,33 +48,44 @@ 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:
|
|
|
- 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 maximum bandwidth (bytes/s) [4 bytes]
|
|
|
- [Total: 50 bytes]
|
|
|
+
|
|
|
+ (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_b] [16 bytes]
|
|
|
+ The maximum bandwidth (bytes/s) [4 bytes]
|
|
|
+ [Total: 50 bytes]
|
|
|
|
|
|
The client then RSA-encrypts [M] with the server's public key
|
|
|
and PKCS1 padding to give an encrypted message.
|
|
@@ -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
|
|
|
+
|
|
|
+ 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.
|
|
|
|
|
|
- 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.
|
|
|
+ 2a. If client is an OP:
|
|
|
|
|
|
- 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.
|
|
|
+ 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.
|
|
|
|
|
|
- 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.
|
|
|
+ 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
|
|
|
-
|
|
|
-[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
|
|
|
+2.2. 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
|
|
@@ -309,7 +289,7 @@ which reveals the downstream node.
|
|
|
going from the OP to the OR, and second of which (called Kb) is
|
|
|
used to encrypt the stream of data going from the OR to the OP.
|
|
|
|
|
|
-4.3. Creating circuits
|
|
|
+4.3. Creating circuits
|
|
|
|
|
|
When creating a circuit through the network, the circuit creator
|
|
|
performs the following steps:
|