Re: [TLS] Proposal for detecting fraudulent certificates

Florian Weimer <> Sat, 01 October 2011 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2361E21F8E0F for <>; Sat, 1 Oct 2011 09:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.929
X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J2KuxW-7yFeP for <>; Sat, 1 Oct 2011 09:13:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 65A8F21F8E10 for <>; Sat, 1 Oct 2011 09:13:56 -0700 (PDT)
Received: from ([]) by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RA2F7-0004hf-9q; Sat, 01 Oct 2011 16:16:49 +0000
Received: by with local id 1RA2F7-0001W0-6a; Sat, 01 Oct 2011 16:16:49 +0000
From: Florian Weimer <>
References: <>
Date: Sat, 01 Oct 2011 16:16:49 +0000
In-Reply-To: <> (Martin Rex's message of "Mon, 26 Sep 2011 18:42:17 +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: Sat, 01 Oct 2011 16:13:57 -0000

* Martin Rex:

> Florian Weimer wrote:
>> * 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.
> The Web Server certificate nails down the public&private key for the
> server.  If a MITM has access to the servers private key, then
> you've lost already, because that MITM can perform a perfect
> impersonation for the client (the only thing that the MITM could
> not do is a client-certificate authentication to the real server
> (unless the real server lacks rfc5746 renegotiation protection).

Let me rephrase.  I'm concerned that without the full chain, server
operators dealing with larger user bases will drown in reports of wrong
server certificates, some of them created by Fiddler, some of them by
HTTPS-aware AV-scanning web proxies.  I'm not sure if these cases are
interesting.  The full chain, on the other hand, provides a cryptographi
proof how the server certificate is rooted in the browser PKI.  If it is
properly rooted, but is not yours, you definitely have got a problem.

>> > 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.
> The client could decide to not talk to such TLS servers at all
> (while theoretically not "standards compliant", it is what a
>  non-marginal fraction of the installed base is doing...)

I considered that.  But I don't think we need any more of that.

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