commit 8d51fb27adcddca401a7d77c5b69bc25a199adaa Author: Nick Mathewson nickm@torproject.org Date: Wed Sep 21 14:01:41 2011 -0400

prop176 evisions based on Roger's tor-dev email of 20 Sep. --- proposals/176-revising-handshake.txt | 49 ++++++++++++++++----------------- 1 files changed, 24 insertions(+), 25 deletions(-)

diff --git a/proposals/176-revising-handshake.txt b/proposals/176-revising-handshake.txt index 39f4465..52a2d0a 100644 --- a/proposals/176-revising-handshake.txt +++ b/proposals/176-revising-handshake.txt @@ -146,16 +146,11 @@ Supersedes: 169 1) We should make it easier to use self-signed certs, or maybe even existing HTTPS certificates, for the server side handshake, since most non-Tor SSL handshakes use either - self-signed certificates or + self-signed certificates or CA-signed certificates.

- 2) We should make it harder to probe for a Tor server. Right - now, you can just do a handshake with a server, - renegotiate, then see if it gives you a VERSIONS cell. - That's no good. - - 3) We should allow other changes in our use of TLS and in our + 2) We should allow other changes in our use of TLS and in our certificates so as to resist fingerprinting based on how - our certificates look. + our certificates look. (See proposal 179.)

3. Design

@@ -217,6 +212,7 @@ Supersedes: 169 S->C: VERSIONS cell, CERT cell, AUTH_CHALLENGE cell, NETINFO cell

C->S: Optionally: CERT cell, AUTHENTICATE cell + C->S: NETINFO cell

A "CERTS" cell contains a set of certificates; an "AUTHENTICATE" cell authenticates the client to the server. More on these @@ -253,8 +249,7 @@ Supersedes: 169 signed by a CA, then the issuer will surely have more DN fields set. Certificates that aren't trying to resist fingerprinting can trivially become v3 by using a CN that doesn't end with .net, - or using a 1024-bit key. - + or using a key longer than 1024 bits.

3.3. Authenticating via Tor cells: server authentication

@@ -321,20 +316,28 @@ Supersedes: 169 the connection. If the client wanted to connect to a server with a different identity key, the client closes the connection.

- 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] + It is sent from the server to the client. Clients MUST ignore unexpected bytes at the end of the cell. Servers MUST generate every challenge using a strong RNG or PRNG.

+ The Challenge field is a randomly generated string that the + client must sign (a hash of) as part of authenticating. The + methods are the authentication methods that the server will + accept. Only one authentication method is defined right now; see + 3.4 below. + 3.4. Authenticating via Tor cells: Client authentication

A client does not need to authenticate to the server. If it does not wish to, it responds to the server's valid CERT cell by - sending a NETINFO cell: once it has gotten a valid NETINFO cell - back, the client should consider the connection open, and the + sending a NETINFO cell: once it has gotten a valid NETINFO cell, + the client should consider the connection open, and the server should consider the connection as opened by an unauthenticated client.

@@ -352,7 +355,6 @@ Supersedes: 169 AuthLen [2 octets] Authentication [AuthLen octets]

- Servers MUST ignore extra bytes at the end of an AUTHENTICATE cell. If AuthType is 1 (meaning "RSA-SHA256-TLSSecret"), then the Authentication contains the following: @@ -369,15 +371,15 @@ Supersedes: 169 VERSIONS cell and the CERT cell. [32 octets] SCERT: A SHA256 hash of the server's TLS link certificate. [32 octets] - TLSSECRETS: Either 32 zero octets, or a SHA256 HMAC, using - the TLS master secret as the secret key, of the following: + TLSSECRETS: A SHA256 HMAC, using the TLS master secret as the + secret key, of the following: - client_random, as sent in the TLS Client Hello - server_random, as sent in the TLS Server Hello - the NUL terminated ASCII string: "Tor V3 handshake TLS cross-certification" [32 octets] TIME: The time of day in seconds since the POSIX epoch. [8 octets] - NONCE: A 16 byte value, randomly chosen by the client [16 octets] + RAND: A 16 byte value, randomly chosen by the client [16 octets] SIG: A signature of a SHA256 hash of all the previous fields using the client's "Authenticate" key as presented. (As always in Tor, we use OAEP-MGF1 padding; see tor-spec.txt @@ -386,19 +388,16 @@ Supersedes: 169

To check the AUTHENTICATE cell, a server checks that all fields containing a hash contain the correct value, then verifies the - signature. The server MUST ignore any extra bytes after - the SHA256 hash. - - When possible (that is, when implemented using C TLS API), - implementations SHOULD include and verify the TLSSECRETS field. + signature. The server MUST ignore any extra bytes in the signed + data after the SHA256 hash.

3.5. Responding to extra cells, and other security checks.

- If the handshake is a V3+ TLS handshake, both parties MUST reject + If the handshake is a V3 TLS handshake, both parties MUST reject any negotiated link version less than 3. Both parties MUST check this and close the connection if it is violated.

- If the handshake is not a V3+ TLS handshake, both parties MUST + If the handshake is not a V3 TLS handshake, both parties MUST still advertise all link protocols they support in their versions cell. Both parties MUST close the link if it turns out they both would have supported version 3 or higher, but they somehow wound @@ -613,7 +612,7 @@ Supersedes: 169 - Can we give some way for clients to signal "I want to use the V3 protocol if possible, but I can't renegotiate, so don't give me the V2"? Clients currently have a fair idea of server - versions, so they could potentially do the V3+ handshake with + versions, so they could potentially do the V3 handshake with servers that support it, and fall back to V1 otherwise.

- What should servers that don't have TLS renegotiation do? For