mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-20 10:12:15 +01:00
252 lines
10 KiB
Plaintext
252 lines
10 KiB
Plaintext
$Id$
|
|
|
|
TOR (The Onion Router) Spec
|
|
|
|
Note: This is an attempt to specify TOR as it exists as implemented in
|
|
early March, 2003. It is not recommended that others implement this
|
|
design as it stands; future versions of TOR will implement improved
|
|
protocols.
|
|
|
|
0. Notation:
|
|
|
|
PK -- a public key.
|
|
SK -- a private key
|
|
K -- a key for a symmetric cypher
|
|
|
|
All numeric values are encoded in network (big-endian) order.
|
|
|
|
Unless otherwise specified, all symmetric ciphers are DES in OFB
|
|
mode, with an IV of all 0 bytes. All asymmetric ciphers are RSA
|
|
with 1024-bit keys, and exponents of 65537.
|
|
|
|
[Comments: DES? This should be AES. Why are -NM]
|
|
[We will move to AES once we can assume everybody will have it. -RD]
|
|
|
|
1. System overview
|
|
|
|
[Something to start with here. Do feel free to change/expand. -RD]
|
|
|
|
Tor is an implementation of version 2 of Onion Routing.
|
|
|
|
Onion Routing is a connection-oriented anonymizing communication
|
|
service. Users build a layered block of asymmetric encryptions
|
|
(an "onion") which describes a source-routed path through a set of
|
|
nodes. Those nodes build a "virtual circuit" through the network, in which
|
|
each node knows its predecessor and successor, but no others. Traffic
|
|
flowing down the circuit is unwrapped by a symmetric key at each node,
|
|
which reveals the downstream node.
|
|
|
|
|
|
|
|
2. Connections
|
|
|
|
2.1. Establishing OR-to-OR connections
|
|
|
|
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.
|
|
|
|
Before the handshake begins, the client and server know one
|
|
another's (1024-bit) public keys, IPV4 addresses, and ports.
|
|
|
|
1. Client connects to server:
|
|
|
|
The client generates a pair of 8-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 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) [8 bytes]
|
|
The backward key (K_f) [8 bytes]
|
|
The maximum bandwidth (bytes/s) [4 bytes]
|
|
[Total: 36 bytes]
|
|
|
|
The client then RSA-encrypts the message with the server's
|
|
public key, and PKCS1 padding to given an encrypted message
|
|
|
|
[Commentary: 1024 bytes is probably too short, and this protocol can't
|
|
support IPv6. -NM]
|
|
[1024 is too short for a high-latency remailer; but perhaps it's
|
|
fine for us, given our need for speed and also given our greater
|
|
vulnerability to other attacks? Onions are infrequent enough now
|
|
that maybe we could handle it; but I worry it will impact
|
|
scalability, and handling more users is important.-RD]
|
|
|
|
The client then opens a TCP connection to the server, sends
|
|
the 128-byte RSA-encrypted data to the server, and waits for a
|
|
reply.
|
|
|
|
2. Server authenticates to client:
|
|
|
|
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 32 bytes,
|
|
the server closes the TCP connection and stops handshaking.
|
|
|
|
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.
|
|
|
|
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 server then creates a server authentication message[M2] as
|
|
follows:
|
|
Modified client authentication [32 bytes]
|
|
A random nonce [N] [8 bytes]
|
|
[Total: 40 bytes]
|
|
The client authentication is generated from M by replacing
|
|
the client's preferred bandwidth [B_c] with the server's
|
|
preferred bandwidth [B_s], if B_s < B_c.
|
|
|
|
The server encrypts M2 with the client's public key (found
|
|
from the list of known routers), using PKCS1 padding.
|
|
|
|
The server sends the 128-byte encrypted message to the client,
|
|
and waits for a reply.
|
|
|
|
3. Client authenticates to server.
|
|
|
|
Once the client has received 128 bytes, it decrypts them with
|
|
its public key, and checks the PKCS1 padding. If the padding
|
|
is invalid, or the decrypted message's length is other than 40
|
|
bytes, the client closes the TCP connection.
|
|
|
|
The client checks that the addresses and keys in the reply
|
|
message are the same as the ones it originally sent. If not,
|
|
it closes the TCP connection.
|
|
|
|
The client updates the connection's bandwidth to that set by
|
|
the server, and generates the following authentication message [M3]:
|
|
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 server-generated nonce [N] [8 bytes]
|
|
[Total: 20 bytes]
|
|
|
|
Once again, the client encrypts this message using the
|
|
server's public key and PKCS1 padding, and sends the resulting
|
|
128-byte message to the server.
|
|
|
|
4. Server checks client authentication
|
|
|
|
The server once again waits to receive 128 bytes from the
|
|
client, 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 20 bytes, the server closes the
|
|
TCP connection and stops handshaking.
|
|
|
|
If the addresses in the decrypted message M3 match those in M
|
|
and M2, and if the nonce in M3 is the same as in M2, the
|
|
handshake is complete, and the client and server begin sending
|
|
cells to one another. Otherwise, the server closes the TCP
|
|
connection.
|
|
|
|
2.2. Establishing OP-to-OR connections
|
|
|
|
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:
|
|
Maximum bandwidth (bytes/s) [4 bytes]
|
|
Forward key [K_f] [8 bytes]
|
|
Backward key [K_b] [8 bytes]
|
|
[Total: 20 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 20 bytes long, the
|
|
OR closes the connection.
|
|
|
|
Otherwise, the connection is established, and the O 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
|
|
(specified below) to one another. Cells are sent serially,
|
|
encrypted with the DES-OFB keystream specified by the handshake
|
|
protocol. Over a connection, communicants encrypt outgoing cells
|
|
with the connection's K_f, and decrypt incoming cells with the
|
|
connection's K_b.
|
|
|
|
[Commentary: This means that OR/OP->OR connections are malleable; I
|
|
can flip bits in cells as they go across the wire, and see flipped
|
|
bits coming out the cells as they are decrypted at the next
|
|
server. I need to look more at the data format to see whether
|
|
this is exploitable, but if there's no integrity checking there
|
|
either, I suspect we may have an attack here. -NM]
|
|
[Yes, this protocol is open to tagging attacks. The payloads are
|
|
encrypted inside the network, so it's only at the edge node and beyond
|
|
that it's a worry. But adversaries can already count packets and
|
|
observe/modify timing. It's not worth putting in hashes; indeed, it
|
|
would be quite hard, because one of the sides of the circuit doesn't
|
|
know the keys that are used for de/encrypting at each hop, so couldn't
|
|
craft hashes anyway. See the Bandwidth Throttling (threat model)
|
|
thread on http://archives.seul.org/or/dev/Jul-2002/threads.html. -RD]
|
|
|
|
|
|
3. Cell Packet format
|
|
|
|
The basic unit of communication between onion routers and onion
|
|
proxies is a fixed-width "Cell." Each Cell contains the following
|
|
fields:
|
|
|
|
ACI (anonymous circuit identifier) [2 bytes]
|
|
Command [1 byte]
|
|
Length [1 byte]
|
|
Sequence number (unused) [4 bytes]
|
|
Payload (padded with 0 bytes) [120 bytes]
|
|
[Total size: 128 bytes]
|
|
|
|
The 'Command' field holds one of the following values:
|
|
0 -- PADDING (Padding)
|
|
1 -- CREATE (Create a circuit)
|
|
2 -- DATA (End-to-end data)
|
|
3 -- DESTROY (Stop using a circuit)
|
|
4 -- SENDME (For flow control)
|
|
|
|
The interpretation of 'Length' and 'Payload' depend on....
|
|
|
|
4. Onions and circuit management
|
|
|
|
|
|
5. Topic management
|
|
|
|
|
|
6. Flow control
|
|
|
|
|
|
|
|
|
|
|