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

Marsh Ray <marsh@extendedsubset.com> Tue, 30 March 2010 15:53 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 B90253A6C54 for <tls@core3.amsl.com>; Tue, 30 Mar 2010 08:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.687
X-Spam-Level:
X-Spam-Status: No, score=0.687 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_40=-0.185, 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 99LjjgdRGzGy for <tls@core3.amsl.com>; Tue, 30 Mar 2010 08:53:26 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 40FD63A6839 for <tls@ietf.org>; Tue, 30 Mar 2010 08:53:26 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NwdlL-000D2k-8k; Tue, 30 Mar 2010 15:53:55 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4680B60B8; Tue, 30 Mar 2010 15:53:54 +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: U2FsdGVkX1/fkn7Pg+EMgg6HPeGPiVIwaZZnAcgXvKQ=
Message-ID: <4BB21E93.2040103@extendedsubset.com>
Date: Tue, 30 Mar 2010 10:53:55 -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: "Kemp, David P." <DPKemp@missi.ncsc.mil>
References: <4BAE396B.9090104@extendedsubset.com> <201003291745.o2THjKgr017986@fs4113.wdf.sap.corp> <6b9359641003291236t4e7bd0c6ycc5c5a435f38f3cf@mail.gmail.com> <4BB1077D.4030506@pobox.com><6b9359641003291622y4310e1f2p18301fde231701c8@mail.gmail.com> <4BB15250.6080306@extendedsubset.com> <201003301424.o2UEOiJv013761@stingray.missi.ncsc.mil> <4BB20FBB.9000608@extendedsubset.com> <201003301530.o2UFU2XJ019961@stingray.missi.ncsc.mil>
In-Reply-To: <201003301530.o2UFU2XJ019961@stingray.missi.ncsc.mil>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] [POSSIBLE SPAM] Re: 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: Tue, 30 Mar 2010 15:53:27 -0000

On 3/30/2010 10:29 AM, Kemp, David P. wrote:
> Neither AT&T nor China can authenticate themselves as facebook.com
> (assuming the browser trust list is properly managed, all trusted
> issuers are trustworthy, the user won't confuse facebook.com.cn with
> facebook.com, etc.).

My understanding is that cell phone carriers install their own trusted
root cert for that purpose. I don't know about China, but I would assume
it's at least sometimes the case.

"Below is a list of trusted root certificates which are pre-installed
with the iPhone 3.0 software"
http://support.apple.com/kb/HT3580

> ADH does not protect against data stealing or
> session hijacking in general; authenticated TLS performs that function.
> The ADH tunnel protects just one small piece of data (the certificates)
> from eavesdropping during the TLS authentication handshake.

DHE ciphersuites do not protect the client cert info. On an initial
handshake, the client cert info is passed in-the-clear before the Change
Cipher Spec message takes effect. When client certs are passed on
renegotiation, any effective ciphersuite protects the client cert info,
not just DHE ones.

But unless the client refuses to pass his client certificate except
during a renegotiation that occurs inside an well encrypted connection
with a strongly authenticated server, the client cert info is available
to active attackers. I don't know of any client apps that do this, it's
probably not allowed behavior for https.

> If AT&T and China and 10 other players all insert themselves between the
> user and facebook.com, they can all learn the identities of the user and
> of facebook.  But none of them can view or modify any data sent over
> mutually-authenticated TLS.

I don't think facebook.com actually supports TLS mutual auth (i.e.,
client certs).

> Social networking sites are not a useful example because they don't use
> TLS for most pages and they don't do client authentication for the few
> pages that do use TLS.  But if banking / medical sites actually used
> client-authenticated TLS for all pages (instead of little
> phish-prevention pictures and personal-knowledge questions and
> passwords), then AT&T would be out of luck.

Or maybe those sites just wouldn't work on an iPhone, or from behind
corporate SSL-intercepting firewalls.

- Marsh