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

Martin Rex <mrex@sap.com> Wed, 24 March 2010 03:14 UTC

Return-Path: <mrex@sap.com>
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 80B393A68E3 for <tls@core3.amsl.com>; Tue, 23 Mar 2010 20:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.819
X-Spam-Level:
X-Spam-Status: No, score=-7.819 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 Z0cQZ7dNEbtA for <tls@core3.amsl.com>; Tue, 23 Mar 2010 20:14:20 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 132343A68D8 for <tls@ietf.org>; Tue, 23 Mar 2010 20:14:18 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o2O3ET5D021896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Mar 2010 04:14:29 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003240314.o2O3ESig015991@fs4113.wdf.sap.corp>
To: henry.story@bblfish.net (Story Henry)
Date: Wed, 24 Mar 2010 04:14:28 +0100 (MET)
In-Reply-To: <8FCB6B68-2EE5-4BC2-948B-A2640DDB9A93@bblfish.net> from "Story Henry" at Mar 24, 10 01:07:21 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
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
Reply-To: mrex@sap.com
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 03:14:21 -0000

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