Re: [TLS] Asking the browser for a different certificate

Story Henry <henry.story@bblfish.net> Wed, 24 March 2010 22:49 UTC

Return-Path: <hjs@bblfish.net>
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 DDE293A6DD2 for <tls@core3.amsl.com>; Wed, 24 Mar 2010 15:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.009
X-Spam-Level: *
X-Spam-Status: No, score=1.009 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619]
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 fdRUcNEWSb7f for <tls@core3.amsl.com>; Wed, 24 Mar 2010 15:49:02 -0700 (PDT)
Received: from bblfish.net (rust.entic.net [199.89.53.222]) by core3.amsl.com (Postfix) with ESMTP id 27ACA3A6DD0 for <tls@ietf.org>; Wed, 24 Mar 2010 15:49:01 -0700 (PDT)
Received: from 13.244-226-89.dsl.completel.net ([89.226.244.13] helo=bblfish.darty) by bblfish.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <hjs@bblfish.net>) id 1NuZO3-000149-WC; Wed, 24 Mar 2010 15:49:21 -0700
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Story Henry <henry.story@bblfish.net>
In-Reply-To: <201003240314.o2O3ESig015991@fs4113.wdf.sap.corp>
Date: Wed, 24 Mar 2010 23:49:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6FBE60E-803D-4430-B2A7-6BDB42FF0447@bblfish.net>
References: <201003240314.o2O3ESig015991@fs4113.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1077)
Sender: hjs@bblfish.net
Cc: tls@ietf.org
Subject: Re: [TLS] Asking the browser for a different certificate
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-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: Wed, 24 Mar 2010 22:49:04 -0000

Thanks for the great info Martin.

On 24 Mar 2010, at 04:14, Martin Rex wrote:

> These are several different issues, and you forgot to
> mention the OS/platforms that you are "complaining" about.

Well all of them :-)
Chrome could be on the verge of fixing this problem which is why I 
suggested people here add a star to this bug report

http://code.google.com/p/chromium/issues/detail?id=29784

> 
> AFAIK, Apple Safari and Chrome, when running on Microsoft Windows,
> use the Microsoft WinHTTP API and therefore the Microsoft SChannel SSP
> as the TLS provider and much of the (default) behaviour might be that
> of WinHTTP rather than a conscious choice of the Browser designers.
> 
> 
> MSIE, when receiving a request for a client certificate, closes the
> network connection while prompting the user for a choice of the
> client certificate.  IMHO that is actually a very sensible behaviour,
> rather than tying up server resources in the middle of a TLS handshake
> for an indefinite amount of time while waiting for user input.
> MSIE (or maybe the event-based WinHTTP) will memorize that decision
> and perform the next TLS handshake on a new connection without
> user interaction.
> 
> That browsers show only the servers identity when you check the
> security settings for a page, but not the information whether
> a client cert was requested, which client cert was used, if any,
> should be considered a defect of pretty much all browsers.
> A possibility to visualize the list of trusted CAs, which a server
> announced when requesting a client certificate, would also be
> nice...

Completely agree. I even put out a call for hackers to help us put 
together a Firefox plugin to demonstrate the correct behaviour.

http://bit.ly/cQ5f48

I urge people to open similar bug reports for all the other browsers.
If a few do the right thing, the major UI problem could soon be a thing
of the past.

> 
> 
> IMHO there are a number of defects in the TLS protocol related
> to client certificate authentication, and some of them should probably
> be fixed at the TLS protocol level.  But fixes at the TLS protocol
> level may take a huge amount of time before they become a useful
> feature in the installed base...
> 
>  - the TLS client can not indicate that it posseses a client cert
>    (so a server has to probe--and by probing create a
>     bad user experience for users without client cert)
>    TLS renegotiation has been abused in the past to reduce the
>    bad user experience side of the problem.
> 
>  - the TLS client can not indicate that it does _not_ posess or
>    is firmly determined to not send a client cert
> 
>  - the TLS server can not recommend to the TLS client that the client
>    should offer a user a possibility to change his selection of
>    client certificate for the current handshake.

Yes. I am now looking for hacks to help people with defective browsers 
participate in a world of secure client certificates. The only one up 
till now I found was to have multiple server ports open each with a 
different server key. 

If browser vendors fix the above issue, it will still be useful to have
some libraries - a bit like the javascript cross browser libraries - to help create a bridge to that secure future...

> Client certificate support in Apple Safari 4 Windows seems to be
> somewhat outdated.  WinHTTP originally had a defect in the client
> certificate support, and Apple seems to have programmed only for
> the old (incomplete) client certificate support in WinHTTP.
> 
> That WinHTTP defect was fixed here
> 
>    http://support.microsoft.com/kb/909425
> 
> and the relevant documentation for correct WinHTTP use would be here
> 
>    http://msdn.microsoft.com/en-us/library/aa384066(VS.85).aspx
> 
> specifically the parts labelled with
> 
>   Windows Server 2003 with SP1 and Windows XP with SP2:
>   The ... macro is not supported
> 
> I don't know whether Apple Safari 4 Windows has been fixed already.
> 4.0.4 was defective and I didn't see any clues about this fix
> in the 4.0.5 changelog.

Thanks for the details. That will be very useful.

Henry

> 
> 
> -Martin