Re: [TLS] Root certificates in server certificate chains

Marsh Ray <marsh@extendedsubset.com> Wed, 01 September 2010 01:56 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993A13A69FB for <tls@core3.amsl.com>; Tue, 31 Aug 2010 18:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-cuny+3klJI for <tls@core3.amsl.com>; Tue, 31 Aug 2010 18:56:25 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 6A4183A69FA for <tls@ietf.org>; Tue, 31 Aug 2010 18:56:25 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OqcZL-0002qo-HL; Wed, 01 Sep 2010 01:56:55 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CE30B6092; Wed, 1 Sep 2010 01:56:53 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18kkZjSRE36tkm8AtYndrc6JWeuJ/fmbLI=
Message-ID: <4C7DB2E5.6030307@extendedsubset.com>
Date: Tue, 31 Aug 2010 20:56:53 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6
MIME-Version: 1.0
To: Matt McCutchen <matt@mattmccutchen.net>
References: <90e6ba1818805af088048f262265@google.com> <1283299784.1923.145.camel@mattlaptop2.local>
In-Reply-To: <1283299784.1923.145.camel@mattlaptop2.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: 1.41421@gmail.com, tls@ietf.org
Subject: Re: [TLS] Root certificates in server certificate chains
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Sep 2010 01:56:29 -0000

On 08/31/2010 07:09 PM, Matt McCutchen wrote:
> The following is my understanding.  Others should feel free to disagree
> or correct me.
>
> On Tue, 2010-08-31 at 22:30 +0000, 1.41421@gmail.com wrote:
>> The standard (RFC 5246, sec. 7.4.2) says that a server certificate
>> chain may include, as the last entry in this chain, the root
>> certificate that is to be considered the ultimate trust anchor as far
>> the server certificate is concerned. What would prevent an attacker
>> from inserting a Certificate message of its own during the handshake,
>> containing a totally bogus root certificate?
>
> Like any other tampering with the handshake, this would cause the
> Finished check to fail.

Not if the attacker is successful in getting the client to accept his 
proposed root certificate.

>> Actually, doesn't this render the whole idea of authentication of the
>> remote useless?

Sure, if the client is willing to accept it.

>> How can one make sure that a root certificate received
>> in a certificate chain is genuine?

Perhaps the client already trusts that root cert or key? If so, why even 
bother to send it?

>> But, in this case, why allow the server to include a root certificate
>> in the certificate chain in the first place?
>
> Perhaps as a hint to clients that might decide they wish to add that
> certificate as a trust anchor, possibly after further research?

To make it easier for users to "Permanently store this exception"?  :-P

- Marsh