mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2025-02-23 22:47:12 +01:00
r11789@catbus: nickm | 2007-02-12 22:42:58 -0500
Merge proposal 106 into tor-spec.txt; reformat it slightly; mark it closed. svn:r9576
This commit is contained in:
Nick Mathewson
parent
d9c095be3e
commit
a7f1b165e4
3 changed files with 41 additions and 38 deletions
|
|
@ -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]
|
||||
|
||||
|
|
|
|||
|
|
@ -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,16 +52,16 @@ 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
|
||||
[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]
|
||||
[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
|
||||
[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.
|
||||
|
|
@ -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
|
||||
there's really no harm in letting every router have any commonName it
|
||||
wants.
|
||||
[this is the better choice -rd]
|
||||
[agreed. -nm]
|
||||
[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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue