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

Dale Gustafson <degustafson@comcast.net> Mon, 29 March 2010 22:48 UTC

Return-Path: <degustafson@comcast.net>
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 ED5283A690B for <tls@core3.amsl.com>; Mon, 29 Mar 2010 15:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.469
X-Spam-Level:
X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 We1ABDQicRwk for <tls@core3.amsl.com>; Mon, 29 Mar 2010 15:48:49 -0700 (PDT)
Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 1D6E83A68A0 for <tls@ietf.org>; Mon, 29 Mar 2010 15:48:49 -0700 (PDT)
Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta03.emeryville.ca.mail.comcast.net with comcast id z1Ct1d0021GXsucA3ApJrG; Mon, 29 Mar 2010 22:49:18 +0000
Received: from [138.220.19.98] ([138.220.19.98]) by omta07.emeryville.ca.mail.comcast.net with comcast id zAp71d00926xugA8TAp9nl; Mon, 29 Mar 2010 22:49:16 +0000
Message-ID: <4BB12E61.7000802@comcast.net>
Date: Mon, 29 Mar 2010 18:49:05 -0400
From: Dale Gustafson <degustafson@comcast.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: mrex@sap.com
References: <201003292156.o2TLuN5d001961@fs4113.wdf.sap.corp>
In-Reply-To: <201003292156.o2TLuN5d001961@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
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: 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.

Best,

--dg






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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>