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

[Story Henry <[e-mail]>]

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