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

[Ondrej Mikle]

The proposal seems quite thought through. Some comments inline:

On 03/09/2012 06:02 PM, Nick Mathewson wrote:
> 
> 
> 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.

I'd go for 2048 bits minimum (CAB forum is moving towards this value soon and
other sources [1] suggest it for long-lived certs as well).

> 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.]

Here are two quick statistics I did on my DB (1.5M+ unique certs), columns are
"count, hour, minute, second":

not_before: http://pastie.org/3564679
not_after: http://pastie.org/3564694

Statitic on validity period:

http://pastie.org/3564701

> 
>    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.

Note that there are many embedded devices that generate certs periodically
(every day, every few days; I wonder if it's because somebody thought about the
"shared prime due to low entropy fiasco" before and wanted to avoid it without
HW RNG.)

I'd suggest we use some similar approach.

>    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.

Agreed, good point.

> 
> 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.]

One statistic here (EFF's SSL Observatory is more thorough than my DB in
self-signed certs, I'll post a statistic from it later):

http://pastie.org/3564743

But in general thousands of embedded devices share Issuer and Subject RDNs.

>    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.

There are many embedded devices we could fake (I could put together a list).
Just for fun, we could use 'BlueCoat Series' :-)

My suggestion is that we put a list in Tor so that Tor node picks a
issuer/subject randomly unless operator overrides it (but node needs to stick to
one CN then, at least for a longer period of time - days/weeks).

> 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.

Using reverse IP can be useful if both reverse and forward DNS records match.
Though there are tons of misconfigurations in the wild (either due to not
needing proper configuration or simple mistake).


[1] http://www.keylength.com/en/3/ (or
http://www.ecrypt.eu.org/documents/D.SPA.17.pdf in case someone is interested in
full report)

Ondrej