Draft-status proposal 195: normalize TLS in 0.2.4

1 files changed, 170 insertions, 0 deletions

diff --git a/proposals/195-TLS-normalization-for-024.txt b/proposals/195-TLS-normalization-for-024.txt
new file mode 100644
index 0000000..37ee546
--- /dev/null
+++ b/proposals/195-TLS-normalization-for-024.txt
@@ -0,0 +1,170 @@
+Filename: 195-TLS-normalization-for-024.txt
+Title: TLS certificate normalization for Tor 0.2.4.x
+Author: Jacob Appelbaum, Gladys Shufflebottom, Nick Mathewson, Tim Wilde
+Created: 6-Mar-2012
+Status: Draft
+Target: 0.2.4.x
+
+
+0. Introduction
+
+   The TLS (Transport Layer Security) protocol was designed for security
+   and extensibility, not for uniformity.  Because of this, it's not
+   hard for an attacker to tell one application's use of TLS from
+   another's.
+
+   We proposes improvements to Tor's current TLS certificates to
+   reduce the distinguishability of Tor traffic.
+
+0.1. History
+
+   This draft is based on parts of Proposal 179, by Jacob Appelbaum
+   and Gladys Shufflebottom, but removes some already implemented parts
+   and replaces others.
+
+0.2. Non-Goals
+
+   We do not address making TLS harder to distinguish after the
+   handshake is done.  We also do not discuss TLS improvements not
+   related to distinguishability (such as increased key size, algorithm
+   choice, and so on).
+
+1. Certificate Issues
+
+   Currently, Tor generates certificates according to a fixed pattern,
+   where lifetime is fairly small, the certificate Subject DN is a
+   single randomly generated CN, and the certificate Issuer DN is a
+   different single randomly generated CN.
+
+   We propose several ways to improve this below.
+
+1.1. Separate initial certificate from link certificate
+
+   When Tor is using the v2 or v3 link handshake (see tor-spec.txt), it
+   currently presents an initial handshake authenticating the link key
+   with the identity key.
+
+   We propose instead that Tor should be able to present an arbitrary
+   initial certificate (so long as its key matches the link key used in
+   the actual TLS handshake), and then present the real certificate
+   authenticating the link key during the Tor handshake.  (That is,
+   during the v2 handshake's renegotiation step, or in the v3
+   handshake's CERTS cell.)
+
+   The TLS protocol and the Tor handshake protocol both allow this, and
+   doing so will give us more freedom for the alternative certificate
+   presentation ideas below.
+
+1.2. Allow externally generated certificates
+
+   It should be possible for a Tor relay operator to generate and
+   provide their own certificate and secret key.  This will allow a relay or
+   bridge operator to use a certificate signed by any member of the "SSL
+   mafia,"[*] to generate their own self-signed certificate, and so on.
+
+   For compatibility, we need to require that the key be an RSA secret
+   key, of at least 1024 bits, generated with e=65537.
+
+   As a proposed interface, let's require that the certificate be stored
+   in ${DataDir}/tls_cert/tls_certificate.crt , that the secret key be
+   stored in ${DataDir}/tls_cert/private_tls_key.key , and that they be
+   used instead of generating our own certificate whenever the new
+   boolean option "ProvidedTLSCert" is set to true.
+
+   (Alternative interface: Allow the cert and key cert to be stored
+   wherever, and have the user provide their respective locations with
+   TLSCertificateFile and TLSCertificateKeyFile options.)
+
+1.3. Longer certificate lifetimes
+
+   Tor's current certificates aren't long-lived, which makes them
+   different from most other certificates in the wild.
+
+   Typically, certificates are valid for a year, so let's use that as
+   our default lifetime.  [TODO: investigate whether "a year" for most
+   CAs and self-signed certs have their validity dates running for a
+   calendar year ending at the second of issue, one calendar year
+   ending at midnight, or 86400*(365.5 +/- .5) seconds, or what.]
+
+   There are two ways to approach this.  We could continue our current
+   certificate management approach where we frequently generate new
+   certificates (albeit with longer lifetimes), or we could make a cert,
+   store it to disk, and use it for all or most of its declared
+   lifetime.
+
+   If we continue to use fairly short lifetimes for the _true_ link
+   certificates (the ones presented during the Tor handshake), then
+   presenting long-lived certificates doesn't hurt us much: in the event
+   of a link-key-only compromise, the adversary still couldn't actually
+   impersonate a server for long.[**]
+
+   Using shorter-lived certificates with long nominal lifetimes doesn't
+   seem to buy us much.  It would let us rotate link keys more
+   frequently, but we're already getting forward secrecy from our use of
+   diffie-hellman key agreement.  Further, it would make our behavior
+   look less like regular TLS behavior, where certificates are typically
+   used for most of their nominal lifetime.  Therefore, let's store and
+   use certs and link keys for the full year.
+
+1.4. Self-signed certificates with better DNs
+
+   When we generate our own certificates, we currently set no DN fields
+   other than the commonName.  This behavior isn't terribly common:
+   users of self-signed certs usually/often set other fields too.
+   [TODO: find out frequency.]
+
+   Unfortunately, it appears that no particular other set of fields or
+   way of filling them out _is_ universal for self-signed certificates,
+   or even particularly common.  The most common schema seem to be for
+   things most censors wouldn't mind blocking, like embedded devices.
+   Even the default openssl schema, though common, doesn't appear to
+   represent a terribly large fraction of self-signed websites.  [TODO:
+   get numbers here.]
+
+   So the best we can do here is probably to reproduce the process that
+   results in self-signed certificates originally: let the bridge and relay
+   operators to pick the DN fields themselves.  This is an annoying
+   interface issue, and wants a better solution.
+
+1.5. Better commonName values
+
+   Our current certificates set the commonName to a randomly generated
+   field like www.rmf4h4h.net.  This is also a weird behavior: nearly
+   all TLS certs used for web purposes will have a hostname that
+   resolves to their IP.
+
+   The simplest way to get a plausible commonName here would be to do a
+   reverse lookup on our IP and try to find a good hostname.  It's not
+   clear whether this would actually work out in practice, or whether
+   we'd just get dynamic-IP-pool hostnames everywhere blocked when they
+   appear in certificates.
+
+   Alternatively, if we are told a hostname in our Torrc (possibly in
+   the Address field), we could try to use that.
+
+2. TLS handshake issues
+
+2.1. Session ID.
+
+   Currently we do not send an SSL session ID, as we do not support session
+   resumption.  However, Apache (and likely other major SSL servers) do have
+   this support, and do send a 32 byte SSLv3/TLSv1 session ID in their Server
+   Hello cleartext.  We should do the same to avoid an easy fingerprinting
+   opportunity.  It may be necessary to lie to OpenSSL to claim that we are
+   tracking session IDs to cause it to generate them for us.
+
+   (We should not actually support session resumption.)
+
+
+
+
+[*] "Hey buddy, it's a nice website you've got there.  Sure would be a
+    shame if somebody started poppin' up warnings on all your user's
+    browsers, tellin' everbody that you're _insecure_..."
+
+[**] Furthermore, a link-key-only compromise isn't very realistic atm;
+     nearly any attack that would let an adversary learn a link key would
+     probably let the adversary learn the identity key too.  The most
+     plausible way would probably be an implementation bug in OpenSSL or
+     something.
+