IETF Logo Mail Archive

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

Nelson B Bolyard <nelson@bolyard.me> Tue, 14 October 2008 00:55 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 A24F73A6A5C; Mon, 13 Oct 2008 17:55:40 -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 7E5983A6A5C for <tls@core3.amsl.com>; Mon, 13 Oct 2008 17:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 j3BKcwwaSZsG for <tls@core3.amsl.com>; Mon, 13 Oct 2008 17:55:28 -0700 (PDT)
Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id C6C0F3A6A17 for <tls@ietf.org>; Mon, 13 Oct 2008 17:55:28 -0700 (PDT)
Received: (qmail 630 invoked from network); 14 Oct 2008 00:56:22 -0000
Received: from unknown (64.202.165.36) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 14 Oct 2008 00:56:22 -0000
Message-ID: <48F3EE34.3050402@bolyard.me>
Date: Mon, 13 Oct 2008 17:56:20 -0700
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20080930003201 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: tls@ietf.org
References: <E1Kov1Q-00046w-Bx@wintermute01.cs.auckland.ac.nz>
In-Reply-To: <E1Kov1Q-00046w-Bx@wintermute01.cs.auckland.ac.nz>
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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Peter Gutmann wrote, On 2008-10-12 00:05:
> Nelson B Bolyard <nelson@bolyard.me> writes:

>> - Client certs are requested in EVERY handshake.
>> [...]
>> - If the server receives a client certificate that it does not recognize
>>  as being authorized to authenticate any user, instead of ignoring the
>>  cert, and going on to request authentication using one of the other
>>  methods (e.g. user name and password), it drops the connection, usually
>>  without sending any alert.
> 
> Hmm, that's new, the behaviour I saw was that the servers always asked for
> certs but when sent a no-cert response they continued as normal.  What you're
> seeing could just be a variant of the same broken behaviour, only now the
> server does a bit more checking and fails on the cert it doesn't know it's
> asked for rather than just ignoring it.

I think we've been seeing the behaviors of the same product.
As you say, if you send a no-certificate response, the server continues
in the "normal" (no client auth) fashion.  But if you DO provide a client
cert, then the server drops the connection.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email