|
|
@@ -4,7 +4,7 @@ Version: $Revision: 12105 $
|
|
|
Last-Modified: $Date: 2007-01-30T07:50:01.643717Z $
|
|
|
Author: Nick Mathewson
|
|
|
Created:
|
|
|
-Status: Finished
|
|
|
+Status: Closed
|
|
|
|
|
|
Overview:
|
|
|
|
|
|
@@ -22,11 +22,11 @@ Motivation:
|
|
|
|
|
|
What we check now, and where we check it:
|
|
|
|
|
|
-tor_tls_check_lifetime:
|
|
|
+ tor_tls_check_lifetime:
|
|
|
peer has certificate
|
|
|
notBefore <= now <= notAfter
|
|
|
|
|
|
-tor_tls_verify:
|
|
|
+ tor_tls_verify:
|
|
|
peer has at least one certificate
|
|
|
There is at least one certificate in the chain
|
|
|
At least one of the certificates in the chain is not the one used to
|
|
|
@@ -34,16 +34,16 @@ tor_tls_verify:
|
|
|
The certificate _not_ used to negotiate the connection has signed the
|
|
|
link cert
|
|
|
|
|
|
-tor_tls_get_peer_cert_nickname:
|
|
|
+ tor_tls_get_peer_cert_nickname:
|
|
|
peer has a certificate.
|
|
|
certificate has a subjectName.
|
|
|
subjectName has a commonName.
|
|
|
commonName consists only of characters in LEGAL_NICKNAME_CHARACTERS. [2]
|
|
|
|
|
|
-tor_tls_peer_has_cert:
|
|
|
+ tor_tls_peer_has_cert:
|
|
|
peer has a certificate.
|
|
|
|
|
|
-connection_or_check_valid_handshake:
|
|
|
+ connection_or_check_valid_handshake:
|
|
|
tor_tls_peer_has_cert [1]
|
|
|
tor_tls_get_peer_cert_nickname [1]
|
|
|
tor_tls_verify [1]
|
|
|
@@ -52,33 +52,33 @@ connection_or_check_valid_handshake:
|
|
|
If we initiated the connection, then we got the identity digest we
|
|
|
expected.
|
|
|
|
|
|
-USEFUL THINGS WE COULD DO:
|
|
|
+ USEFUL THINGS WE COULD DO:
|
|
|
|
|
|
-[1] We could just not force clients to have any certificate at all, let alone
|
|
|
- an identity certificate. Internally to the code, we could assign the
|
|
|
- identity_digest field of these or_connections to a random number, or even
|
|
|
- not add them to the identity_digest->or_conn map.
|
|
|
-[so if somebody connects with no certs, we let them. and mark them as
|
|
|
-a client and don't treat them as a server. great. -rd]
|
|
|
+ [1] We could just not force clients to have any certificate at all, let alone
|
|
|
+ an identity certificate. Internally to the code, we could assign the
|
|
|
+ identity_digest field of these or_connections to a random number, or even
|
|
|
+ not add them to the identity_digest->or_conn map.
|
|
|
+ [so if somebody connects with no certs, we let them. and mark them as
|
|
|
+ a client and don't treat them as a server. great. -rd]
|
|
|
|
|
|
-[2] Instead of using a restricted nickname character set that makes our
|
|
|
- commonName structure look unlike typical SSL certificates, we could treat
|
|
|
- the nickname as extending from the start of the commonName up to but not
|
|
|
- including the first non-nickname character.
|
|
|
+ [2] Instead of using a restricted nickname character set that makes our
|
|
|
+ commonName structure look unlike typical SSL certificates, we could treat
|
|
|
+ the nickname as extending from the start of the commonName up to but not
|
|
|
+ including the first non-nickname character.
|
|
|
|
|
|
- Alternatively, we could stop checking commonNames entirely. We don't
|
|
|
- actually _do_ anything based on the nickname in the certificate, so
|
|
|
- there's really no harm in letting every router have any commonName it
|
|
|
- wants.
|
|
|
-[this is the better choice -rd]
|
|
|
-[agreed. -nm]
|
|
|
+ Alternatively, we could stop checking commonNames entirely. We don't
|
|
|
+ actually _do_ anything based on the nickname in the certificate, so
|
|
|
+ there's really no harm in letting every router have any commonName it
|
|
|
+ wants.
|
|
|
+ [this is the better choice -rd]
|
|
|
+ [agreed. -nm]
|
|
|
|
|
|
REMAINING WAYS TO RECOGNIZE CLIENT->SERVER CONNECTIONS:
|
|
|
|
|
|
-Assuming that we removed the above requirements, we could then (in a later
|
|
|
-release) have clients not send certificates, and sometimes and started making
|
|
|
-our DNs a little less formulaic, client->server OR connections would still be
|
|
|
-recognizable by:
|
|
|
+ Assuming that we removed the above requirements, we could then (in a later
|
|
|
+ release) have clients not send certificates, and sometimes and started
|
|
|
+ making our DNs a little less formulaic, client->server OR connections would
|
|
|
+ still be recognizable by:
|
|
|
having a two-certificate chain sent by the server
|
|
|
using a particular set of ciphersuites
|
|
|
traffic patterns
|
|
|
@@ -86,7 +86,7 @@ recognizable by:
|
|
|
|
|
|
OTHER IMPLICATIONS:
|
|
|
|
|
|
-If we stop verifying the above requirements:
|
|
|
+ If we stop verifying the above requirements:
|
|
|
|
|
|
It will be slightly (but only slightly) more common to connect to a non-Tor
|
|
|
server running TLS, and believe that you're talking to a Tor server (until
|
|
|
@@ -95,8 +95,8 @@ If we stop verifying the above requirements:
|
|
|
It will be far easier for non-Tor SSL clients to accidentally connect to
|
|
|
Tor servers and speak HTTPS or whatever to them.
|
|
|
|
|
|
-If, in a later release, we have clients not send certificates, and we make
|
|
|
-DNs less recognizable:
|
|
|
+ If, in a later release, we have clients not send certificates, and we make
|
|
|
+ DNs less recognizable:
|
|
|
|
|
|
If clients don't send certs, servers don't need to verify them: win!
|
|
|
|
|
|
@@ -107,6 +107,6 @@ DNs less recognizable:
|
|
|
|
|
|
OTHER SPEC CHANGES:
|
|
|
|
|
|
-When a client doesn't give us an identity, we should never extend any
|
|
|
-circuits to it (duh), and we should allow it to set circuit ID however it
|
|
|
-wants.
|
|
|
+ When a client doesn't give us an identity, we should never extend any
|
|
|
+ circuits to it (duh), and we should allow it to set circuit ID however it
|
|
|
+ wants.
|
Nick Mathewson