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

Story Henry <> Wed, 24 March 2010 22:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDE293A6DD2 for <>; Wed, 24 Mar 2010 15:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fdRUcNEWSb7f for <>; Wed, 24 Mar 2010 15:49:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 27ACA3A6DD0 for <>; Wed, 24 Mar 2010 15:49:01 -0700 (PDT)
Received: from ([] helo=bblfish.darty) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <>) 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 <>
In-Reply-To: <>
Date: Wed, 24 Mar 2010 23:49:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.1077)
Subject: Re: [TLS] Asking the browser for a different certificate
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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

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
> and the relevant documentation for correct WinHTTP use would be here
> 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.


> -Martin