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

Dale Gustafson <> Mon, 29 March 2010 22:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED5283A690B for <>; Mon, 29 Mar 2010 15:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.469
X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id We1ABDQicRwk for <>; Mon, 29 Mar 2010 15:48:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1D6E83A68A0 for <>; Mon, 29 Mar 2010 15:48:49 -0700 (PDT)
Received: from ([]) by with comcast id z1Ct1d0021GXsucA3ApJrG; Mon, 29 Mar 2010 22:49:18 +0000
Received: from [] ([]) by with comcast id zAp71d00926xugA8TAp9nl; Mon, 29 Mar 2010 22:49:16 +0000
Message-ID: <>
Date: Mon, 29 Mar 2010 18:49:05 -0400
From: Dale Gustafson <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 29 Mar 2010 22:48:51 -0000

FWIW, the more vexing problem is the browser that *always* requires the 
user to select a TLS-client certificate whenever there are two or more 
that satisfy website requirements.

See CA Siteminder's "certificate or forms" authentication method for one 
workable approach to providing user-auth service to a diverse user base, 
many of whom have no acceptable certificate for some (or all) use cases.



On 3/29/2010 5:56 PM, Martin Rex wrote:
> Marsh Ray wrote:
>>> For those users that use SmartCards enabled for TLS client cert
>>> authentication, you will see their entire certificate flying by
>>> in the clear in the regular TLS handshake when they connect
>>> to the TLS server for which they plugged their SmartCard in the
>>> first place.
>> As you know, many web servers request the client cert under an existing
>> encrypted session via renegotiation specifically because they don't want
>> that to happen.
> I'm not sure that this was the original motivator for implementing
> it that way, and that it is always a conscious decision of Web Server
> admin, whose Web Server operates that way.
> Another reason might be the desire to serve clients with certs and client
> without certs from the same Server port, in particular for users
> without client certs using non-Microsoft Browsers -- because of
> the negative user experience impact of the CertificateRequest message
> with most browsers default settings.
> If you configure MS IIS6 on W2K3sp2 for "optional" client certs,
> i.e. mixed access for clients with and without client certs, then
> TLS session caching effectively doesn't work for clients without
> client certs -- because they will be forced through a renegotiation
> on each connect (including TLS session resumes).  I don't know what
> particular problem there is why MS IIS6/W2K3sp2 does not cache
> the meta-information that the client had actively declined a prior
> CertificateRequest on renegotiation.
> Although TLS renegotiation might "hide" client certs from
> passive observers, like sniffable wifi environments, the attacker
> could insert fake data into the TLS handshake without much hazzle,
> e.g.  a fake ServerHello+ServerCertificate+CertificateRequest+ServerHelloDone
> followed by some Fatal SSL Alert (bad_certificate,unsupported_certificate,
> unknown_ca) and use an empty list of CAs in the CertificateRequest
> message.  That will likely elicit the client cert in the clear
> from those browsers that would be sending/using it to the real server.
> Although this is going to result in a connection failure for that
> particular TLS handshake, the attacker does not necessarily care--
> if his objective is to obtain the client's TLS client cert.
>> Passing the TLS record content type in plaintext (so the renegotiation
>> becomes visible to a passive observer) is another info leak that would
>> be good to fix.
> Things would become less clear to off-the-shelf network analyzers
> that visualize network traffic, but you will gain little by this
> for any competent traffic analysis near the client if that is
> the only change to the protocol.
> The size difference between
>     ChangeCipherSpec+Finished
> vs.
>     Certificate+CertificateVerify+ChangeCipherSpec+Finished
> is pretty significant.
> And in regular usage scenarios, TLS renegotiation will result in a
> new TLS session ID, and the change of the TLS session ID is going to be
> visible on new/parallel/later network connections to the same server.
>>> And would you make your client include a "certificate URL extension"
>>> even when the client does not have a client certificate.  Well, maybe
>>> -- if you are the CIA and ordering your constant daily batch of pizzas.  :)
>> A. I think everyone should be able to order their pizzas over TLS! :-)
> Absolutely!
>>> Maybe you should not use any secure authentication protocols like
>>> Kerberos or TLS if you want to entirely hide that fact, that you possess
>>> secure client credentials.
>> Yep, those with the highest security requirements are better off
>> connecting only through a VPN, or not remotely at all. To some degree
>> this can be considered a failure of the existing security protocols.
> Hiding this level of information (availability of secure client creds)
> from traffic analysis will be pretty difficult.
> It's doable for passive ob servers near the server if there are many
> clients and "onion routing" is used.  But when the passive observer
> is very close the the client he wants to observe (like on his network
> segment), it becomes quite difficult for the client to hide from
> traffic analysis with existing protocols, so that it hides even the
> mere fact that the client uses secure/cryptographic credentials
> for authentication.
>> Your "I don't have any client certs" extension suggestion is probably
>> not that big a deal, it's hard to tell. I think the deeper problem is
>> that TLS client authentication requires the client to transmit and sign
>> with his cert before he is able to strongly authenticate the server.
> I would describe it a "don't bother to CertificateRequest me" extension,
> and it could also be used by any (background) service that performs
> downloads under TLS-protection with no access to the interactive
> user's credentials/smartcard.
> -Martin
> _______________________________________________
> TLS mailing list