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

Martin Rex <mrex@sap.com> Mon, 29 March 2010 21:56 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 386E33A6BA2 for <tls@core3.amsl.com>; Mon, 29 Mar 2010 14:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.208
X-Spam-Level:
X-Spam-Status: No, score=-7.208 tagged_above=-999 required=5 tests=[AWL=-0.689, 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 RpSZMvIecwgi for <tls@core3.amsl.com>; Mon, 29 Mar 2010 14:56:02 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 42E193A6B83 for <tls@ietf.org>; Mon, 29 Mar 2010 14:56:01 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o2TLuOvE000586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Mar 2010 23:56:24 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003292156.o2TLuN5d001961@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Mon, 29 Mar 2010 23:56:23 +0200 (MEST)
In-Reply-To: <4BB0F5D4.9010500@extendedsubset.com> from "Marsh Ray" at Mar 29, 10 01:47:48 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
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: Mon, 29 Mar 2010 21:56:03 -0000

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