From 28a78381e4cee7d9fe20415d5c2d1391510a87f8 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 6 Mar 2012 18:04:04 -0500 Subject: Draft-status proposal 195: normalize TLS in 0.2.4 --- proposals/195-TLS-normalization-for-024.txt | 170 ++++++++++++++++++++++++++++ 1 file changed, 170 insertions(+) create mode 100644 proposals/195-TLS-normalization-for-024.txt (limited to 'proposals/195-TLS-normalization-for-024.txt') 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. + -- cgit v1.2.3-54-g00ecf