Re: [TLS] Proposal for detecting fraudulent certificates

Florian Weimer <> Mon, 26 September 2011 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BBBF21F8CE9 for <>; Mon, 26 Sep 2011 09:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z1v6fkCm6YBp for <>; Mon, 26 Sep 2011 09:18:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4C3E921F8CD9 for <>; Mon, 26 Sep 2011 09:18:47 -0700 (PDT)
Received: from ([]) by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1R8Dvt-0006vQ-IX; Mon, 26 Sep 2011 16:21:29 +0000
Received: by with local id 1R8Dvt-0001ts-Fq; Mon, 26 Sep 2011 16:21:29 +0000
From: Florian Weimer <>
References: <>
Date: Mon, 26 Sep 2011 16:21:29 +0000
In-Reply-To: <> (Martin Rex's message of "Mon, 26 Sep 2011 18:05:57 +0200 (MEST)")
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] Proposal for detecting fraudulent certificates
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Sep 2011 16:18:48 -0000

* Martin Rex:

> Having the client send _only_ the servers certificate and not the
> entire certificate path should IMO be sufficient for the purpose you
> outline.

I don't think it is.  The certificate itself is not proof of fraud if an
intermediate CA is involved.  More importantly, you cannot tell an
intercepting corporate proxy (whose certificate is not rooted in the
browser PKI) from a certificate which is.

> I don't know why you think the 64 KByte TLS extension size limit would
> be a problem.

The wire format allows for larger server chains (up to 16 MB).  This
could be abused to bypass detection (just use a certificate with a
logotype extension).  I just felt I had to say something about that.

> But I don't see how this extension could realistically work in a
> sane fashion.  The TLS implementation in TLS servers is not normally
> keeping a history of previous TLS Server certificates which it ever
> used (and might not have a persistence of its own for such a purpose),
> usually not even across process restarts, and having TLS backends of
> a Web-Server-Farm or hot-backups keep such a history in a consistent
> fashion is even more unlikely.

The TLS server doesn't have to keep this information.  It just has to
log it or export it over an out-of-band mechanism to the application
(similar to what's already done for client certificates).  Client hellos
are clear text, so you would see the extension on an IDS host, too.

> And end users would probably prefer their TLS clients to tell them right
> away when a server credential changes unexpectedly, rather than
> a TLS server telling them, after they come home from a several weeks
> trip through some contry YYY, that their last several week of connect(s)
> had all been MITMd...

This has UI issues which appear to unsolvable.  And even in web
browsers, not all TLS activity is user-initiated (e.g., software and
filter list updates).

Thanks for your comments.

Florian Weimer                <>
BFK edv-consulting GmbH
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99