Re: [TLS] Asking the browser for a different certificate
Marsh Ray <marsh@extendedsubset.com> Mon, 29 March 2010 18:47 UTC
Return-Path: <marsh@extendedsubset.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 D523A3A6AB8 for <tls@core3.amsl.com>; Mon, 29 Mar 2010 11:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.481
X-Spam-Level:
X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, 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 GyxpQAxuaH7R for <tls@core3.amsl.com>; Mon, 29 Mar 2010 11:47:23 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 94A6E3A6AAA for <tls@ietf.org>; Mon, 29 Mar 2010 11:47:22 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NwK06-000O9K-Bo; Mon, 29 Mar 2010 18:47:50 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2133660B8; Mon, 29 Mar 2010 18:47:48 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19/cesRGe4kKTu9lQXyWOyZ+ycFFKaQtD8=
Message-ID: <4BB0F5D4.9010500@extendedsubset.com>
Date: Mon, 29 Mar 2010 13:47:48 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: mrex@sap.com
References: <201003291745.o2THjKgr017986@fs4113.wdf.sap.corp>
In-Reply-To: <201003291745.o2THjKgr017986@fs4113.wdf.sap.corp>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
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 18:47:23 -0000
On 3/29/2010 12:45 PM, Martin Rex wrote: > Marsh Ray wrote: >> >> Consider an attacker passively sniffing public wifi in a coffee shop >> near a targeted organization. Now he sees who has his smart card in the >> reader and activated. > > To me this sounds extremely farfetched. Really? It's pretty standard stuff http://www.google.com/search?q=wifi+penetration+testing > The ClientHello also "leaks" the maximum protocol_version that your > client supports, the cipher_suites and compression algs your client > is willing to use. Yes, there are lots of ways existing TLS clients can be fingerprinted. > The reason why a client may be sending that information may be manyfold, > not necessarily a presence of a Smartcard. True. Still, as more TLS extensions get used in practice, I think each extension's potential for info leakage needs to be well understood and well documented. > A client could implement > a caching of a users decision to present a client cert, e.g. on a > per-server basis, or for a specific amount of time (for the next X hours). > > 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. 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. > 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! :-) B. All cryptography used to be super secret spy stuff. But the trend has been only accelerating over the years that data security practices that were formerly considered paranoid are increasingly necessary for business to resist corporate espionage and individuals to retain some online privacy from intrusive ISPs and governments. > 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. 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. - Marsh
- 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