mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-12-11 05:03:34 +01:00
113 lines
4.1 KiB
Plaintext
113 lines
4.1 KiB
Plaintext
Filename: 106-less-tls-constraint.txt
|
|
Title: Checking fewer things during TLS handshakes
|
|
Version: $Revision$
|
|
Last-Modified: $Date$
|
|
Author: Nick Mathewson
|
|
Created: 9-Feb-2007
|
|
Status: Closed
|
|
|
|
Overview:
|
|
|
|
This document proposes that we relax our requirements on the context of
|
|
X.509 certificates during initial TLS handshakes.
|
|
|
|
Motivation:
|
|
|
|
Later, we want to try harder to avoid protocol fingerprinting attacks.
|
|
This means that we'll need to make our connection handshake look closer
|
|
to a regular HTTPS connection: one certificate on the server side and
|
|
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:
|
|
|
|
tor_tls_check_lifetime:
|
|
peer has certificate
|
|
notBefore <= now <= notAfter
|
|
|
|
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
|
|
negotiate the connection. (The "identity cert".)
|
|
The certificate _not_ used to negotiate the connection has signed the
|
|
link cert
|
|
|
|
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:
|
|
peer has a certificate.
|
|
|
|
connection_or_check_valid_handshake:
|
|
tor_tls_peer_has_cert [1]
|
|
tor_tls_get_peer_cert_nickname [1]
|
|
tor_tls_verify [1]
|
|
If nickname in cert is a known, named router, then its identity digest
|
|
must be as expected.
|
|
If we initiated the connection, then we got the identity digest we
|
|
expected.
|
|
|
|
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]
|
|
|
|
[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]
|
|
|
|
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:
|
|
having a two-certificate chain sent by the server
|
|
using a particular set of ciphersuites
|
|
traffic patterns
|
|
probing the server later
|
|
|
|
OTHER IMPLICATIONS:
|
|
|
|
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
|
|
you send the first cell).
|
|
|
|
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 clients don't send certs, servers don't need to verify them: win!
|
|
|
|
If we remove these restrictions, it will be easier for people to write
|
|
clients to fuzz our protocol: sorta win!
|
|
|
|
If clients don't send certs, they look slightly less like servers.
|
|
|
|
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.
|