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

From: Story Henry <[email-masked]>
Date: Wed, 24 Mar 2010 01:07:21 +0100

Hi,

Is there a way for a server to get the browser to ask the user for a new certificate? It seems that a lot of browsers send certificates automatically. Safari is the worst, in that once it makes a decision it never asks the user again it seems. Firefox and Opera ask the user again on restart. This is a problem in a number of situations, such as if the user mistakenly selects the wrong cert. The user experience is really bad as a result.

It seems to me that the browser should show the user what certificate it is using on a connection, and allow the user to change the certificate if he wants to change persona. That seems to me to be a very important piece of feedback.

I filed an issue in Google Chrome for this
   http://code.google.com/p/chromium/issues/detail?id=29784

Please vote on it.

But perhaps there is also a way to do this at a deeper TLS level from the server side. I found that having different server certs at different ports works. But that is to say the least extremely clunky.

Perhaps I have missed something.

Henry 

Social Web Architect
http://bblfish.net/

---

From: Martin Rex <[email-masked]>
Date: Wed, 24 Mar 2010 04:14:28 +0100 (MET)

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

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

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.

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.

-Martin

---

From: Story Henry <[email-masked]>
Date: Wed, 24 Mar 2010 23:49:05 +0100

Thanks for the great info Martin.

> 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

> announced when requesting a client certificate, would also be

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.

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

> 4.0.4 was defective and I didn't see any clues about this fix

Thanks for the details. That will be very useful.

Henry

---

From: Martin Rex <[email-masked]>
Date: Sat, 27 Mar 2010 00:41:29 +0100 (MET)

> till now I found was to have multiple server ports open each with a 

You mean a server listening on multiple TCP ports for HTTP-over-TLS
incoming requests, with different TLS server certificates for each
of these TCP ports and different requirement levels for client certificate?

The purpose of "different server certs for each TCP port" is not clear
to me.  rfc-2818 server endpoint identification does not distinguish
ports.

Depending on how much cross-referencing there is from the content
on those different ports, and how much parallel access there is
from a single user to contents on seperate ports, you may run into
a TLS session caching issue with some browsers.  Some Web Browsers
do not distinguish TCP server ports (present in the URL)
in their client side TLS session caching.  Some blindly assume
that servers on the same host share their TLS session cache
and therefore exhibit frequent full TLS handshakes when
multiple distinct servers on the same host are concurrently
accessed (and probably flushing each TLS session where TLS session
resume fails).

-Martin

---

From: Wan-Teh Chang <[email-masked]>
Date: Fri, 26 Mar 2010 17:11:40 -0700

> of WinHTTP rather than a conscious choice of the Browser designers.

Google Chrome 1.0 used WinHTTP.  Starting in Chrome 2.0, Chrome is
using the Microsoft SChannel directly.

Like MSIE, the Windows version of Chrome closes the network connection
while prompting the user to select a client certificate.  This could be due to
a limitation of the SChannel, but I agree with you that it's a very sensible
behavior.

Wan-Teh Chang