proposals/106-less-tls-constraint.txt

   1 Filename: 106-less-tls-constraint.txt
   2 Title: Checking fewer things during TLS handshakes
   3 Author: Nick Mathewson
   4 Created: 9-Feb-2007
   5 Status: Closed
   6 Implemented-In: 0.2.0.x
   7
   8 Overview:
   9
  10     This document proposes that we relax our requirements on the context of
  11     X.509 certificates during initial TLS handshakes.
  12
  13 Motivation:
  14
  15     Later, we want to try harder to avoid protocol fingerprinting attacks.
  16     This means that we'll need to make our connection handshake look closer
  17     to a regular HTTPS connection: one certificate on the server side and
  18     zero certificates on the client side.  For now, about the best we
  19     can do is to stop requiring things during handshake that we don't
  20     actually use.
  21
  22 What we check now, and where we check it:
  23
  24  tor_tls_check_lifetime:
  25     peer has certificate
  26     notBefore <= now <= notAfter
  27
  28  tor_tls_verify:
  29     peer has at least one certificate
  30     There is at least one certificate in the chain
  31     At least one of the certificates in the chain is not the one used to
  32         negotiate the connection.  (The "identity cert".)
  33     The certificate _not_ used to negotiate the connection has signed the
  34         link cert
  35
  36  tor_tls_get_peer_cert_nickname:
  37     peer has a certificate.
  38     certificate has a subjectName.
  39     subjectName has a commonName.
  40     commonName consists only of characters in LEGAL_NICKNAME_CHARACTERS. [2]
  41
  42  tor_tls_peer_has_cert:
  43     peer has a certificate.
  44
  45  connection_or_check_valid_handshake:
  46     tor_tls_peer_has_cert [1]
  47     tor_tls_get_peer_cert_nickname [1]
  48     tor_tls_verify [1]
  49     If nickname in cert is a known, named router, then its identity digest
  50         must be as expected.
  51     If we initiated the connection, then we got the identity digest we
  52         expected.
  53
  54  USEFUL THINGS WE COULD DO:
  55
  56  [1] We could just not force clients to have any certificate at all, let alone
  57      an identity certificate.  Internally to the code, we could assign the
  58      identity_digest field of these or_connections to a random number, or even
  59      not add them to the identity_digest->or_conn map.
  60  [so if somebody connects with no certs, we let them. and mark them as
  61  a client and don't treat them as a server. great. -rd]
  62
  63  [2] Instead of using a restricted nickname character set that makes our
  64      commonName structure look unlike typical SSL certificates, we could treat
  65      the nickname as extending from the start of the commonName up to but not
  66      including the first non-nickname character.
  67
  68      Alternatively, we could stop checking commonNames entirely.  We don't
  69      actually _do_ anything based on the nickname in the certificate, so
  70      there's really no harm in letting every router have any commonName it
  71      wants.
  72  [this is the better choice -rd]
  73  [agreed. -nm]
  74
  75 REMAINING WAYS TO RECOGNIZE CLIENT->SERVER CONNECTIONS:
  76
  77  Assuming that we removed the above requirements, we could then (in a later
  78  release) have clients not send certificates, and sometimes and started
  79  making our DNs a little less formulaic, client->server OR connections would
  80  still be recognizable by:
  81     having a two-certificate chain sent by the server
  82     using a particular set of ciphersuites
  83     traffic patterns
  84     probing the server later
  85
  86 OTHER IMPLICATIONS:
  87
  88  If we stop verifying the above requirements:
  89
  90     It will be slightly (but only slightly) more common to connect to a non-Tor
  91     server running TLS, and believe that you're talking to a Tor server (until
  92     you send the first cell).
  93
  94     It will be far easier for non-Tor SSL clients to accidentally connect to
  95     Tor servers and speak HTTPS or whatever to them.
  96
  97  If, in a later release, we have clients not send certificates, and we make
  98  DNs less recognizable:
  99
 100     If clients don't send certs, servers don't need to verify them: win!
 101
 102     If we remove these restrictions, it will be easier for people to write
 103     clients to fuzz our protocol: sorta win!
 104
 105     If clients don't send certs, they look slightly less like servers.
 106
 107 OTHER SPEC CHANGES:
 108
 109  When a client doesn't give us an identity, we should never extend any
 110  circuits to it (duh), and we should allow it to set circuit ID however it
 111  wants.