On 2012-03-09, Nick Mathewson <[email protected]> wrote: > 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.)
Users need to specify a full certificate chain, not just the end-entity certificate. Have you considered whether to allow the user to store the TLS certificate's private key in a hardware device? > > 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. What if a bridge's IP address and reverse-DNS hostname change? How does this interact with the v3 link protocol signaling mechanism? How will a bridge's client be told what hostname to specify in its server name indication field? Robert Ransom _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
