diff options
Diffstat (limited to 'doc/spec/proposals/176-revising-handshake.txt')
-rw-r--r-- | doc/spec/proposals/176-revising-handshake.txt | 623 |
1 files changed, 0 insertions, 623 deletions
diff --git a/doc/spec/proposals/176-revising-handshake.txt b/doc/spec/proposals/176-revising-handshake.txt deleted file mode 100644 index db7ea4a663..0000000000 --- a/doc/spec/proposals/176-revising-handshake.txt +++ /dev/null @@ -1,623 +0,0 @@ -Filename: 176-revising-handshake.txt -Title: Proposed version-3 link handshake for Tor -Author: Nick Mathewson -Created: 31-Jan-2011 -Status: Draft -Target: 0.2.3 -Supersedes: 169 - -1. Overview - - I propose a (mostly) backward-compatible change to the Tor - connection establishment protocol to avoid the use of TLS - renegotiation, to avoid certain protocol fingerprinting attacks, - and to make it easier to write Tor clients and servers. - - Rather than doing a TLS renegotiation to exchange certificates - 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. - - 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. - -2. History and Motivation - - The _goals_ of the Tor link handshake have remained basically uniform - since our earliest versions. They are: - - * Provide data confidentiality, data integrity - * Provide forward secrecy - * Allow responder authentication or bidirectional authentication. - * Try to look like some popular too-important-to-block-at-whim - encryption protocol, to avoid fingerprinting and censorship. - * Try to be implementatble -- on the client side at least! -- - by as many TLS implementations as possible. - - When we added the v2 handshake, we added another goal: - - * Remain compatible with older versions of the handshake - protocol. - - In the original Tor TLS connection handshake protocol ("V1", or - "two-cert"), parties that wanted to authenticate provided a - two-cert chain of X.509 certificates during the handshake setup - phase. Every party that wanted to authenticate sent these - certificates. The security properties of this protocol are just - fine; the problem was that our behavior of sending - two-certificate chains made Tor easy to identify. - - In the current Tor TLS connection handshake protocol ("V2", or - "renegotiating"), the parties begin with a single certificate - sent from the server (responder) to the client (initiator), and - then renegotiate to a two-certs-from-each-authenticating party. - We made this change to make Tor's handshake look like a browser - speaking SSL to a webserver. (See proposal 130, and - tor-spec.txt.) So from an observer's point of view, two parties - performing the V2 handshake begin by making a regular TLS - handshake with a single certificate, then renegotiate - immediately. - - To tell whether to use the V1 or V2 handshake, the servers look - at the list of ciphers sent by the client. (This is ugly, but - there's not much else in the ClientHello that they can look at.) - If the list contains any cipher not used by the V1 protocol, the - server sends back a single cert and expects a renegotiation. If - the client gets back a single cert, then it withholds its own - certificates until the TLS renegotiation phase. - - In other words, V2-supporting initiator behavior currently looks - like this: - - - Begin TLS negotiation with V2 cipher list; wait for - certificate(s). - - If we get a certificate chain: - - Then we are using the V1 handshake. Send our own - certificate chain as part of this initial TLS handshake - if we want to authenticate; otherwise, send no - certificates. When the handshake completes, check - certificates. We are now mutually authenticated. - - Otherwise, if we get just a single certificate: - - Then we are using the V2 handshake. Do not send any - certificates during this handshake. - - When the handshake is done, immediately start a TLS - renegotiation. During the renegotiation, expect - a certificate chain from the server; send a certificate - chain of our own if we want to authenticate ourselves. - - After the renegotiation, check the certificates. Then - send (and expect) a VERSIONS cell from the other side to - establish the link protocol version. - - And V2-supporting responder behavior now looks like this: - - - When we get a TLS ClientHello request, look at the cipher - list. - - If the cipher list contains only the V1 ciphersuites: - - Then we're doing a V1 handshake. Send a certificate - chain. Expect a possible client certificate chain in - response. - Otherwise, if we get other ciphersuites: - - We're using the V2 handshake. Send back a single - certificate and let the handshake complete. - - Do not accept any data until the client has renegotiated. - - When the client is renegotiating, send a certificate - chain, and expect (possibly multiple) certificates in - reply. - - Check the certificates when the renegotiation is done. - Then exchange VERSIONS cells. - - Late in 2009, researchers found a flaw in most applications' use - of TLS renegotiation: Although TLS renegotiation does not - reauthenticate any information exchanged before the renegotiation - takes place, many applications were treating it as though it did, - and assuming that data sent _before_ the renegotiation was - authenticated with the credentials negotiated _during_ the - renegotiation. This problem was exacerbated by the fact that - most TLS libraries don't actually give you an obvious good way to - tell where the renegotiation occurred relative to the datastream. - Tor wasn't directly affected by this vulnerability, but the - aftermath hurts us in a few ways: - - 1) OpenSSL has disabled renegotiation by default, and created - a "yes we know what we're doing" option we need to set to - turn it back on. (Two options, actually: one for openssl - 0.9.8l and one for 0.9.8m and later.) - - 2) Some vendors have removed all renegotiation support from - their versions of OpenSSL entirely, forcing us to tell - users to either replace their versions of OpenSSL or to - link Tor against a hand-built one. - - 3) Because of 1 and 2, I'd expect TLS renegotiation to become - rarer and rarer in the wild, making our own use stand out - more. - - Furthermore, there are other issues related to TLS and - fingerprinting that we want to fix in any revised handshake: - - 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 - - 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 - certificates so as to resist fingerprinting based on how - our certificates look. - -3. Design - -3.1. The view in the large - - Taking a cue from Steven Murdoch's proposal 124 and my old - proposal 169, I propose that we move the work currently done by - the TLS renegotiation step (that is, authenticating the parties - to one another) and do it with Tor cells instead of with TLS - alone. - - This section outlines the protocol; we go into more detail below. - - To tell the client that it can use the new cell-based - authentication system, the server sends a "V3 certificate" during - the initial TLS handshake. (More on what makes a certificate - "v3" below.) If the client recognizes the format of the - certificate and decides to pursue the V3 handshake, then instead - of renegotiating immediately on completion of the initial TLS - handshake, the client instead sends a VERSIONS cell (and the - negotiation begins). - - So the flowchart on the server side is: - - Wait for a ClientHello. - IF the client sends a ClientHello that indicates V1: - - Send a certificate chain. - - When the TLS handshake is done, if the client sent us a - certificate chain, then check it. - If the client sends a ClientHello that indicates V2 or V3: - - Send a self-signed certificate or a CA-signed certificate - - When the TLS handshake is done, wait for renegotiation or data. - - If renegotiation occurs, the client is V2: send a - certificate chain and maybe receive one. Check the - certificate chain as in V1. - - If the client sends data without renegotiating, it is - starting the V3 handshake. Proceed with the V3 - handshake as below. - - And the client-side flowchart is: - - - Send a ClientHello with a set of ciphers that indicates V2/V3. - - After the handshake is done: - - If the server sent us a certificate chain, check it: we - are using the V1 handshake. - - If the server sent us a single "V2 certificate", we are - using the v2 handshake: the client begins to renegotiate - and proceeds as before. - - Finally, if the server sent us a "v3 certificate", we are - doing the V3 handshake below. - - And the cell-based part of the V3 handshake, in summary, is: - - C<->S: TLS handshake where S sends a "v3 certificate" - - In TLS: - - C->S: VERSIONS cell - S->C: VERSIONS cell, CERT cell, AUTH_CHALLENGE cell, NETINFO cell - - C->S: Optionally: CERT cell, AUTHENTICATE cell - - A "CERTS" cell contains a set of certificates; an "AUTHENTICATE" - cell authenticates the client to the server. More on these - later. - -3.2. Distinguishing V2 and V3 certificates - - In the protocol outline above, we require that the client can - distinguish between v2 certificates (that is, those sent by - current servers) and a v3 certificates. We further require that - existing clients will accept v3 certificates as they currently - accept v2 certificates. - - Fortunately, current certificates have a few characteristics that - make them fairly mannered as it is. We say that a certificate - indicates a V2-only server if ALL of the following hold: - * The certificate is not self-signed. - * There is no DN field set in the certificate's issuer or - subject other than "commonName". - * The commonNames of the issuer and subject both end with - ".net" - * The public modulus is at most 1024 bits long. - - Otherwise, the client should assume that the server supports the - V3 handshake. - - To the best of my knowledge, current clients will behave properly - on receiving non-v2 certs during the initial TLS handshake so - long as they eventually get the correct V2 cert chain during the - renegotiation. - - The v3 requirements are easy to meet: any certificate designed to - resist fingerprinting will likely be self-signed, or if it's - 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. - - -3.3. Authenticating via Tor cells: server authentication - - Once the TLS handshake is finished, if the client renegotiates, - then the server should go on as it does currently. - - If the client implements this proposal, however, and the server - has shown it can understand the V3+ handshake protocol, the - client immediately sends a VERSIONS cell to the server - and waits to receive a VERSIONS cell in return. We negotiate - the Tor link protocol version _before_ we proceed with the - negotiation, in case we need to change the authentication - protocol in the future. - - Once either party has seen the VERSIONS cell from the other, it - knows which version they will pick (that is, the highest version - shared by both parties' VERSIONS cells). All Tor instances using - the handshake protocol described in 3.2 MUST support at least - link protocol version 3 as described here. If a version lower - than 3 is negotiated with the V3 handshake in place, a Tor - instance MUST close the connection. - - On learning the link protocol, the server then sends the client a - CERT cell and a NETINFO cell. If the client wants to - authenticate to the server, it sends a CERT cell, an AUTHENTICATE - cell, and a NETINFO cell, or it may simply send a NETINFO cell if - it does not want to authenticate. - - The CERT cell describes the keys that a Tor instance is claiming - to have. It is a variable-length cell. Its payload format is: - - N: Number of certs in cell [1 octet] - N times: - CertType [1 octet] - CLEN [2 octets] - Certificate [CLEN octets] - - Any extra octets at the end of a CERT cell MUST be ignored. - - CertType values are: - 1: Link key certificate from RSA1024 identity - 2: RSA1024 Identity certificate - 3: RSA1024 AUTHENTICATE cell link certificate - - The certificate format is X509. - - To authenticate the server, the client 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 - are not expired. - * The certified key in the Link certificate matches the - link key that was used to negotiate the TLS connection. - * The certified key in the ID certificate is a 1024-bit RSA key. - * The certified key in the ID certificate was used to sign both - certificates. - * The link certificate is correctly signed with the key in the - ID certificate - * The ID certificate is correctly self-signed. - - If all of these conditions hold, then the client knows that it is - connected to the server whose identity key is certified in the ID - certificate. If any condition does not hold, the client closes - 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] - 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. - -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 NETINFO cell: once it has gotten a valid NETINFO cell - back, the client should consider the connection open, and the - server should consider the connection as opened by an - unauthenticated client. - - If a client wants to authenticate, it responds to the - AUTH_CHALLENGE cell with a CERT cell and an AUTHENTICATE cell. - The CERT cell is as a server would send, except that instead of - sending a CertType 1 cert for an arbitrary link certificate, the - client sends a CertType 3 cert for an RSA AUTHENTICATE key. - (This difference is because we allow any link key type on a TLS - link, but the protocol described here will only work for 1024-bit - RSA keys. A later protocol version should extend the protocol - here to work with non-1024-bit, non-RSA keys.) - - AuthType [2 octets] - 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: - - 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] - 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] - 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: - - 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] - 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 - section 0.3.) - [variable length] - - 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. - -3.5. Responding to extra cells, and other security checks. - - 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 - 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 - up using a v2 or v1 handshake. (More on this in section 6.4.) - - 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 - NETINFO cell that appears at any other time or out of sequence. - - A client should not begin a v3 negotiation with any sequence - other than "VERSIONS, NETINFO" or "VERSIONS, CERT, AUTHENTICATE, - NETINFO". A server SHOULD drop a CERT, AUTH_CHALLENGE, or - NETINFO cell that appears at any other time or out of sequence. - -4. Numbers to assign - - We need a version number for this link protocol. I've been - calling it "3". - - 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. - -5. Efficiency - - This protocol adds a round-trip step when the client sends a - VERSIONS cell to the server, and waits for the {VERSIONS, CERT, - NETINFO} response in turn. (The server then waits for the - client's {NETINFO} or {CERT, AUTHENTICATE, NETINFO} reply, - but it would have already been waiting for the client's NETINFO, - so that's not an additional wait.) - - This is actually fewer round-trip steps than required before for - TLS renegotiation, so that's a win over v2. - -6. Security argument - - These aren't crypto proofs, since I don't write those. They are - meant be reasonably convincing. - -6.1. The server is authenticated - - TLS guarantees that if the TLS handshake completes successfully, - the client knows that it is speaking to somebody who knows the - private key corresponding to the public link key that was used in - the TLS handshake. - - Because this public link key is signed by the server's identity - key in the CERT cell, the client knows that somebody who holds - the server's private identity key says that the server's public - link key corresponds to the server's public identity key. - - Therefore, if the crypto works, and if TLS works, and if the keys - aren't compromised, then the client is talking to somebody who - holds the server's private identity key. - -6.2. The client is authenticated - - Once the server has checked the client's certificates, the server - knows that somebody who knows the client's private identity key - says that he is the one holding the private key corresponding to - the client's presented link-authentication public key. - - Once the server has checked the signature in the AUTHENTICATE - cell, the server knows that somebody holding the client's - link-authentication private key signed the data in question. By - the standard certification argument above, the server knows that - somebody holding the client's private identity key signed the - data in question. - - So the server's remaining question is: am I really talking to - somebody holding the client's identity key, or am I getting a - replayed or MITM'd AUTHENTICATE cell that was previously sent by - the client? - - If the client included a non-zero 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 - 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 - before. The server knows that it is not getting a MITM'd - AUTHENTICATE cell, since the cell includes a hash of the server's - link certificate, which nobody else should have been able to use - in a successful TLS negotiation. - -6.3. MITM attacks won't work any better than they do against TLS - - TLS guarantees that a man-in-the-middle attacker can't read the - content of a successfully negotiated encrypted connection, nor - alter the content in any way other than truncating it, unless he - compromises the session keys or one of the key-exchange secret - keys used to establish that connection. Let's make sure we do at - least that well. - - Suppose that a client Alice connects to an MITM attacker Mallory, - thinking that he is connecting to some server Bob. Let's assume - that the TLS handshake between Alice and Mallory finishes - successfully and the v3 protocol is chosen. [If the v1 or v2 - protocol is chosen, those already resist MITM. If the TLS - handshake doesn't complete, then Alice isn't connected to anybody.] - - During the v3 handshake, Mallory can't convince Alice that she is - talking to Bob, since she should not be able to produce a CERT - cell containing a certificate chain signed by Bob's identity key - and used to authenticate the link key that Mallory used during - TLS. (If Mallory used her own link key for the TLS handshake, it - won't match anything Bob signed unless Bob is compromised. - Mallory can't use any key that Bob _did_ produce a certificate - for, since she doesn't know the private key.) - - Even if Alice fails to check the certificates from Bob, Mallory - still can't convince Bob that she is really Alice. Assuming that - Alice's keys aren't compromised, Mallory can't sent a CERT cell - with a cert chain from Alice's identity key to a key that Mallory - controls, so if Mallory wants to impersonate Alice's identity - key, she can only do so by sending an AUTHENTICATE cell really - generated by Alice. Because Bob will check that the random bytes - in the AUTH_CHALLENGE cell will influence the SLOG hash, Mallory - needs to send Bob's challenge to Alice, and can't use any other - AUTHENTICATE cell that Alice generated before. But because the - AUTHENTICATE cell Alice will generate will include in the SCERT - field a hash of the link certificate used by Mallory, Bob will - reject it as not being valid to connect to him. - -6.4. Protocol downgrade attacks won't work. - - Assuming that Alice checks the certificates from Bob, she knows - that Bob really sent her the VERSION cell that she received. - - Because the AUTHENTICATE cell from Alice includes signed hashes - of the VERSIONS cells from Alice and Bob, Bob knows that Alice - got the VERSIONS cell he sent and sent the VERSIONS cell that he - received. - - But what about attempts to downgrade the protocol earlier in the - handshake? Here TLS comes to the rescue: because the TLS - Finished handshake message includes an authenticated digest of - everything previously said during the handshake, an attacker - can't replace the client's ciphersuite list (to trigger a - downgrade to the v1 protocol) or the server's certificate [chain] - (to trigger a downgrade to the v1 or v2 protocol). - -7. Design considerations - - I previously considered adding our own certificate format in - order to avoid the pain associated with X509, but decided instead - to simply use X509 since a correct Tor implementation will - already need to have X509 code to handle the other handshake - versions and to use TLS. - - The trickiest part of the design here is deciding what to stick - in the AUTHENTICATE cell. Some of it is strictly necessary, and - some of it is left there for security margin in case my other - security arguments fail. Because of the CID and SID elements - you can't use an AUTHENTICATE cell for anything other than - authenticating a client ID to a server with an appropriate - server ID. The SLOG and CLOG elements are there mostly to - authenticate the VERSIONS cells and resist downgrade attacks - once there are two versions of this. The presence of the - AUTH_CHALLENGE field in the stuff authenticated in SLOG - prevents replays and ensures that the AUTHENTICATE cell was - really generated by somebody who is reading what the server is - sending over the TLS connection. The SCERT element is meant to - prevent MITM attacks. When the TLSSECRET field is - 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. - - If the client checks the server's certificates and matches them - to the TLS connection link key before proceding with the - handshake, then signing the contents of the AUTH_CHALLENGE cell - would be sufficient to authenticate the client. But implementers - of allegedly compatible Tor clients have in the past skipped - certificate verification steps, and I didn't want a client's - failure to verify certificates to mean that a server couldn't - trust that he was really talking to the client. To prevent this, - I added the TLS link certificate to the authenticated data: even - if the Tor client code doesn't check any certificates, the TLS - library code will still check that the certificate used in the - handshake contains a link key that matches the one used in the - handshake. - -8. Open questions: - - - May we cache which certificates we've already verified? It - might leak in timing whether we've connected with a given server - before, and how recently. - - - With which TLS libraries is it feasible to yoink client_random, - server_random, and the master secret? If the answer is "All - free C TLS libraries", great. If the answer is "OpenSSL only", - not so great. - - - Should we do anything to check the timestamp in the AUTHENTICATE - cell? - - - 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 - servers that support it, and fall back to V1 otherwise. - - - What should servers that don't have TLS renegotiation do? For - now, I think they should just stick with V1. Eventually we can - deprecate the V2 handshake as we did with the V1 handshake. - When that happens, servers can be V3-only. |