Re: [TLS] HTTPS client-certificate-authentication in browsers
Martin Rex <mrex@sap.com> Tue, 26 July 2011 19:11 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109865E8002 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 12:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.556
X-Spam-Level:
X-Spam-Status: No, score=-9.556 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP8pUlhorXKu for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 12:11:10 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6084D5E8001 for <tls@ietf.org>; Tue, 26 Jul 2011 12:11:06 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6QJB40R022729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jul 2011 21:11:04 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107261911.p6QJB3Dv011457@fs4113.wdf.sap.corp>
To: anders.rundgren@telia.com
Date: Tue, 26 Jul 2011 21:11:03 +0200
In-Reply-To: <4E2E3F7E.30506@telia.com> from "Anders Rundgren" at Jul 26, 11 06:15:58 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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/options/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: Tue, 26 Jul 2011 19:11:12 -0000
Anders Rundgren wrote: > > On 2011-07-26 01:51, Martin Rex wrote: > > > > Anders Rundgren wrote: > > > > > > I don't believe that TLS CCA (Client Certificate Authentication) in the > > > form of HTTPS as implemented in current browsers has much of a future. > > > > It works perfectly fine and we've been using it >10 years for > > all of our intranet (50.000 employees these days) web servers > > accessed via HTTPS, using TLS client certs for Single Sign-On. > > (similar to how Kerberos is used by others). > > I'm sure about that. My perspective are consumers. My perspective is also consumers. TLS client authentication is about Single Sign-On. http://en.wikipedia.org/wiki/Single_sign-on And the most convenient incarnation of it is popup-free single sign-on. > > > > > What you're looking at here is scenarios for individually authenticated > > transactions. That is an entirely different problem domain and not > > addressed by TLS at all. You would have to address that with > > a browser plugin that accesses a completely different PKI credential > > that has signature qualities, with a clearly defined protocol that > > describes what data gets signed, and which requires seperate per-transaction > > authorization for every signature operation. > > There was even a Danish e-government standard for PKI authentication > that rides on top of server-auth-only HTTPS. They also have a > companion scheme doing web signatures which indeed uses another > key. There are lots of similar systems out there. > > Are all these guys morons? I believe they are rather dissatisfied > with how HTTPS CCA works. So am I. Not understanding the underlying technology at all and not discussing with software suppliers how a standardized but hardly used protocol option works is more than a little naive on my scorecard. Microsoft foobar'ed client certs in WinHTTP (a component distinct from MSIE) and fixed it here http://support.microsoft.com/kb/909425 when we asked them to. When Apple shipped Safari for Windows they did not find that winhttp fix and made their browser exhibit the exact same bugs. We told them in January 2009, but they were still shipping defective Safaris for Windows in April 2010... Google Chrome used WinHTTP only for a short time and got rid of the problem when it dumped WinHTTP. > > > > > If the server wants to perform a logout operation, > > it can delete the TLS session cache entry on the server. > > > > But the Single Sign-On capability of the TLS client cert means > > that as long as the client credential is still available to the > > TLS client, the client will perform "transparent" reauthentication. > > Doesn't this actually lead to what I'm saying from a practical > point of view? No. It doesn't make any flawed assumptions less flawed, of course. > > What you can do at the TLS layer is BTW very little > at least if you are using Servlets. For other authentication > methods logout (HttpSession.invalidate) works as expected. You misunderstand the concept of "Single Sign-On" as offered by TLS. > > >> The button "Clear SSL state" in MSIE is an indication how horribly bad it > >> can go when security experts design systems for "people". > > > > Is your intention to get prompted again? > >>From a usability standpoint, we prefer the "select automatically" > > setting and spare our users the client certificate selection popup. > > I don't really want to know what it does actually. The mere existence > of such a button signals that something is terribly wrong :-) The equivalent for Kerberos (win7 in a windows domain) is "klist purge". (Although the Kerberos ticket purge does _NOT_ result in the prompting when new TGTs and new tickets are acquired. > > >> There's no way you can hide the fact that TLS CCA is only truly useful > >> securing tunnels between "boxes". > > > > The purpose of the TLS CCA is the same as the purpose of Kerberos, > > to provide a non-disclosing Single Sign-On convenience. > > But Kerberos is built on using a ticket after primary auth and > that's exactly what most "Web Programmers" would like to do > because then you just have to invalidate the ticket to force > reauth. Huh? That is not how Kerberos works. Kerberos tickets are not invalidated at all. And with Kerberos, you get even less prompting (more seamless Single Sign-On) than with TLS client certs. > > Services should time-out but most HTTPS CCA-based services do not. > I noted this first when logging in to the Swedish Tax authority. > They are all morons? Maybe. > But the TLS WG has nothing to offer AFAICT. What you are looking for is for a completely different protocol layer than TLS. If you want application level session management, you have to do application level session management. TLS provides you a secure tunnel with Single Sign-On and fast session resumption over later transport connections to the same target (to better match the connection characteristics of HTTP). -Martin
- [TLS] HTTPS client-certificate-authentication in … Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Saint-Andre
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Paul Wouters
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Daniel Kahn Gillmor
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Matt McCutchen
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Stefan Winter
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Henry Story
- Re: [TLS] EU cards Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Peter Gutmann
- Re: [TLS] EU cards Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Henry Story
- Re: [TLS] EU cards Nikos Mavrogiannopoulos
- Re: [TLS] EU cards Yoav Nir
- Re: [TLS] EU cards Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] HTTPS client-certificate-authentication… Wan-Teh Chang
- Re: [TLS] EU cards Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… t.petch
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex