nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-24 12:23:32 +01:00
Code Issues Packages Projects Releases Wiki Activity

106 sounds like a great proposal. let's do it.

Browse Source 
svn:r9547
This commit is contained in:
Roger Dingledine 2007-02-10 20:00:06 +00:00
parent 01ddb05fba
commit da041c5350
1 changed files with 11 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
doc/spec/proposals/106-less-tls-constraint.txt
View File

@ -1,4 +1,4 @@
Filename: 105-less-tls-constraint.txt Filename: 106-less-tls-constraint.txt
Title: Checking fewer things during TLS handshakes Title: Checking fewer things during TLS handshakes
Version: $Revision: 12105 $ Version: $Revision: 12105 $
Last-Modified: $Date: 2007-01-30T07:50:01.643717Z $ Last-Modified: $Date: 2007-01-30T07:50:01.643717Z $
@ -15,8 +15,10 @@ Motivation:
Later, we want to try harder to avoid protocol fingerprinting attacks. Later, we want to try harder to avoid protocol fingerprinting attacks.
This means that we'll need to make our connection handshake look closer This means that we'll need to make our connection handshake look closer
to a regular HTTPS connection. For now, about the best we can do is to to a regular HTTPS connection: one certificate on the server side and
stop requiring things during handshake that we don't actually use. zero certificates on the client side. For now, about the best we
can do is to stop requiring things during handshake that we don't
actually use.
What we check now, and where we check it: What we check now, and where we check it:
@ -26,7 +28,7 @@ tor_tls_check_lifetime:
tor_tls_verify: tor_tls_verify:
peer has at least one certificate peer has at least one certificate
There is at lease 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
negotiate the connection. (The "identity cert".) negotiate the connection. (The "identity cert".)
The certificate _not_ used to negotiate the connection has signed the The certificate _not_ used to negotiate the connection has signed the
@ -56,16 +58,19 @@ USEFUL THINGS WE COULD DO:
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
a client and don't treat them as a server. great. -rd]
[2] Instead of using a restricted nickname character set that make 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.
Alternatively, we could stop checking commonNames entirely. We don't Alternatively, we could stop checking commonNames entirely. We don't
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]
REMAINING WAYS TO RECOGNIZE CLIENT->SERVER CONNECTIONS: REMAINING WAYS TO RECOGNIZE CLIENT->SERVER CONNECTIONS: