diff options
| -rw-r--r-- | proposals/000-index.txt | 2 | ||||
| -rw-r--r-- | proposals/106-less-tls-constraint.txt | 66 | ||||
| -rw-r--r-- | tor-spec.txt | 11 |
3 files changed, 41 insertions, 38 deletions
diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 9cd76f2..cdf9254 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -24,5 +24,5 @@ Proposals by number: 103 Splitting identity key from regularly used signing key [OPEN] 104 Long and Short Router Descriptors [OPEN] 105 Version negotiation for the Tor protocol [OPEN] -106 Checking fewer things during TLS handshakes [FINISHED] +106 Checking fewer things during TLS handshakes [CLOSED] diff --git a/proposals/106-less-tls-constraint.txt b/proposals/106-less-tls-constraint.txt index f44532e..6f53497 100644 --- a/proposals/106-less-tls-constraint.txt +++ b/proposals/106-less-tls-constraint.txt @@ -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. diff --git a/tor-spec.txt b/tor-spec.txt index f27901e..4c9d16d 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -149,7 +149,7 @@ see tor-design.pdf. support any suite without ephemeral keys, symmetric keys of at least KEY_LEN bits, and digests of at least HASH_LEN bits. - Even though the connection protocol is identical, we think of the + Even though the connection protocol is identical, we will think of the initiator as either an onion router (OR) if it is willing to relay traffic for other Tor users, or an onion proxy (OP) if it only handles local requests. Onion proxies SHOULD NOT provide long-term-trackable @@ -175,8 +175,11 @@ see tor-design.pdf. the key is not as expected, the party must close the connection. All parties SHOULD reject connections to or from ORs that have malformed - or missing certificates. ORs MAY accept or reject connections from OPs - with malformed or missing certificates. + or missing certificates. ORs SHOULD NOT reject incoming connections from + OPs with malformed or missing certificates. + + [Before version 0.1.2.8-rc, ORs rejected incoming connections from ORs and + OPs alike if their certificates were missing or malformed.] Once a TLS connection is established, the two sides send cells (specified below) to one another. Cells are sent serially. All @@ -286,7 +289,7 @@ see tor-design.pdf. The CircID for a CREATE cell is an arbitrarily chosen 2-byte integer, selected by the node (OP or OR) that sends the CREATE cell. To prevent - CircID collisions, when one OR sends a CREATE cell to another, it chooses + CircID collisions, when one OR sends a CREATE cell to another OR, it chooses from only one half of the possible values based on the ORs' public identity keys: if the sending OR has a lower key, it chooses a CircID with an MSB of 0; otherwise, it chooses a CircID with an MSB of 1. |