[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Proposal 195: TLS certificate normalization for Tor 0.2.4.x
On 2012-03-09, Nick Mathewson <nickm@xxxxxxxxxxxxx> 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
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev