torproject/torspec
1
0
Fork 0
mirror of https://github.com/torproject/torspec.git synced 2025-02-19 16:10:36 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Revise 176 a little based on comments by steven on tor-dev

Browse Source
This commit is contained in:
Nick Mathewson 2011-10-05 10:10:09 -04:00
parent 02049040cd
commit 0b0dae8c57
1 changed files with 22 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
proposals/176-revising-handshake.txt
View File

@ -17,16 +17,16 @@ Supersedes: 169
and authenticate the original handshake, this proposal takes an
approach similar to Steven Murdoch's proposal 124 and my old
proposal 169, and uses Tor cells to finish authenticating the
parties' identities once the initial TLS handshake is finished.
parties' identities once the initial TLS handshake is finished.spo
I discuss some alternative design choices and why I didn't make
them in section 7; please have a quick look there before
telling me that something is pointless or makes no sense.
Terminological note: I use "client" below to mean the Tor
instance (a client or a bridge or a relay) that initiates a TLS
connection, and "server" to mean the Tor instance (a bridge or a
relay) that accepts it.
Terminological note: I use "client" or "initiator" below to mean
the Tor instance (a client or a bridge or a relay) that initiates a
TLS connection, and "server" or "responder" to mean the Tor
instance (a bridge or a relay) that accepts it.
2. History and Motivation
@ -359,16 +359,17 @@ Supersedes: 169
cell. If AuthType is 1 (meaning "RSA-SHA256-TLSSecret"), then the
Authentication contains the following:
Type: The characters "AUTH0001" [8 octets]
TYPE: The characters "AUTH0001" [8 octets]
CID: A SHA256 hash of the client's RSA1024 identity key [32 octets]
SID: A SHA256 hash of the server's RSA1024 identity key [32 octets]
SLOG: A SHA256 hash of all bytes sent from the server to the client
as part of the negotiation up to and including the
AUTH_CHALLENGE cell; that is, the VERSIONS cell,
the CERT cell, and the AUTH_CHALLENGE cell. [32 octets]
the CERT cell, the AUTH_CHALLENGE cell, and any padding cells.
[32 octets]
CLOG: A SHA256 hash of all bytes sent from the client to the
server as part of the negotiation so far; that is, the
VERSIONS cell and the CERT cell. [32 octets]
VERSIONS cell and the CERT cell and any padding cells. [32 octets]
SCERT: A SHA256 hash of the server's TLS link
certificate. [32 octets]
TLSSECRETS: A SHA256 HMAC, using the TLS master secret as the
@ -387,7 +388,8 @@ Supersedes: 169
[variable length]
To check the AUTHENTICATE cell, a server checks that all fields
containing a hash contain the correct value, then verifies the
containing from TYPE through TLSSECRETS contain their unique
correct values as described above, and then verifies the signature.
signature. The server MUST ignore any extra bytes in the signed
data after the SHA256 hash.
@ -403,6 +405,9 @@ Supersedes: 169
would have supported version 3 or higher, but they somehow wound
up using a v2 or v1 handshake. (More on this in section 6.4.)
Either party may send a VPADDING cell at any time during the
handshake, except as the first cell. (See proposal 184.)
A server SHOULD NOT send any sequence of cells when starting a v3
negotiation other than "VERSIONS, CERT, AUTH_CHALLENGE,
NETINFO". A client SHOULD drop a CERT, AUTH_CHALLENGE, or
@ -421,6 +426,7 @@ Supersedes: 169
We need to reserve command numbers for CERT, AUTH_CHALLENGE, and
AUTHENTICATE. I suggest that in link protocol 3 and higher, we
reserve a separate range of commands for variable-length cells.
See proposal 184 for more there.
5. Efficiency
@ -474,15 +480,15 @@ Supersedes: 169
replayed or MITM'd AUTHENTICATE cell that was previously sent by
the client?
If the client included a non-zero TLSSECRET component, and the
Because the client includes a TLSSECRET component, and the
server is able to verify it, then the answer is easy: the server
knows for certain that it is talking to the party with whom it
did the TLS handshake, since if somebody else generated a correct
TLSSECRET, they would have to know the master secret of the TLS
connection, which would require them to have broken TLS.
If the client was not able to include a non-zero TLSSECRET
component, or the server can't check it, the answer is a little
Even if the protocol didn't contain the TLSSECRET component,
the server could the client's authentication, but it's a little
trickier. The server knows that it is not getting a replayed
AUTHENTICATE cell, since the cell authenticates (among other
stuff) the server's AUTH_CHALLENGE cell, which it has never used
@ -573,13 +579,10 @@ Supersedes: 169
used, it should prevent the use of the AUTHENTICATE cell for
anything other than the TLS connection the client had in mind.
A signature of the TLSSECRET element on its own should be
sufficient to prevent the attacks we care about, but because we
don't necessarily have access to the TLS master secret when using
a non-C TLS library, we can't depend on it. I added it anyway
so that, if there is some problem with the rest of the protocol,
clients and servers that _are_ written in C (that is, the official
Tor implementation) can still be secure.
A signature of the TLSSECRET element on its own should also be
sufficient to prevent the attacks we care about. The redundancy
here should come in handy if I've made a mistake somewhere else in
my analysis.
If the client checks the server's certificates and matches them
to the TLS connection link key before proceding with the