On Mon, Jan 31, 2011 at 09:50:06PM -0500, Nick Mathewson wrote:
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
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.
Does this proposal address this goal in any way? I don't see why it's on the list.
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.
Or this goal. Or do we simply mean here that proposal 176's results should not prevent results from other proposals like 179?
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
Would probably be clearer to append an explicit line here:
C->S: NETINFO cell
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.
I assume you mean "or using a key longer than 1024 bits."
If the client implements this proposal, however, and the server has shown it can understand the V3+ handshake protocol, the
This is the first point where you use "V3+" where you had otherwise used "V3". Should the + just be implicit, or do you mean to imply something different when you say V3+ vs V3? I don't see how we can predict that a given behavior could imply V4 without knowing what V4 will be.
An AUTH_CHALLENGE cell is a variable-length cell with the following fields: Challenge [32 octets]
On IRC you suggested that the AUTH_CHALLENGE cell might want to list the authtypes it knows how to parse. Thus if we bump the AuthType version, we may not need to bump the whole link version.
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.
The word 'back' is misleading here, since it implies that the server waits to send its netinfo cell until it sees one from the client.
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 byte 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]
In the server section you specify that the randomness needs to be strong. Does the omission of that specification for the client mean it doesn't need to be? :)
(I'd hate for somebody to misinterpret 'nonce' as 'value that was not previously used', and implement it as a counter, which would do perfectly fine for the protocol but also reveal how many authenticate cells we've sent since the last time you saw one.)
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.
You mean extra bytes after the signature?
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.
Sounds good to me.
Security argument
These aren't crypto proofs, since I don't write those. They are meant be reasonably convincing.
They look plausible to me.
- 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.
Would this be much of a win anyway? Seems like more code for not much of a win.
- 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.
Good question.
- Should we do anything to check the timestamp in the AUTHENTICATE cell?
Does having the timestamp give us anything that having the nonce doesn't already provide?
I pondered for a while that it might actually be bad to have the timestamp there, since its offset from 'real' time is a cookie that lets us track the user. But there are plenty of other ways that we can learn the client's time, like the NETINFO 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.
Given that corporations like Bluecoat sell censorship devices that censor our V2 handshake -- and we've seen them deployed in Syria -- but we know of no places that censor our V1 handshake, it would not be crazy to declare that V3-supporting clients all prefer V1 to V2.
That said, bridges are a good example of a case where we don't know the server version, and also a prime use case here.
One hack would be to change Tor versions that don't support V3 (like 0.2.2.x) so they don't support V2.
*That* said, I think we shouldn't waste too much time on this topic. There aren't any Tors that can't renegotiate now (if we ignore Tor clients in Syria), so if we are forced to make some in the future before V3 is deployed, we could just make those Tors only support V1.
- 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.
Who are these servers you're thinking of?
--Roger