[tor-commits] [torspec/master] prop176 evisions based on Roger's tor-dev email of 20 Sep.
nickm at torproject.org
nickm at torproject.org
Wed Sep 21 17:59:55 UTC 2011
commit 8d51fb27adcddca401a7d77c5b69bc25a199adaa
Author: Nick Mathewson <nickm at 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
More information about the tor-commits
mailing list