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

Henry Story <henry.story@bblfish.net> Tue, 26 July 2011 16:46 UTC

Return-Path: <henry.story@bblfish.net>
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 B46CC11E80EC for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 09:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.346
X-Spam-Level:
X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Ik+7Zs26BvWk for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 09:46:40 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7223221F8ADE for <tls@ietf.org>; Tue, 26 Jul 2011 09:46:40 -0700 (PDT)
Received: by wwg11 with SMTP id 11so2505214wwg.1 for <tls@ietf.org>; Tue, 26 Jul 2011 09:46:39 -0700 (PDT)
Received: by 10.216.160.68 with SMTP id t46mr5158194wek.5.1311698799480; Tue, 26 Jul 2011 09:46:39 -0700 (PDT)
Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id k9sm473870weq.27.2011.07.26.09.46.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 09:46:38 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <201107261510.p6QFA4JH027491@fs4113.wdf.sap.corp>
Date: Tue, 26 Jul 2011 18:46:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4C69697-7352-4CEC-A8A5-83122DBEADCC@bblfish.net>
References: <201107261510.p6QFA4JH027491@fs4113.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1244.3)
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
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 16:46:41 -0000

On 26 Jul 2011, at 17:10, Martin Rex wrote:

> 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.

Yes, I see, that is a good idea. Start by cutting down complexity. Start by making it obvious and simple when all your info comes from one server only. Make responses of that type easy to understand and give them a positive interface.

Then work with artists to see how to present things in more complicated cases, after finding good examples of those, and by seeing how the user would like to be alerted to them.

In any case the same is true with cookies. We should be alerted on where we are leaking information to. 

Henry

> 
> 
> -Martin

Social Web Architect
http://bblfish.net/