Re: [TLS] Verifying X.509 Certificate Chains out of order
Nelson B Bolyard <nelson@bolyard.me> Sat, 11 October 2008 21:40 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 B3E273A68CE; Sat, 11 Oct 2008 14:40:09 -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 AFABC3A68CE for <tls@core3.amsl.com>; Sat, 11 Oct 2008 14:40:08 -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 aiKVzjeBFycg for <tls@core3.amsl.com>; Sat, 11 Oct 2008 14:40:07 -0700 (PDT)
Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id 882233A690D for <tls@ietf.org>; Sat, 11 Oct 2008 14:40:06 -0700 (PDT)
Received: (qmail 6772 invoked from network); 11 Oct 2008 21:40:55 -0000
Received: from unknown (64.202.165.47) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 11 Oct 2008 21:40:55 -0000
Message-ID: <48F11D66.6040900@bolyard.me>
Date: Sat, 11 Oct 2008 14:40:54 -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: IETF TLS Working Group <tls@ietf.org>
References: <E1KnXuC-00044h-Qp@wintermute01.cs.auckland.ac.nz>
In-Reply-To: <E1KnXuC-00044h-Qp@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-08 05:12 PDT: > Martin Rex <Martin.Rex@sap.com> writes: > >> But I really dislike the idea of expecting an empty DName (i.e. one >> that contains no RDName elements in the ASN.1 SEQUENCE) should have the >> same meaning as _NO_ DName at all! Are you sure that this notion is >> interoperable with other implementations? > > Because TLS client certs are so rarely used it's hard to say, the best I > can say is "I haven't run into problems so far", but that doesn't mean > much given the very small sample size. Since I work on TLS for Mozilla products, I can offer some perspective on the issue of the frequency or rarity of client authentication requests. Mozilla's products (browsers and email MUAs) have always implemented client cert authentication. They offer the users a choice of what to do when a server requests client certs, and the choices include: - Automatic selection. The product selects a cert automatically based on issuer name matching the server's list of CA names, (empty list of CA names treated like a wildcard). Basically, the first cert with matching issuer name and appropriate KU and EKU is used. If the user has no cert from an appropriate issuer, send no_certificate response. This is all silent (no user interaction) unless the user's private key requires authentication for every use. - manual selection. If the user has any cert(s) whose issuer matches the server's list of CA names, with appropriate KU and EKU, the product presents the user with a list of such certs, and lets the user choose one. An empty list of CA names from the server is treated like a wildcard. Certs with no EKU extension are presumed to be valid for all EKUs. Even if the user has only one cert that matches, he is prompted to choose. He can also choose not to send any cert, but to send a no_certificate response. If the user has NO certs that match, then the user is not presented with any list, and a no_certificate response is silently sent. (Pre-configured per-server selection of client cert (including "none") is in development.) Until recently, the default for both browsers and MUAs was automatic selection. But this was recently changed in both types of clients, for separate reasons. For browsers, there arose a concern that automatic and silent client cert authentication allows a web site to request cert authentication even when the user has no business relationship with the site, and could be used for user tracking, defeating anonymity of browsing. So the default setting in browsers was changed to manual selection to avoid silent user tracking. This change caused a LOT of users to begin to have a very different user experience with their browsers and MUAs. Requests for client certs were apparently MUCH more common and wide spread than we had previously known. Users who had their own certs for email purposes, certs whose KU and EKU also permitted them to be used for TLS client authentication, suddenly found themselves being inundated with requests to select a cert for client authentication. For MUAs, the reason for making manual selection the default was different. A number of popular free email server products that offer SMTP and IMAP (or POP) over TLS have recently begun to exhibit the following behaviors: - No TLS session cache. A full handshake is done on every connection. - Client certs are requested in EVERY handshake. - The list of CA names in the server's cert request is empty, with no way for the server admin to change that. - 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. MUA users who possessed their own email certs found themselves unable to successfully connect to their mail servers because their MUAs would automatically send their email cert to the server for client authentication, and the server then dropped the connection. The immediate workaround for them was to configure their MUA for manual selection of certs for TLS client authentication, and then choose to send a no-certificate response when prompted. However, this was not entirely satisfactory because they found themselves having to manually choose to send no certificate on EVERY connection. For IMAPS users, this meant encountering the cert selection dialog every time they change to view a different IMAP folder. It also meant encountering the dialog on every message sent. The MTA administrators are generally unaware of client authentication. They are unaware that they have the ability to associate a certificate with each user account, thereby allowing the cert to be used in lieu of name and password Identification and authentication. They have no way to change the behavior of their MTA server product. Therefore, they perceive the unfortunate MUA user experience to be an MUA bug, not an MTA server bug. ANY of the following changes would mitigate these problems: - servers implementing TLS session caches, and then not performing FULL handshakes on every connection. - servers sending non-empty lists of CA names. - CAs issuing email certs with EKU extensions that disallow use for client authentication. However, this dual use is considered a feature by CAs. In trying to persuade MTA administrators to enable TLS session caching in their servers, we found that there is widespread misunderstanding and fear that TLS session caching somehow allows clients to have access to accounts on servers without having authenticated to the servers. They seem to believe that with a TLS server session cache enabled, any client can reuse a previously cached TLS session without authentication. They are fearful to the session caches, and see the session caches as part of the problem, not as part of the solution. Believing that these problems will not be quickly solved, Mozilla is working on implementing the ability for the client to remember the association of a user-chosen cert with a server, so that it can repeat that choice thereafter without bothering the user again. However, this will certainly mask the issues of servers not reusing TLS sessions. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [TLS] Verifying X.509 Certificate Chains out of o… Simon Josefsson
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Rob Dugal
- Re: [TLS] Verifying X.509 Certificate Chains out … Dr Stephen Henson
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Eric Rescorla
- Re: [TLS] Verifying X.509 Certificate Chains out … Steven M. Bellovin
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Mike
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Stefan Santesson
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Axel.Heider
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Alexander Klink
- Re: [TLS] Verifying X.509 Certificate Chains out … Eric Rescorla
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Sylvester
- Re: [TLS] Verifying X.509 Certificate Chains out … Eric Rescorla
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Sylvester
- Re: [TLS] Verifying X.509 Certificate Chains out … Stefan Santesson
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Stefan Santesson
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Steven M. Bellovin
- [TLS] Antwort: Re: Verifying X.509 Certificate Ch… Axel.Heider
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Nelson B Bolyard
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Ben Laurie
- Re: [TLS] Verifying X.509 Certificate Chains out … Ben Laurie
- Re: [TLS] Verifying X.509 Certificate Chains out … Jeffrey A. Williams
- Re: [TLS] Verifying X.509 Certificate Chains out … Martin Rex
- Re: [TLS] Verifying X.509 Certificate Chains out … Nelson B Bolyard
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Nelson B Bolyard
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Simon Josefsson
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Yoav Nir
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Nelson B Bolyard
- Re: [TLS] Verifying X.509 Certificate Chains out … Peter Gutmann
- Re: [TLS] Verifying X.509 Certificate Chains out … Alexander Klink