mirrors/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2025-02-24 06:48:05 +01:00
Code Issues Projects Releases Wiki Activity

r11789@catbus: nickm | 2007-02-12 22:42:58 -0500

Browse source 
Merge proposal 106 into tor-spec.txt; reformat it slightly; mark it closed.


svn:r9576
This commit is contained in:
Nick Mathewson 2007-02-13 03:43:03 +00:00
parent d9c095be3e
commit a7f1b165e4
3 changed files with 41 additions and 38 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/spec/proposals/000-index.txt
View file

@ -24,5 +24,5 @@ Proposals by number:
103 Splitting identity key from regularly used signing key [OPEN] 103 Splitting identity key from regularly used signing key [OPEN]
104 Long and Short Router Descriptors [OPEN] 104 Long and Short Router Descriptors [OPEN]
105 Version negotiation for the Tor protocol [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]

46
doc/spec/proposals/106-less-tls-constraint.txt
View file

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

11
doc/spec/tor-spec.txt
View file

@ -149,7 +149,7 @@ see tor-design.pdf.
support any suite without ephemeral keys, symmetric keys of at support any suite without ephemeral keys, symmetric keys of at
least KEY_LEN bits, and digests of at least HASH_LEN bits. 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 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 traffic for other Tor users, or an onion proxy (OP) if it only handles
local requests. Onion proxies SHOULD NOT provide long-term-trackable 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. the key is not as expected, the party must close the connection.
All parties SHOULD reject connections to or from ORs that have malformed All parties SHOULD reject connections to or from ORs that have malformed
or missing certificates. ORs MAY accept or reject connections from OPs or missing certificates. ORs SHOULD NOT reject incoming connections from
with malformed or missing certificates. 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 Once a TLS connection is established, the two sides send cells
(specified below) to one another. Cells are sent serially. All (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, 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 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 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 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. an MSB of 0; otherwise, it chooses a CircID with an MSB of 1.