From 9c86f54ba07355a968f982aed295e8b6597b4b89 Mon Sep 17 00:00:00 2001 From: Hans-Christoph Steiner Date: Wed, 27 Nov 2019 12:59:04 +0100 Subject: convert text blocks into widely compatible "blockquote" syntax This only adds newline characters to make the existing text blocks act like "blockquote" or "code block" syntax in Markdown, asciidoc, and others. This was accomplished by manually reviewing the output of this script: ```bash for f in *.txt; do cat $f | python -c "import sys,re;print(re.sub(r'(\n {0,3}[^ \n][^\n]*\n)( {4,}[^\n]*)', r'\1\n\2', sys.stdin.read()))" > ${f}.tmp mv ${f}.tmp $f done ``` --- tor-spec.txt | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) (limited to 'tor-spec.txt') diff --git a/tor-spec.txt b/tor-spec.txt index 552a453..6881436 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -226,6 +226,7 @@ see tor-design.pdf. certificate containing its identity key. The other party sends a similar certificate chain. The initiator's ClientHello MUST NOT include any ciphersuites other than: + TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA @@ -248,12 +249,14 @@ see tor-design.pdf. which the initiator can use to learn that the in-protocol handshake is in use. Specifically, at least one of these properties must be true of the certificate: + * The certificate is self-signed * Some component other than "commonName" is set in the subject or issuer DN of the certificate. * The commonName of the subject or issuer of the certificate ends with a suffix other than ".net". * The certificate's public key modulus is longer than 1024 bits. + The initiator then sends a VERSIONS cell to the responder, which then replies with a VERSIONS cell; they have then negotiated a Tor protocol version. Assuming that the version they negotiate is 3 or higher @@ -355,6 +358,7 @@ see tor-design.pdf. cipher is one not supported by OpenSSL 1.0.1. The fixed ciphersuite list is: + TLS1_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS1_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS1_DHE_RSA_WITH_AES_256_SHA @@ -450,6 +454,7 @@ see tor-design.pdf. The 'Command' field of a fixed-length cell holds one of the following values: + 0 -- PADDING (Padding) (See Sec 7.2) 1 -- CREATE (Create a circuit) (See Sec 5.1) 2 -- CREATED (Acknowledge create) (See Sec 5.1) @@ -464,6 +469,7 @@ see tor-design.pdf. 12 -- PADDING_NEGOTIATE (Padding negotiation) (See Sec 7.2) Variable-length command values are: + 7 -- VERSIONS (Negotiate proto version) (See Sec 4) 128 -- VPADDING (Variable-length padding) (See Sec 7.2) 129 -- CERTS (Certificates) (See Sec 4.2) @@ -472,6 +478,7 @@ see tor-design.pdf. 132 -- AUTHORIZE (Client authorization) (Not yet used) The interpretation of 'Payload' depends on the type of the cell. + VPADDING/PADDING: Payload contains padding bytes. CREATE/CREATE2: Payload contains the handshake challenge. @@ -479,6 +486,7 @@ see tor-design.pdf. RELAY/RELAY_EARLY: Payload contains the relay header and relay body. DESTROY: Payload contains a reason for closing the circuit. (see 5.4) + Upon receiving any other value for the command field, an OR must drop the cell. Since more cell types may be added in the future, ORs should generally not warn when encountering unrecognized commands. @@ -486,6 +494,7 @@ see tor-design.pdf. The cell is padded up to the cell length with padding bytes. Senders set padding bytes depending on the cell's command: + VERSIONS: Payload MUST NOT contain padding bytes. AUTHORIZE: Payload is unspecified and reserved for future use. Other variable-length cells: @@ -496,6 +505,7 @@ see tor-design.pdf. Other fixed-length cells: Payload MUST be padded to PAYLOAD_LEN with padding bytes. Padding bytes SHOULD be set to NUL. + We recommend random padding in RELAY/RELAY_EARLY cells, so that the cell content is unpredictable. See proposal 289 for details. For other cells, TLS authenticates cell content, so randomised padding bytes are @@ -594,6 +604,7 @@ see tor-design.pdf. list at least version 3. Link protocols differences are: + 1 -- The "certs up front" handshake. 2 -- Uses the renegotiation-based handshake. Introduces variable-length cells. @@ -633,6 +644,7 @@ see tor-design.pdf. To authenticate the responder as having a given Ed25519,RSA identity key combination, the initiator MUST check the following. + * The CERTS cell contains exactly one CertType 2 "ID" certificate. * The CERTS cell contains exactly one CertType 4 Ed25519 "Id->Signing" cert. @@ -658,6 +670,7 @@ see tor-design.pdf. To authenticate the responder as having a given RSA identity only, the initiator MUST check the following: + * The CERTS cell contains exactly one CertType 1 "Link" certificate. * The CERTS cell contains exactly one CertType 2 "ID" certificate. * Both certificates have validAfter and validUntil dates that @@ -678,6 +691,7 @@ see tor-design.pdf. To authenticate the initiator as having a given Ed25519,RSA identity key combination, the responder MUST check the following: + * The CERTS cell contains exactly one CertType 2 "ID" certificate. * The CERTS cell contains exactly one CertType 4 Ed25519 "Id->Signing" certificate. @@ -701,6 +715,7 @@ see tor-design.pdf. To authenticate the initiator as having an RSA identity key only, the responder MUST check the following: + * The CERTS cell contains exactly one CertType 3 "AUTH" certificate. * The CERTS cell contains exactly one CertType 2 "ID" certificate. * Both certificates have validAfter and validUntil dates that @@ -712,6 +727,7 @@ see tor-design.pdf. * The auth certificate is correctly signed with the key in the ID certificate. * The ID certificate is correctly self-signed. + Checking these conditions is NOT sufficient to authenticate that the initiator has the ID it claims; to do so, the cells in 4.3 and 4.4 below must be exchanged. @@ -721,6 +737,7 @@ see tor-design.pdf. An AUTH_CHALLENGE cell is a variable-length cell with the following fields: + Challenge [32 octets] N_Methods [2 octets] Methods [2 * N_Methods octets] @@ -864,6 +881,7 @@ see tor-design.pdf. AVAL (Address value in NBO)) [ALEN bytes] Recognized address types (ATYPE) are: + [04] IPv4. [06] IPv6. @@ -903,23 +921,29 @@ see tor-design.pdf. newer format is extensible by design; the older one is not. A CREATE2 cell contains: + HTYPE (Client Handshake Type) [2 bytes] HLEN (Client Handshake Data Len) [2 bytes] HDATA (Client Handshake Data) [HLEN bytes] A CREATED2 cell contains: + HLEN (Server Handshake Data Len) [2 bytes] HDATA (Server Handshake Data) [HLEN bytes] Recognized handshake types are: + 0x0000 TAP -- the original Tor handshake; see 5.1.3 0x0001 reserved 0x0002 ntor -- the ntor+curve25519+sha256 handshake; see 5.1.4 The format of a CREATE cell is one of the following: + HDATA (Client Handshake Data) [TAP_C_HANDSHAKE_LEN bytes] + or + HTAG (Client Handshake Type Tag) [16 bytes] HDATA (Client Handshake Data) [TAP_C_HANDSHAKE_LEN-16 bytes] @@ -931,7 +955,9 @@ see tor-design.pdf. ntor -- 'ntorNTORntorNTOR' The format of a CREATED cell is: + HDATA (Server Handshake Data) [TAP_S_HANDSHAKE_LEN bytes] + (It's equivalent to a CREATED2 cell with length of TAP_S_HANDSHAKE_LEN.) As usual with DH, x and y MUST be generated randomly. @@ -979,6 +1005,7 @@ see tor-design.pdf. relay cell to the last node in the circuit. An EXTEND2 cell's relay payload contains: + NSPEC (Number of link specifiers) [1 byte] NSPEC times: LSTYPE (Link specifier type) [1 byte] @@ -990,6 +1017,7 @@ see tor-design.pdf. Link specifiers describe the next node in the circuit and how to connect to it. Recognized specifiers are: + [00] TLS-over-TCP, IPv4 address A four-byte IPv4 address plus two-byte ORPort [01] TLS-over-TCP, IPv6 address @@ -1004,6 +1032,7 @@ see tor-design.pdf. instances of specifiers other than 'legacy identity'. The relay payload for an EXTEND relay cell consists of: + Address [4 bytes] Port [2 bytes] Onion skin [TAP_C_HANDSHAKE_LEN bytes] @@ -1080,6 +1109,7 @@ see tor-design.pdf. The payload for a CREATED cell, or the relay payload for an EXTENDED cell, contains: + DH data (g^y) [DH_LEN bytes] Derivative key data (KH) [HASH_LEN bytes] @@ -1112,6 +1142,7 @@ see tor-design.pdf. [The ntor handshake was added in Tor 0.2.4.8-alpha.] In this section, define: + H(x,t) as HMAC_SHA256 with message x and key t. H_LENGTH = 32. ID_LENGTH = 20. @@ -1132,8 +1163,11 @@ see tor-design.pdf. digest for the server, and an ntor onion key (a curve25519 public key) for that server. Call the ntor onion key "B". The client generates a temporary keypair: + x,X = KEYGEN() + and generates a client-side handshake with contents: + NODEID Server identity digest [ID_LENGTH bytes] KEYID KEYID(B) [H_LENGTH bytes] CLIENT_PK X [G_LENGTH bytes] @@ -1147,6 +1181,7 @@ see tor-design.pdf. auth_input = verify | ID | B | Y | X | PROTOID | "Server" The server's handshake reply is: + SERVER_PK Y [G_LENGTH bytes] AUTH H(auth_input, t_mac) [H_LENGTH bytes] @@ -1214,6 +1249,7 @@ see tor-design.pdf. From the base key material K0, they compute KEY_LEN*2+HASH_LEN*3 bytes of derivative key data as + K = H(K0 | [00]) | H(K0 | [01]) | H(K0 | [02]) | ... The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward @@ -1333,6 +1369,7 @@ see tor-design.pdf. To prevent this, when an OR gets an extend request, it SHOULD use an existing OR connection if the ID matches, and ANY of the following conditions hold: + - The IP matches the requested IP. - The OR knows that the IP of the connection it's using is canonical because it was listed in the NETINFO cell. @@ -1346,12 +1383,14 @@ see tor-design.pdf. circuit's intended lifetime is over. ORs SHOULD also tear down circuits which attempt to create: + * streams with RELAY_BEGIN, or * rendezvous points with ESTABLISH_RENDEZVOUS, ending at the first hop. Letting Tor be used as a single hop proxy makes exit and rendezvous nodes a more attractive target for compromise. ORs MAY use multiple methods to check if they are the first hop: + * If an OR sees a circuit created with CREATE_FAST, the OR is sure to be the first hop of a circuit. * If an OR is the responder, and the initiator: @@ -1401,6 +1440,7 @@ see tor-design.pdf. this error code to 0, to avoid leaking its version. The error codes are: + 0 -- NONE (No reason given.) 1 -- PROTOCOL (Tor protocol violation.) 2 -- INTERNAL (Internal error.) @@ -1438,6 +1478,7 @@ see tor-design.pdf. When a relay cell is sent from an OP, the OP encrypts the payload with the stream cipher as follows: + OP sends relay cell: For I=N...1, where N is the destination node: Encrypt with Kf_I. @@ -1447,6 +1488,7 @@ see tor-design.pdf. When a forward relay cell is received by an OR, it decrypts the payload with the stream cipher, as follows: + 'Forward' relay cell: Use Kf as key; decrypt. @@ -1469,6 +1511,7 @@ see tor-design.pdf. When a backward relay cell is received by an OR, it encrypts the payload with the stream cipher, as follows: + 'Backward' relay cell: Use Kb as key; encrypt. @@ -1476,6 +1519,7 @@ see tor-design.pdf. When a relay cell arrives at an OP, the OP decrypts the payload with the stream cipher as follows: + OP receives relay cell from node 1: For I=1...N, where N is the final node on the circuit: Decrypt with Kb_I. @@ -1517,6 +1561,7 @@ see tor-design.pdf. * onion services (RELAY_BEGIN, anonymous via a rendezvous point). The payload of each unencrypted RELAY cell consists of: + Relay command [1 byte] 'Recognized' [2 bytes] StreamID [2 bytes] @@ -1525,6 +1570,7 @@ see tor-design.pdf. Data [PAYLOAD_LEN-11 bytes] The relay commands are: + 1 -- RELAY_BEGIN [forward] 2 -- RELAY_DATA [forward or backward] 3 -- RELAY_END [forward or backward] @@ -1633,9 +1679,12 @@ see tor-design.pdf. exit node replies with a RELAY_END cell. (See 6.4 below.) Otherwise, the exit node replies with a RELAY_CONNECTED cell, whose payload is in one of the following formats: + The IPv4 address to which the connection was made [4 octets] A number of seconds (TTL) for which the address may be cached [4 octets] + or + Four zero-valued octets [4 octets] An address type (6) [1 octet] The IPv6 address to which the connection was made [16 octets] @@ -1783,6 +1832,7 @@ see tor-design.pdf. TTL (4 octets) "Length" is the length of the Value field. "Type" is one of: + 0x00 -- Hostname 0x04 -- IPv4 address 0x06 -- IPv6 address @@ -1842,6 +1892,7 @@ see tor-design.pdf. enabled as per padding-spec.txt. On these connections, clients may negotiate the use of padding with a CELL_PADDING_NEGOTIATE command whose format is as follows: + Version [1 byte] Command [1 byte] ito_low_ms [2 bytes] -- cgit v1.2.3-54-g00ecf