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

Stefan Santesson <stefans@microsoft.com> Tue, 07 October 2008 17:00 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90F23A6B5E; Tue, 7 Oct 2008 10:00:39 -0700 (PDT)
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 3B7D43A6B52 for <tls@core3.amsl.com>; Tue, 7 Oct 2008 10:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.06
X-Spam-Level:
X-Spam-Status: No, score=-10.06 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, WHOIS_DMNBYPROXY=0.478]
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 qUHlf+jdGFgA for <tls@core3.amsl.com>; Tue, 7 Oct 2008 10:00:37 -0700 (PDT)
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by core3.amsl.com (Postfix) with ESMTP id AF1193A6B4C for <tls@ietf.org>; Tue, 7 Oct 2008 10:00:36 -0700 (PDT)
Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 7 Oct 2008 18:01:14 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.73]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Tue, 7 Oct 2008 18:01:14 +0100
From: Stefan Santesson <stefans@microsoft.com>
To: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Date: Tue, 7 Oct 2008 18:01:12 +0100
Thread-Topic: [TLS] Verifying X.509 Certificate Chains out of order
Thread-Index: AcknkNv1Cf2kbbZxS+ymoSeK/fzxrgBDOuuQ
Message-ID: <9F11911AED01D24BAA1C2355723C3D3218DDA55CF6@EA-EXMSG-C332.europe.corp.microsoft.com>
References: <1223034323.30303.29.camel@localhost> <877i8pk772.fsf@mocca.josefsson.org> <1223281251.12502.74.camel@localhost> <87abdit8c2.fsf_-_@mocca.josefsson.org>
In-Reply-To: <87abdit8c2.fsf_-_@mocca.josefsson.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
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-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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

On the original question:

> It is claimed that OpenSSL, IE and Firefox does not enforce the second
> MUST in the paragraph above, and succeeds in verifying an
> out-of-sequence chain.  I haven't verified the claim.

A Microsoft based SSL server will insert the certificates in order. A Microsoft based SSL client doesn't require the certificates to be in order. The client simply passes these certificates to the CertGetCertificateChain API in the hAdditionalStore parameter. This will validate the subject certificate regardless of order.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Simon Josefsson
> Sent: den 6 oktober 2008 10:51
> To: tls@ietf.org
> Subject: [TLS] Verifying X.509 Certificate Chains out of order
>
> All,
>
> We've received a request to verify X.509 certificate chains out of
> order
> in GnuTLS.  Doing that would violate the following in RFC 5246 (earlier
> versions had similar language), ยง7.4.2:
>
>    certificate_list
>       This is a sequence (chain) of certificates.  The sender's
>       certificate MUST come first in the list.  Each following
>       certificate MUST directly certify the one preceding it.  Because
>       certificate validation requires that root keys be distributed
>       independently, the self-signed certificate that specifies the
> root
>       certificate authority MAY be omitted from the chain, under the
>       assumption that the remote end must already possess it in order
> to
>       validate it in any case.
>
> It is claimed that OpenSSL, IE and Firefox does not enforce the second
> MUST in the paragraph above, and succeeds in verifying an
> out-of-sequence chain.  I haven't verified the claim.  It appears as if
> the OpenSSL developers don't consider their behaviour as a bug (see
> reply below).
>
> For more details, including the particular certificate chain in this
> example, see:
>
> http://thread.gmane.org/gmane.network.gnutls.general/1383/focus=1384
>
> I can see several reasons to enforce the MUST recommendation here, e.g.,
> covert channels, DoS-considerations, unneeded complexity.
>
> What are others opinion on this?  I'm looking for some guidance on
> whether we should modify our current behaviour.
>
> /Simon
>
> Peter Volkov <pva@gentoo.org>; writes:
>
> > Is it possible to do something similar in gnutls? It looks like there
> > are reasons to validate certificate with wrong order...
> >
> > -------- Forwarded message --------
> > From: Tim Hudson <tjh AT cryptsoft  com>
> > Reply-TO: openssl-dev@openssl.org
> > TO: openssl-dev@openssl.org
> >
> > Peter Volkov wrote:
> >> CC'ing openssl developers for their opinions, since I think this
> >> behavior better to have consistent or configurable. Description of
> the
> >> problem is here:
> >
> > Placing this in context - connect with internet explorer or firefox
> to
> > https://metasploit.com/ and you will see that both of those
> independent
> > implementations see nothing wrong with the certificate chain and
> handle the
> > redirect to http://metasploit.com/ without and errors or warnings.
> >
> > Implementations typically take the list of certificates as untrusted
> > certificates to add into the process of walking the certificate chain
> to a
> > trusted root certificate. There are pragmatic reasons for doing it
> this way.
> >
> >  From an interoperability point of view remember the adage - "Be
> strict in what
> > you generate, be liberal in what you accept"
> >
> > Tim.
> >
> ______________________________________________________________________
> >
> >
> > --
> > Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls