Re: [TLS] HTTPS client-certificate-authentication in browsers

Martin Rex <mrex@sap.com> Tue, 26 July 2011 15:10 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 D4F2C21F84B6 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 08:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.85
X-Spam-Level:
X-Spam-Status: No, score=-9.85 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 D9HWSCn0Tlb5 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 08:10:32 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C682021F8BEB for <tls@ietf.org>; Tue, 26 Jul 2011 08:10:11 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6QFA5NU018371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jul 2011 17:10:05 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107261510.p6QFA4JH027491@fs4113.wdf.sap.corp>
To: henry.story@bblfish.net (Henry Story)
Date: Tue, 26 Jul 2011 17:10:04 +0200 (MEST)
In-Reply-To: <13CDC8F7-572C-43C6-9123-29E291B4132B@bblfish.net> from "Henry Story" at Jul 26, 11 04:34:09 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 15:10:34 -0000

Henry Story wrote:
> 
> On 26 Jul 2011, at 01:51, Martin Rex wrote:
> > 
> > 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.
> > 
> > > 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.
> 
> The way to solve both of those issues is just a better User Interface.
> At the Identity in the Browser W3C Workshop earlier this year [1]
> we pointed to the work of Aza Raskin who showed very simply and clearly
> what needed to be done:
> 
>    http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
> 
> The user in the browser should be aware for ever tab what client certificate
> he is using for the content he is seeing, just as he is aware of the server 
> identity. This would make logging out, a one click affair controlled from
> the browser - the only place where that can be done correctly.


You're just scratching the surface of the problem.

Browsers have just one address bar and one chrome element to signal
about the servers and your identity _per_window_. 

The only sensible approach to obtain a secure browser would be to
strictly enforce a single-source policy, i.e. when https:// is used,
*ALL* resources must be served from the exact same server.
That is not currently done, your page may contain resources from
20 different servers and could be using 20 different client certs,
and it is not obvious for the end user which elements on the
page are from which of the servers.


-Martin