[tor-commits] [torspec/master] Draft-status proposal 195: normalize TLS in 0.2.4
nickm at torproject.org
nickm at torproject.org
Fri Mar 9 17:01:47 UTC 2012
commit 28a78381e4cee7d9fe20415d5c2d1391510a87f8
Author: Nick Mathewson <nickm at torproject.org>
Date: Tue Mar 6 18:04:04 2012 -0500
Draft-status proposal 195: normalize TLS in 0.2.4
---
proposals/000-index.txt | 6 +-
.../179-TLS-cert-and-parameter-normalization.txt | 27 +++-
proposals/195-TLS-normalization-for-024.txt | 170 ++++++++++++++++++++
3 files changed, 200 insertions(+), 3 deletions(-)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 95dd4d4..fc5c508 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -99,7 +99,7 @@ Proposals by number:
176 Proposed version-3 link handshake for Tor [CLOSED]
177 Abstaining from votes on individual flags [OPEN]
178 Require majority of authorities to vote for consensus parameters [CLOSED]
-179 TLS certificate and parameter normalization [DRAFT]
+179 TLS certificate and parameter normalization [CLOSED]
180 Pluggable transports for circumvention [OPEN]
181 Optimistic Data for Tor: Client Side [CLOSED]
182 Credit Bucket [DRAFT]
@@ -115,6 +115,7 @@ Proposals by number:
192 Automatically retrieve and store information about bridges [OPEN]
193 Safe cookie authentication for Tor controllers [OPEN]
194 Mnemonic .onion URLs [OPEN]
+195 TLS certificate normalization for Tor 0.2.4.x [DRAFT]
Proposals by status:
@@ -126,9 +127,9 @@ Proposals by status:
141 Download server descriptors on demand
144 Increase the diversity of circuits by detecting nodes belonging the same provider
175 Automatically promoting Tor clients to nodes
- 179 TLS certificate and parameter normalization [for 0.2.3.x]
182 Credit Bucket
186 Multiple addresses for one OR or bridge
+ 195 TLS certificate normalization for Tor 0.2.4.x [for 0.2.4.x]
NEEDS-REVISION:
131 Help users to verify they are using Tor
190 Bridge Client Authorization Based on a Shared Secret
@@ -205,6 +206,7 @@ Proposals by status:
174 Optimistic Data for Tor: Server Side [in 0.2.3.1-alpha]
176 Proposed version-3 link handshake for Tor [for 0.2.3]
178 Require majority of authorities to vote for consensus parameters [in 0.2.3.9-alpha]
+ 179 TLS certificate and parameter normalization [for 0.2.3.x]
181 Optimistic Data for Tor: Client Side [in 0.2.3.3-alpha]
183 Refill Intervals [in 0.2.3.5-alpha]
184 Miscellaneous changes for a v3 Tor link protocol [for 0.2.3.x]
diff --git a/proposals/179-TLS-cert-and-parameter-normalization.txt b/proposals/179-TLS-cert-and-parameter-normalization.txt
index 7ad3ed8..4272d4f 100644
--- a/proposals/179-TLS-cert-and-parameter-normalization.txt
+++ b/proposals/179-TLS-cert-and-parameter-normalization.txt
@@ -2,7 +2,7 @@ Filename: 179-TLS-cert-and-parameter-normalization.txt
Title: TLS certificate and parameter normalization
Author: Jacob Appelbaum, Gladys Shufflebottom
Created: 16-Feb-2011
-Status: Draft
+Status: Closed
Target: 0.2.3.x
@@ -11,6 +11,12 @@ Target: 0.2.3.x
Overview
+ STATUS NOTE:
+
+ This document is implemented in part in 0.2.3.x, deferred in part, and
+ rejected in part. See indented bracketed comments in individual
+ sections below for more information. -NM
+
Scope
This is a document that proposes improvements to problems with Tor's
@@ -135,6 +141,11 @@ covert channel will not lead to an attacker having a method to downgrade client
behavior. This shouldn't be a risk because the TLS Finished message hashes over
all the bytes of the handshake, including the certificates.
+ [Randomized serial numbers are implemented in 0.2.3.9-alpha. We probably
+ shouldn't do certificate tagging by a covert channel in serial numbers,
+ since doing so would mean we could never have an externally signed
+ cert. -NM]
+
Certificate fingerprinting issues expressed as base64 encoding
It appears that all deployed Tor certificates have the following strings in
@@ -209,6 +220,8 @@ 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.
+ [Deferred and needs revision; see proposal XXX. -NM]
+
Proposed certificate form
The following output from openssl asn1parse results from the proposed
@@ -260,6 +273,10 @@ default self-signed certificate:
383:d=2 hl=2 l= 0 prim: NULL
385:d=1 hl=3 l= 129 prim: BIT STRING
+ [Rejected pending more evidence; this pattern is trivially detectable,
+ and there is just not enough reason at the moment to think that this
+ particular certificate pattern is common enough for sites that matter
+ that the censors wouldn't be willing to block it. -NM]
Custom Certificates
@@ -271,6 +288,8 @@ This may be desirable in some kinds of filtered networks or when attempting to
avoid attracting suspicion by blending in with the TLS web server certificate
crowd.
+ [Deferred; see proposal XXX]
+
Problematic Diffie–Hellman parameters
We currently send a static Diffie–Hellman parameter, prime p (or “prime p
@@ -317,6 +336,8 @@ well for Tor. More research in this area including the applicability of
Miller-Rabin or AKS primality tests[6] will need to be analyzed and probably
added to Tor.
+ [Randomized DH groups are implemented in 0.2.3.9-alpha. -NM]
+
Practical key size
Currently we use a 1024 bit long RSA modulus. I propose that we increase the
@@ -327,6 +348,10 @@ with regard to key security properties.
The implementer should increase the 1024 bit RSA modulus to 2048 bits.
+ [Deferred and needs performance analysis. See proposal
+ XXX. Additionally, DH group strength seems far more crucial. Still, this
+ is out-of-scope for a "normalization" question. -NM]
+
Possible future filtering nightmares
At some point it may cost effective or politically feasible for a network
diff --git a/proposals/195-TLS-normalization-for-024.txt b/proposals/195-TLS-normalization-for-024.txt
new file mode 100644
index 0000000..37ee546
--- /dev/null
+++ b/proposals/195-TLS-normalization-for-024.txt
@@ -0,0 +1,170 @@
+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.)
+
+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.
+
+ Alternatively, if we are told a hostname in our Torrc (possibly in
+ the Address field), we could try to use that.
+
+2. TLS handshake issues
+
+2.1. Session ID.
+
+ Currently we do not send an SSL session ID, as we do not support session
+ resumption. However, Apache (and likely other major SSL servers) do have
+ this support, and do send a 32 byte SSLv3/TLSv1 session ID in their Server
+ Hello cleartext. We should do the same to avoid an easy fingerprinting
+ opportunity. It may be necessary to lie to OpenSSL to claim that we are
+ tracking session IDs to cause it to generate them for us.
+
+ (We should not actually support session resumption.)
+
+
+
+
+[*] "Hey buddy, it's a nice website you've got there. Sure would be a
+ shame if somebody started poppin' up warnings on all your user's
+ browsers, tellin' everbody that you're _insecure_..."
+
+[**] Furthermore, a link-key-only compromise isn't very realistic atm;
+ nearly any attack that would let an adversary learn a link key would
+ probably let the adversary learn the identity key too. The most
+ plausible way would probably be an implementation bug in OpenSSL or
+ something.
+
More information about the tor-commits
mailing list