[tor-dev] Proposal 195: TLS certificate normalization for Tor 0.2.4.x

[Robert Ransom]

On 2012-03-09, Nick Mathewson <nickm at freehaven.net> 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