mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-09-20 13:06:20 +02:00
partial update of the spec
still wrong in plenty of places svn:r301
This commit is contained in:
parent
8e242d9b87
commit
5e05079890
@ -1,9 +1,9 @@
|
|||||||
$Id$
|
$Id$
|
||||||
|
|
||||||
TOR (The Onion Router) Spec
|
TOR Spec
|
||||||
|
|
||||||
Note: This is an attempt to specify TOR as it exists as implemented in
|
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
|
early June, 2003. It is not recommended that others implement this
|
||||||
design as it stands; future versions of TOR will implement improved
|
design as it stands; future versions of TOR will implement improved
|
||||||
protocols.
|
protocols.
|
||||||
|
|
||||||
@ -18,22 +18,23 @@ protocols.
|
|||||||
|
|
||||||
All numeric values are encoded in network (big-endian) order.
|
All numeric values are encoded in network (big-endian) order.
|
||||||
|
|
||||||
Unless otherwise specified, all symmetric ciphers are DES in OFB
|
Unless otherwise specified, all symmetric ciphers are 3DES in OFB
|
||||||
mode, with an IV of all 0 bytes. All asymmetric ciphers are RSA
|
mode, with an IV of all 0 bytes. Asymmetric ciphers are either RSA
|
||||||
with 1024-bit keys, and exponents of 65537.
|
with 1024-bit keys and exponents of 65537, or DH with the safe prime
|
||||||
|
from rfc2409, section 6.2, whose hex representation is:
|
||||||
|
|
||||||
|
"FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E08"
|
||||||
|
"8A67CC74020BBEA63B139B22514A08798E3404DDEF9519B3CD3A431B"
|
||||||
|
"302B0A6DF25F14374FE1356D6D51C245E485B576625E7EC6F44C42E9"
|
||||||
|
"A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE6"
|
||||||
|
"49286651ECE65381FFFFFFFFFFFFFFFF"
|
||||||
|
|
||||||
[We will move to AES once we can assume everybody will have it. -RD]
|
[We will move to AES once we can assume everybody will have it. -RD]
|
||||||
|
|
||||||
1. System overview
|
1. System overview
|
||||||
|
|
||||||
[Something to start with here. Do feel free to change/expand. -RD]
|
Tor is a connection-oriented anonymizing communication service. Users
|
||||||
|
build a path known as a "virtual circuit" through the network, in which
|
||||||
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
|
each node knows its predecessor and successor, but no others. Traffic
|
||||||
flowing down the circuit is unwrapped by a symmetric key at each node,
|
flowing down the circuit is unwrapped by a symmetric key at each node,
|
||||||
which reveals the downstream node.
|
which reveals the downstream node.
|
||||||
@ -42,11 +43,12 @@ which reveals the downstream node.
|
|||||||
|
|
||||||
2. Connections
|
2. Connections
|
||||||
|
|
||||||
2.1. Establishing OR-to-OR connections
|
2.1. Establishing OR connections
|
||||||
|
|
||||||
When one onion router opens a connection to another, the initiating
|
When one onion router opens a connection to another, the initiating
|
||||||
OR (called the 'client') and the listening OR (called the 'server')
|
OR (called the 'client') and the listening OR (called the 'server')
|
||||||
perform the following handshake.
|
perform the following handshake.
|
||||||
|
[or when an op wants to connect to or]
|
||||||
|
|
||||||
Before the handshake begins, the client and server know one
|
Before the handshake begins, the client and server know one
|
||||||
another's (1024-bit) public keys, IPV4 addresses, and ports.
|
another's (1024-bit) public keys, IPV4 addresses, and ports.
|
||||||
@ -59,6 +61,7 @@ which reveals the downstream node.
|
|||||||
|
|
||||||
The client then generates a 'Client authentication' message [M]
|
The client then generates a 'Client authentication' message [M]
|
||||||
containing:
|
containing:
|
||||||
|
The number 2 to signify OR handshake [2 bytes]
|
||||||
The client's published IPV4 address [4 bytes]
|
The client's published IPV4 address [4 bytes]
|
||||||
The client's published port [2 bytes]
|
The client's published port [2 bytes]
|
||||||
The server's published IPV4 address [4 bytes]
|
The server's published IPV4 address [4 bytes]
|
||||||
@ -66,18 +69,10 @@ which reveals the downstream node.
|
|||||||
The forward key (K_f) [16 bytes]
|
The forward key (K_f) [16 bytes]
|
||||||
The backward key (K_f) [16 bytes]
|
The backward key (K_f) [16 bytes]
|
||||||
The maximum bandwidth (bytes/s) [4 bytes]
|
The maximum bandwidth (bytes/s) [4 bytes]
|
||||||
[Total: 48 bytes]
|
[Total: 50 bytes]
|
||||||
|
|
||||||
The client then RSA-encrypts the message with the server's
|
The client then RSA-encrypts [M] with the server's public key
|
||||||
public key, and PKCS1 padding to given an encrypted message
|
and PKCS1 padding to give 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 client then opens a TCP connection to the server, sends
|
||||||
the 128-byte RSA-encrypted data to the server, and waits for a
|
the 128-byte RSA-encrypted data to the server, and waits for a
|
||||||
@ -88,7 +83,7 @@ which reveals the downstream node.
|
|||||||
Upon receiving a TCP connection, the server waits to receive
|
Upon receiving a TCP connection, the server waits to receive
|
||||||
128 bytes from the client. It decrypts the message with its
|
128 bytes from the client. It decrypts the message with its
|
||||||
private key, and checks the PKCS1 padding. If the padding is
|
private key, and checks the PKCS1 padding. If the padding is
|
||||||
incorrect, or if the message's length is other than 32 bytes,
|
incorrect, or if the message's length is other than 50 bytes,
|
||||||
the server closes the TCP connection and stops handshaking.
|
the server closes the TCP connection and stops handshaking.
|
||||||
|
|
||||||
The server then checks the list of known ORs for one with the
|
The server then checks the list of known ORs for one with the
|
||||||
@ -119,7 +114,7 @@ which reveals the downstream node.
|
|||||||
|
|
||||||
Once the client has received 128 bytes, it decrypts them with
|
Once the client has received 128 bytes, it decrypts them with
|
||||||
its public key, and checks the PKCS1 padding. If the padding
|
its public key, and checks the PKCS1 padding. If the padding
|
||||||
is invalid, or the decrypted message's length is other than 40
|
is invalid, or the decrypted message's length is other than 56
|
||||||
bytes, the client closes the TCP connection.
|
bytes, the client closes the TCP connection.
|
||||||
|
|
||||||
The client checks that the addresses and keys in the reply
|
The client checks that the addresses and keys in the reply
|
||||||
@ -155,6 +150,7 @@ which reveals the downstream node.
|
|||||||
|
|
||||||
2.2. Establishing OP-to-OR connections
|
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,
|
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
|
the handshake is simpler because the OR does not need to verify the
|
||||||
OP's identity. The OP and OR establish the following steps:
|
OP's identity. The OP and OR establish the following steps:
|
||||||
@ -166,10 +162,11 @@ which reveals the downstream node.
|
|||||||
[K_b] for the 'backward' stream from OR to OP).
|
[K_b] for the 'backward' stream from OR to OP).
|
||||||
|
|
||||||
The OP generates a message [M] in the following format:
|
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]
|
Maximum bandwidth (bytes/s) [4 bytes]
|
||||||
Forward key [K_f] [16 bytes]
|
Forward key [K_f] [16 bytes]
|
||||||
Backward key [K_b] [16 bytes]
|
Backward key [K_b] [16 bytes]
|
||||||
[Total: 32 bytes]
|
[Total: 38 bytes]
|
||||||
|
|
||||||
The OP encrypts M with the OR's public key and PKCS1 padding,
|
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
|
opens a TCP connection to the OR's TCP port, and sends the
|
||||||
@ -183,10 +180,10 @@ which reveals the downstream node.
|
|||||||
and the op_port variable specified the OP port. -RD]
|
and the op_port variable specified the OP port. -RD]
|
||||||
it waits for 128 bytes of data, and decrypts the resulting
|
it waits for 128 bytes of data, and decrypts the resulting
|
||||||
data with its private key, checking the PKCS1 padding. If the
|
data with its private key, checking the PKCS1 padding. If the
|
||||||
padding is invalid, or the message is not 20 bytes long, the
|
padding is invalid, or the message is not 38 bytes long, the
|
||||||
OR closes the connection.
|
OR closes the connection.
|
||||||
|
|
||||||
Otherwise, the connection is established, and the O is ready
|
Otherwise, the connection is established, and the OR is ready
|
||||||
to receive cells.
|
to receive cells.
|
||||||
|
|
||||||
The server sets its keys for this connection, setting K_f to
|
The server sets its keys for this connection, setting K_f to
|
||||||
@ -236,19 +233,20 @@ which reveals the downstream node.
|
|||||||
The 'Command' field holds one of the following values:
|
The 'Command' field holds one of the following values:
|
||||||
0 -- PADDING (Padding) (See Sec 6.2)
|
0 -- PADDING (Padding) (See Sec 6.2)
|
||||||
1 -- CREATE (Create a circuit) (See Sec 4)
|
1 -- CREATE (Create a circuit) (See Sec 4)
|
||||||
2 -- DATA (End-to-end data) (See Sec 5)
|
2 -- CREATED (Acknowledge create) (See Sec 4)
|
||||||
3 -- DESTROY (Stop using a circuit) (See Sec 4)
|
3 -- RELAY (End-to-end data) (See Sec 5)
|
||||||
4 -- SENDME (For flow control) (See Sec 6.1)
|
4 -- DESTROY (Stop using a circuit) (See Sec 4)
|
||||||
|
|
||||||
The interpretation of 'Length' and 'Payload' depend on the type of
|
The interpretation of 'Length' and 'Payload' depend on the type of
|
||||||
the cell.
|
the cell.
|
||||||
PADDING: Length is 0; Payload is 248 bytes of 0's.
|
PADDING: Neither field is used.
|
||||||
CREATE: Length is a value between 1 and 248; the first 'length'
|
CREATE: Length is 144; the payload contains the first phase of the
|
||||||
bytes of payload contain a portion of an onion.
|
DH handshake.
|
||||||
DATA: Length is a value between 4 and 248; the first 'length'
|
CREATED: Length is 128; the payload contains the second phase of
|
||||||
|
the DH handshake.
|
||||||
|
RELAY: Length is a value between 8 and 248; the first 'length'
|
||||||
bytes of payload contain useful data.
|
bytes of payload contain useful data.
|
||||||
DESTROY: Neither field is used.
|
DESTROY: Neither field is used.
|
||||||
SENDME: Length encodes a window size, payload is unused.
|
|
||||||
|
|
||||||
Unused fields are filled with 0 bytes. The payload is padded with
|
Unused fields are filled with 0 bytes. The payload is padded with
|
||||||
0 bytes.
|
0 bytes.
|
||||||
@ -260,17 +258,24 @@ which reveals the downstream node.
|
|||||||
CREATE and DESTROY cells are used to manage circuits; see section
|
CREATE and DESTROY cells are used to manage circuits; see section
|
||||||
4 below.
|
4 below.
|
||||||
|
|
||||||
DATA cells are used to send commands and data along a circuit; see
|
RELAY cells are used to send commands and data along a circuit; see
|
||||||
section 5 below.
|
section 5 below.
|
||||||
|
|
||||||
SENDME cells are used for flow control; see section 6 below.
|
4. Circuit management
|
||||||
|
|
||||||
4. Onions and circuit management
|
|
||||||
|
|
||||||
4.1. Setting up circuits
|
4.1. Setting up circuits
|
||||||
|
|
||||||
An onion is a multi-layered structure, with one layer for each node
|
Users set up circuits incrementally, one hop at a time. To create
|
||||||
in a circuit. Each (unencrypted) layer has the following fields:
|
a new circuit, users send a CREATE cell to the first node, with the
|
||||||
|
first half of the DH handshake; that node responds with a CREATED cell
|
||||||
|
with the second half of the DH handshake. To extend a circuit past
|
||||||
|
the first hop, the user sends an EXTEND relay cell (see section 5)
|
||||||
|
which instructs the last node in the circuit to send a CREATE cell
|
||||||
|
to extend the circuit.
|
||||||
|
|
||||||
|
CREATE cells contain the following:
|
||||||
|
|
||||||
|
[this stuff now wrong; haven't fixed the rest of the file either.]
|
||||||
|
|
||||||
Version [1 byte]
|
Version [1 byte]
|
||||||
Port [2 bytes]
|
Port [2 bytes]
|
||||||
@ -279,8 +284,6 @@ which reveals the downstream node.
|
|||||||
Key seed material [16 bytes]
|
Key seed material [16 bytes]
|
||||||
[Total: 27 bytes]
|
[Total: 27 bytes]
|
||||||
|
|
||||||
The value of Version is currently 2.
|
|
||||||
|
|
||||||
The port and address field denote the IPV4 address and port of
|
The port and address field denote the IPV4 address and port of
|
||||||
the next onion router in the circuit, or are set to 0 for the
|
the next onion router in the circuit, or are set to 0 for the
|
||||||
last hop.
|
last hop.
|
||||||
@ -414,9 +417,9 @@ which reveals the downstream node.
|
|||||||
Edge nodes process the length and payload fields of DATA cells as
|
Edge nodes process the length and payload fields of DATA cells as
|
||||||
described in section 5 below.
|
described in section 5 below.
|
||||||
|
|
||||||
5. Application connections and topic management
|
5. Application connections and stream management
|
||||||
|
|
||||||
5.1. Topics and TCP streams
|
5.1. Streams
|
||||||
|
|
||||||
Within a circuit, the OP and the exit node use the contents of DATA
|
Within a circuit, the OP and the exit node use the contents of DATA
|
||||||
packets to tunnel TCP connections ("Topics") across circuits.
|
packets to tunnel TCP connections ("Topics") across circuits.
|
||||||
|
Loading…
Reference in New Issue
Block a user