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 > >
- Re: [TLS] Asking the browser for a different cert… Story Henry
- [TLS] Asking the browser for a different certific… Story Henry
- Re: [TLS] Asking the browser for a different cert… Martin Rex
- Re: [TLS] Asking the browser for a different cert… Martin Rex
- Re: [TLS] Asking the browser for a different cert… Wan-Teh Chang
- Re: [TLS] Asking the browser for a different cert… Martin Rex
- Re: [TLS] Asking the browser for a different cert… Marsh Ray
- Re: [TLS] Asking the browser for a different cert… Martin Rex
- Re: [TLS] Asking the browser for a different cert… Marsh Ray
- Re: [TLS] Asking the browser for a different cert… Kyle Hamilton
- Re: [TLS] Asking the browser for a different cert… Michael D'Errico
- Re: [TLS] Asking the browser for a different cert… Marsh Ray
- Re: [TLS] Asking the browser for a different cert… Martin Rex
- Re: [TLS] Asking the browser for a different cert… Dale Gustafson
- Re: [TLS] Asking the browser for a different cert… Kyle Hamilton
- Re: [TLS] Asking the browser for a different cert… Bruno Harbulot
- Re: [TLS] Asking the browser for a different cert… Marsh Ray
- Re: [TLS] [POSSIBLE SPAM] Re: Asking the browser … Kemp, David P.
- Re: [TLS] [POSSIBLE SPAM] Re: Asking the browser … Marsh Ray
- Re: [TLS] [POSSIBLE SPAM] Re: Asking the browser … Kemp, David P.
- Re: [TLS] [POSSIBLE SPAM] Re: Asking the browser … Marsh Ray