proposals/195-TLS-normalization-for-024.txt

   1 Filename: 195-TLS-normalization-for-024.txt
   2 Title: TLS certificate normalization for Tor 0.2.4.x
   3 Author: Jacob Appelbaum, Gladys Shufflebottom, Nick Mathewson, Tim Wilde
   4 Created: 6-Mar-2012
   5 Status: Draft
   6 Target: 0.2.4.x
   7
   8
   9 0. Introduction
  10
  11    The TLS (Transport Layer Security) protocol was designed for security
  12    and extensibility, not for uniformity.  Because of this, it's not
  13    hard for an attacker to tell one application's use of TLS from
  14    another's.
  15
  16    We proposes improvements to Tor's current TLS certificates to
  17    reduce the distinguishability of Tor traffic.
  18
  19 0.1. History
  20
  21    This draft is based on parts of Proposal 179, by Jacob Appelbaum
  22    and Gladys Shufflebottom, but removes some already implemented parts
  23    and replaces others.
  24
  25 0.2. Non-Goals
  26
  27    We do not address making TLS harder to distinguish after the
  28    handshake is done.  We also do not discuss TLS improvements not
  29    related to distinguishability (such as increased key size, algorithm
  30    choice, and so on).
  31
  32 1. Certificate Issues
  33
  34    Currently, Tor generates certificates according to a fixed pattern,
  35    where lifetime is fairly small, the certificate Subject DN is a
  36    single randomly generated CN, and the certificate Issuer DN is a
  37    different single randomly generated CN.
  38
  39    We propose several ways to improve this below.
  40
  41 1.1. Separate initial certificate from link certificate
  42
  43    When Tor is using the v2 or v3 link handshake (see tor-spec.txt), it
  44    currently presents an initial handshake authenticating the link key
  45    with the identity key.
  46
  47    We propose instead that Tor should be able to present an arbitrary
  48    initial certificate (so long as its key matches the link key used in
  49    the actual TLS handshake), and then present the real certificate
  50    authenticating the link key during the Tor handshake.  (That is,
  51    during the v2 handshake's renegotiation step, or in the v3
  52    handshake's CERTS cell.)
  53
  54    The TLS protocol and the Tor handshake protocol both allow this, and
  55    doing so will give us more freedom for the alternative certificate
  56    presentation ideas below.
  57
  58 1.2. Allow externally generated certificates
  59
  60    It should be possible for a Tor relay operator to generate and
  61    provide their own certificate and secret key.  This will allow a relay or
  62    bridge operator to use a certificate signed by any member of the "SSL
  63    mafia,"[*] to generate their own self-signed certificate, and so on.
  64
  65    For compatibility, we need to require that the key be an RSA secret
  66    key, of at least 1024 bits, generated with e=65537.
  67
  68    As a proposed interface, let's require that the certificate be stored
  69    in ${DataDir}/tls_cert/tls_certificate.crt , that the secret key be
  70    stored in ${DataDir}/tls_cert/private_tls_key.key , and that they be
  71    used instead of generating our own certificate whenever the new
  72    boolean option "ProvidedTLSCert" is set to true.
  73
  74    (Alternative interface: Allow the cert and key cert to be stored
  75    wherever, and have the user provide their respective locations with
  76    TLSCertificateFile and TLSCertificateKeyFile options.)
  77
  78 1.3. Longer certificate lifetimes
  79
  80    Tor's current certificates aren't long-lived, which makes them
  81    different from most other certificates in the wild.
  82
  83    Typically, certificates are valid for a year, so let's use that as
  84    our default lifetime.  [TODO: investigate whether "a year" for most
  85    CAs and self-signed certs have their validity dates running for a
  86    calendar year ending at the second of issue, one calendar year
  87    ending at midnight, or 86400*(365.5 +/- .5) seconds, or what.]
  88
  89    There are two ways to approach this.  We could continue our current
  90    certificate management approach where we frequently generate new
  91    certificates (albeit with longer lifetimes), or we could make a cert,
  92    store it to disk, and use it for all or most of its declared
  93    lifetime.
  94
  95    If we continue to use fairly short lifetimes for the _true_ link
  96    certificates (the ones presented during the Tor handshake), then
  97    presenting long-lived certificates doesn't hurt us much: in the event
  98    of a link-key-only compromise, the adversary still couldn't actually
  99    impersonate a server for long.[**]
 100
 101    Using shorter-lived certificates with long nominal lifetimes doesn't
 102    seem to buy us much.  It would let us rotate link keys more
 103    frequently, but we're already getting forward secrecy from our use of
 104    diffie-hellman key agreement.  Further, it would make our behavior
 105    look less like regular TLS behavior, where certificates are typically
 106    used for most of their nominal lifetime.  Therefore, let's store and
 107    use certs and link keys for the full year.
 108
 109 1.4. Self-signed certificates with better DNs
 110
 111    When we generate our own certificates, we currently set no DN fields
 112    other than the commonName.  This behavior isn't terribly common:
 113    users of self-signed certs usually/often set other fields too.
 114    [TODO: find out frequency.]
 115
 116    Unfortunately, it appears that no particular other set of fields or
 117    way of filling them out _is_ universal for self-signed certificates,
 118    or even particularly common.  The most common schema seem to be for
 119    things most censors wouldn't mind blocking, like embedded devices.
 120    Even the default openssl schema, though common, doesn't appear to
 121    represent a terribly large fraction of self-signed websites.  [TODO:
 122    get numbers here.]
 123
 124    So the best we can do here is probably to reproduce the process that
 125    results in self-signed certificates originally: let the bridge and relay
 126    operators to pick the DN fields themselves.  This is an annoying
 127    interface issue, and wants a better solution.
 128
 129 1.5. Better commonName values
 130
 131    Our current certificates set the commonName to a randomly generated
 132    field like www.rmf4h4h.net.  This is also a weird behavior: nearly
 133    all TLS certs used for web purposes will have a hostname that
 134    resolves to their IP.
 135
 136    The simplest way to get a plausible commonName here would be to do a
 137    reverse lookup on our IP and try to find a good hostname.  It's not
 138    clear whether this would actually work out in practice, or whether
 139    we'd just get dynamic-IP-pool hostnames everywhere blocked when they
 140    appear in certificates.
 141
 142    Alternatively, if we are told a hostname in our Torrc (possibly in
 143    the Address field), we could try to use that.
 144
 145 2. TLS handshake issues
 146
 147 2.1. Session ID.
 148
 149    Currently we do not send an SSL session ID, as we do not support session
 150    resumption.  However, Apache (and likely other major SSL servers) do have
 151    this support, and do send a 32 byte SSLv3/TLSv1 session ID in their Server
 152    Hello cleartext.  We should do the same to avoid an easy fingerprinting
 153    opportunity.  It may be necessary to lie to OpenSSL to claim that we are
 154    tracking session IDs to cause it to generate them for us.
 155
 156    (We should not actually support session resumption.)
 157
 158
 159
 160
 161 [*] "Hey buddy, it's a nice website you've got there.  Sure would be a
 162     shame if somebody started poppin' up warnings on all your user's
 163     browsers, tellin' everbody that you're _insecure_..."
 164
 165 [**] Furthermore, a link-key-only compromise isn't very realistic atm;
 166      nearly any attack that would let an adversary learn a link key would
 167      probably let the adversary learn the identity key too.  The most
 168      plausible way would probably be an implementation bug in OpenSSL or
 169      something.
 170