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

[Dale Gustafson <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>