Re: [TLS] Verifying X.509 Certificate Chains out of order

Alexander Klink <> Tue, 21 October 2008 15:26 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 285503A6879; Tue, 21 Oct 2008 08:26:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FC223A6834 for <>; Tue, 21 Oct 2008 08:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5eNlXtjK5KtI for <>; Tue, 21 Oct 2008 08:26:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6F1C73A6879 for <>; Tue, 21 Oct 2008 08:26:40 -0700 (PDT)
Received: from (cy10loc []) by (Postfix) with ESMTP id E412A6C3A4; Tue, 21 Oct 2008 17:27:51 +0200 (CEST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 7FC5EC8001; Tue, 21 Oct 2008 17:27:51 +0200 (CEST)
Date: Tue, 21 Oct 2008 17:27:50 +0200
From: Alexander Klink <>
To: Peter Gutmann <>,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/1.5.13 (2006-08-11)
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0372434872=="

On Wed, Oct 22, 2008 at 03:56:59AM +1300, Peter Gutmann wrote:
> >One major difference between tracking with cookies (or TLS session IDs) and
> >using certs is that cookies and TLS session IDs contain only information
> >previously put there by the server itself.  When the server fetches them, it
> >doesn't learn anything about the user that it didn't already know. It has
> >merely learned that a user who has previously been to this web site has now
> >returned.  But certs reveal information that could well have previously been
> >unknown to the server.  Fetching certs is a way to do information discovery.
> I'm sure this can be argued endlessly, but given a mechanism that has 100%
> coverage/penetration (cookies/Flash cookies/cache cookies/Javascript/whatever)
> and one that has a coverage level two orders of magnitude below the margin of
> error, I know which one I'd be using to track users, regardless of some
> theoretical advantage that one might have.

The practical advantage here was that the coverage level did not matter
- if you wanted to track users across two unrelated domains, you could
do so using TLS client certificates no matter if the users actually had
them (they were (nearly) unnoticeable to install) ...

> >The subsequent discovery of lots of sites that are doing this seems to prove
> >that the threat was not merely imaginary.
> That doesn't say anything about the threat, merely that there are lots of
> misconfigured servers.  The fact that the server admins had no idea their

I'd agree with that, I doubt that someone was actually using that as an
attack vector ...

Dipl.-Math. Alexander Klink | IT-Security Engineer |
 mobile: +49 (0)178 2121703 |          Cynops GmbH |
      HRB 7833, Amtsgericht | USt-Id: DE 213094986 |     Geschäftsführer:
     Bad Homburg v. d. Höhe |                      |      Martin Bartosch
TLS mailing list