IETF Logo Mail Archive

Re: [perpass] CDNs as wiretaps [Unauthenticated, ephemeral keying in HTTP/1.0 without TLS]

Eric Burger <eburger@standardstrack.com> Mon, 25 November 2013 12:46 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2901AD957 for <perpass@ietfa.amsl.com>; Mon, 25 Nov 2013 04:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.122
X-Spam-Level:
X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ll42NMClotkZ for <perpass@ietfa.amsl.com>; Mon, 25 Nov 2013 04:46:41 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) by ietfa.amsl.com (Postfix) with ESMTP id A9D1A1AD34C for <perpass@ietf.org>; Mon, 25 Nov 2013 04:46:41 -0800 (PST)
Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:53065 helo=[192.168.15.105]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <eburger@standardstrack.com>) id 1VkvYm-00014J-9K for perpass@ietf.org; Mon, 25 Nov 2013 04:46:41 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_2F4A1F7C-239A-4375-80AE-E9AC52CA3B99"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Message-Id: <06D44542-5BB7-4046-86EE-CD24B3D052E4@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Date: Mon, 25 Nov 2013 07:46:34 -0500
References: <CAMm+Lwg-AF9fZ5=f5W8JDmiCe=U7Uyxso_bdHGaQhddsQ+aGaw@mail.gmail.com> <5287FA09.3060100@gmail.com> <C6822D2B-DE14-43FF-A2D4-F96941F054B7@fugue.com>, <528837B4.7000601@gmail.com> <f642a4561cd34129803b03d38387701e@DB3PR01MB153.eurprd01.prod.exchangelabs.com> <5289125D.6020100@gmail.com> <F11F9E60-05E9-45EF-8B38-E8E1E2BB54A2@cs.georgetown.edu>
To: perpass <perpass@ietf.org>
In-Reply-To: <F11F9E60-05E9-45EF-8B38-E8E1E2BB54A2@cs.georgetown.edu>
X-Mailer: Apple Mail (2.1822)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [perpass] CDNs as wiretaps [Unauthenticated, ephemeral keying in HTTP/1.0 without TLS]
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2013 12:46:43 -0000

Is it physically possible to tell the difference between a CDN and a MITM? IMHO the only way of doing this is if the authentication token presented by the CDN saying it represents the source is if that token is issued (signed) by the source.

In theory, no problem. X.509 chains have no problem with Symantec issuing a certificate to foo (the source) and foo issuing a certificate on foo’s behalf to bar (the CDN).

In reality, foo is buying service from bar *because* they are not in the IT business. They want bar to handle all of the “technical stuff.”

If we can make this easy, we can break the CDN = MITM connection.

On Nov 17, 2013, at 2:00 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> 
> On 17/11/2013 22:25, Learmonth, Iain Ross wrote:
>>>> Also, to completely contradict that point, facebook with https enabled still uses a CDN, so the theory that https prevents CDNs from working is apparently wrong anyway.
>> 
>>> I said "possibly" because I wasn't sure. Maybe somebody can explain
>> how it works and how the associated trust model works?
>> 
>> The CDN has one TLS connection from the client to the CDN and another from the CDN to the server, it sees everything in plaintext. A CA signs the CDNs TLS server certificate so that it can still be accepted by browsers. Depending on the CA, different verifications of ownership may be made.
>> 
>> This does raise the issue that these CDNs, which may be managing many large services, would be a great place to tap the wires. Maybe we should be discouraging them?
> 
> Yep, that's my concern about the trust model (also after redaing Ted Lemon's response).
> 
> All I know is that some site I have decided to trust has redirected me
> to content on a third-party site, which presents an apparently valid cert.
> I don't understand why I should trust that third-party site.
> 
>  Brian
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass

v2.23.0 | Report a Bug | By Email