[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

xxx-draft-spec-for-TLS-normalization.txt

To: or-dev@xxxxxxxxxxxxx
Subject: xxx-draft-spec-for-TLS-normalization.txt
From: Jacob Appelbaum <jacob@xxxxxxxxxxxxx>
Date: Mon, 24 Jan 2011 14:48:23 -0800
Delivered-to: archiver@xxxxxxxx
Delivered-to: or-dev-outgoing@xxxxxxxx
Delivered-to: or-dev@xxxxxxxx
Delivery-date: Mon, 24 Jan 2011 17:48:35 -0500
Openpgp: id=E012B42D; url=http://www.appelbaum.net/gpg.asc
Reply-to: or-dev@xxxxxxxxxxxxx
Sender: owner-or-dev@xxxxxxxxxxxxx
User-agent: mutt

I've written a draft to address both blocking and TLS certificate
related fingerprinting issues. Please see the attached text file for
submission into tor/doc/spec/proposals/idea and I'd like to request a
proposal number from nickm.

All the best,
Jake

Filename: xxx-draft-spec-for-TLS-normalization.txt
Title: Draft spec for TLS certificate and handshake normalization
Author: Jacob Appelbaum
Created: 24-Jan-2011
Status: Draft


        Draft spec for TLS certificate and handshake normalization


                                    Overview

Scope

This is a document that covers issues with current TLS  (Transport Layer
Security) related certificates generated and used by Tor. It also intends to
cover some of the possible fingerprinting issues present in the current Tor TLS
protocol setup process.

Motivation and history

Censorship is an arms race and this is a step forward in the defense of Tor.
This proposal outlines ideas that attempt to limit the ability of an attack who
wishes to fingerprint and block Tor.

Goals

This proposal intends to normalize or remove easy to predict or static values
in the Tor TLS certificates and with the Tor TLS setup process. TLS certificate
observatories should not be able to trivially detect Tor merely by receiving or
observing the certificate used or advertised by a Tor relay. Additionally I
propose that when these changes are implemented, a covert channel will be
available to signal that a server supports the third version ("V3") of the Tor
handshake protocol.

Non-Goals

This document is not intended to solve all of the possible active or passive
Tor fingerprinting problems. Beyond basic certificate examination or TLS setup
issues, we attempt to make no guarantees about resisting other kinds of
fingerprinting of Tor traffic.

                                Implementation details


Certificate Issues

The CN or commonName ASN1 field

Tor generates certificates with a commonName field that is predictable and the
field is within a given value range that is specific to Tor. Additionally, the
generated host names have other undesirable properties. The host names do not
resolve as they are generally for host names that have not and will not ever
exist in the DNS. They are also often host names that while RFC compliant, they
have almost certainly never been registered by any domain name registrar.

An example of the current commonName field: CN=www.s4ku5skci.net

An example of OpenSSLâ??s asn1parse over a typical Tor certificate:

   0:d=0  hl=4 l= 438 cons: SEQUENCE          
    4:d=1  hl=4 l= 287 cons: SEQUENCE          
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
   10:d=3  hl=2 l=   1 prim: INTEGER           :02
   13:d=2  hl=2 l=   4 prim: INTEGER           :4D3C763A
   19:d=2  hl=2 l=  13 cons: SEQUENCE          
   21:d=3  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption
   32:d=3  hl=2 l=   0 prim: NULL              
   34:d=2  hl=2 l=  35 cons: SEQUENCE          
   36:d=3  hl=2 l=  33 cons: SET               
   38:d=4  hl=2 l=  31 cons: SEQUENCE          
   40:d=5  hl=2 l=   3 prim: OBJECT            :commonName
   45:d=5  hl=2 l=  24 prim: PRINTABLESTRING   :www.vsbsvwu5b4soh4wg.net
   71:d=2  hl=2 l=  30 cons: SEQUENCE          
   73:d=3  hl=2 l=  13 prim: UTCTIME           :110123184058Z
   88:d=3  hl=2 l=  13 prim: UTCTIME           :110123204058Z
  103:d=2  hl=2 l=  28 cons: SEQUENCE          
  105:d=3  hl=2 l=  26 cons: SET               
  107:d=4  hl=2 l=  24 cons: SEQUENCE          
  109:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  114:d=5  hl=2 l=  17 prim: PRINTABLESTRING   :www.s4ku5skci.net
  133:d=2  hl=3 l= 159 cons: SEQUENCE          
  136:d=3  hl=2 l=  13 cons: SEQUENCE          
  138:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
  149:d=4  hl=2 l=   0 prim: NULL              
  151:d=3  hl=3 l= 141 prim: BIT STRING        
  295:d=1  hl=2 l=  13 cons: SEQUENCE          
  297:d=2  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption
  308:d=2  hl=2 l=   0 prim: NULL              
  310:d=1  hl=3 l= 129 prim: BIT STRING

I propose that the commonName field is generated to match a specific property
of the server in question. It is reasonable to set the commonName element to
match either the hostname of the relay, the detected IP address of the relay,
or for the relay operator to override certificate generation entirely by
loading a custom certificate. For custom certificates, see the Custom
Certificates section.

I propose that the value for the commonName field shall be populated with the
fully qualified host name as detected by reverse and forward resolution of the
IP address of the relay. If the host name is in the DNS, this host name should
be set as the common name. When forward and reverse DNS is not available, I
propose that the IP address alone is used.

The commonName field for the issuer should be set to known issuer names, random
words or left out entirely.

Some host names may trigger certain censorship keyword filters and so it may be
reasonable to provide an option to force certain values into the commonName
field.

Considerations for commonName normalization

Any host name supplied for the commonName field should resolve - even if it
does not resolve to the IP address of the relay. If the commonName field does
include an IP address, it should be the current IP address of the relay.

Certificate serial numbers

Currently our certificate serial numbers is set to the of number of seconds
since the epoch at creation time. I propose that we should ensure that our
serial numbers are un-related to the epoch. I propose that we use a randomly
generated number that is subsequently hashed with SHA-512 and truncated. The
serial number should be similar in bit width to commonly found certificate
serial numbers in the wild.

This randomly generated field may now serve as a covert channel that signals to
the client that the OR will not support TLS renegotiation; this means that the
client can expect to perform a V3 TLS handshake setup. Otherwise, if the serial
number is a reasonable time since the epoch, we should assume it expects
renegotiation.

As a security note, care must be taken to ensure that supporting this covert
channel will not lead to an attacker having a method to downgrade client
behavior.

Other certificate fields

It may be advantageous to also generate values for the O, L, ST, C, and OU
certificate fields. The C and ST fields may be populated from GeoIP information
that is already available to Tor. The other fields should contain some
semblance of a word or grouping of words.

Certificate dating and validity issues

TLS certificates found in the wild are generally found to be long lived or old
and often expired. The current Tor certificate validity time is a very small
time window starting at generation time and ending shortly thereafter as
defined by MAX_SSL_KEY_LIFETIME (2*60*60).

I propose that the certificate validity time length is extended to a period of
twelve Earth months possibly with a small random skew to be determined by the
implementer. Tor should randomly set the start date in the past or some
currently unspecified window of time before the current date.

The certificate values, such as expiration, should not be used for anything
relating to security.

The expiration time should not be a fixed time that is simple to calculate by
any Deep Packet Inspection device or it will become a new Tor TLS setup
fingerprint.

Custom Certificates

It should be possible for a Tor relay operator to use a specifically supplied
certificate and secret key. This will allow a relay or bridge operator to use a
certificate signed by a member of the certificate authority racket; it will
also allow for any other user supplied certificate. This may be desirable in
some kinds of filtered networks or when attempting to blend in with the TLS web
server certificate crowd.

Problematic Diffieâ??Hellman parameters

We currently send a static Diffieâ??Hellman parameter, prime p (or â??prime p
outlawâ??) as specified in RFC2409 as part of the TLS Server Hello response.
While amusing to have the power to make specific prime numbers into a new class
of numbers (cf. imaginary, irrational, illegal) - our new friend prime p outlaw
is not required.

I propose that the function to initialize and generate DH parameters is split
into two functions.

First, init_dh_param() should be used only for OR to OR DH setup and
communication. Secondly, it it proposed that we create a new function
init_tls_dh_param() that will have a two stage development process.

The first stage init_tls_dh_param() will use the same prime that Apache2.x [0]
sends (or â??dh1024_apache_pâ??) and this change should be made immediately. This
is a known good and safe prime number that is currently not known to be
blocked.

The second stage init_tls_dh_param() should randomly generate a new hard to
outlaw or filter prime p (â??evasive prime pâ??) on a regular basis; this should be
added to the 0.2.3.x branch of Tor. This prime can be generated at setup or
execution time and probably does not need to be stored on disk. Evasive prime p
only needs to be generated by Tor relays as Tor clients will never send it. It
should absolutely not be shared between different Tor relays nor should it ever
be static after the 0.2.3.x release.

As a security precaution, care must be taken to ensure that we do not generate
weak primes or known filtered primes. Both weak and filtered primes will
undermine the TLS connection security properties. OpenSSH solves this issue
dynamically in RFC 4419 [1] and may provide a solution that works reasonably
well for Tor. More research in this area including Millerâ??Rabin primality tests
will need to be analyzed and probably added to Tor.

Practical key size

Currently we use 1024 bit RSA keys. I propose that we increase the RSA key size
to 1280 or to 2048 as an additional covert channel to signal support for the V3
handshake setup. 2048 is likely a more common certificate size and also
provides a reasonable security boost with regard to key security properties.

The implementer should choose a key size that is common and meaningfully above
1024 bits.

Possible future filtering nightmares

At some point it may cost effective or politically feasible for a network
filter to simply block all signed or unsigned certificates without a known
valid CA trust chain. This will break many applications on the internet and
hopefully, our option for custom certificates will ensure that this step is
simply avoided by the censors.  Appendix: Other issues


What other obvious TLS certificate issues exist? What other static values are
present in the Tor TLS setup?

[0] httpd-2.2.17/modules/ss/ssl_engine_dh.c
[1] http://tools.ietf.org/html/rfc4419

Prev by Author: Re: Publishing sanitized bridge pool assignments
Next by Author: xxx-draft-spec-for-TLS-normalization.txt
Previous by thread: Re: Thoughts on https://trac.torproject.org/projects/tor/wiki/dev/SupportPolicy
Next by thread: xxx-draft-spec-for-TLS-normalization.txt
Index(es):
- Author
- Thread