Re: [TLS] [POSSIBLE SPAM] Re: Asking the browser for a different certificate
"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 30 March 2010 15:29 UTC
Return-Path: <DPKemp@missi.ncsc.mil>
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 74FAD3A6A6A for <tls@core3.amsl.com>; Tue, 30 Mar 2010 08:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.5
X-Spam-Level:
X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
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 NIuvWLZXNNEU for <tls@core3.amsl.com>; Tue, 30 Mar 2010 08:29:34 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id CF9AA3A68B3 for <tls@ietf.org>; Tue, 30 Mar 2010 08:29:32 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Mar 2010 11:29:58 -0400
Message-ID: <201003301530.o2UFU2XJ019961@stingray.missi.ncsc.mil>
In-Reply-To: <4BB20FBB.9000608@extendedsubset.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] [POSSIBLE SPAM] Re: Asking the browser for a different certificate
thread-index: AcrQGF9uJJ//OYkSSse91tLbzcmCUwAANbsw
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>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: TLS Mailing List <tls@ietf.org>
X-OriginalArrivalTime: 30 Mar 2010 15:31:01.0343 (UTC) FILETIME=[00BC7EF0:01CAD01E]
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:29:38 -0000
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.). 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. 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. 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. Dave -----Original Message----- From: Marsh Ray [mailto:marsh@extendedsubset.com] Sent: Tuesday, March 30, 2010 10:51 AM To: Kemp, David P. Cc: TLS Mailing List Subject: Re: [TLS] [POSSIBLE SPAM] Re: Asking the browser for a different certificate Importance: Low On 3/30/2010 9:24 AM, Kemp, David P. wrote: > ADH is a pretty standard way of > reducing ID exposure from an infinite number of attackers down to 1 > active party It doesn't reduce it to one active party because Malloy can't know any better than Alice or Bob if one of his connections is itself being MITM'd. One could imagine amusing scenarios where AT&T and China bump into each other on the wire and begin to argue "hey, buddy, go get your own Facebook connection". http://mashable.com/2010/01/16/att-facebook-error/ https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005260.ht ml > and 0 passive parties. That's a fairly significant > reduction. Defeating passive eavesdropping is important, but it's sufficient in general. In the past, people were on shared Ethernet and would naturally be in a position to quietly observe every packet going by. For several common types of attacks today it's no harder to modify the packets than it is to observe them. Think of China and Pakistan DNS- and BGP-jacking YouTube for recent examples. - 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