IETF Logo Mail Archive

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

"Learmonth, Iain Ross" <iain.learmonth.09@aberdeen.ac.uk> Sun, 17 November 2013 09:27 UTC

Return-Path: <iain.learmonth.09@aberdeen.ac.uk>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B8611E89CA for <perpass@ietfa.amsl.com>; Sun, 17 Nov 2013 01:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGMJ2DnASAYo for <perpass@ietfa.amsl.com>; Sun, 17 Nov 2013 01:27:22 -0800 (PST)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0076.outbound.protection.outlook.com [213.199.154.76]) by ietfa.amsl.com (Postfix) with ESMTP id E405D11E88DA for <perpass@ietf.org>; Sun, 17 Nov 2013 01:25:08 -0800 (PST)
Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB155.eurprd01.prod.exchangelabs.com (10.141.2.154) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sun, 17 Nov 2013 09:25:06 +0000
Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Sun, 17 Nov 2013 09:25:06 +0000
From: "Learmonth, Iain Ross" <iain.learmonth.09@aberdeen.ac.uk>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ted Lemon <mellon@fugue.com>
Thread-Topic: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS
Thread-Index: AQHO40UEGUYnXogIFkmzLFZI27dxtJopJduu
Date: Sun, 17 Nov 2013 09:25:06 +0000
Message-ID: <f642a4561cd34129803b03d38387701e@DB3PR01MB153.eurprd01.prod.exchangelabs.com>
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>
In-Reply-To: <528837B4.7000601@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [84.92.41.201]
x-forefront-prvs: 0033AAD26D
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(81816001)(76482001)(47736001)(87936001)(54316002)(49866001)(83322001)(4396001)(74706001)(81686001)(59766001)(79102001)(77982001)(47976001)(54356001)(63696002)(50986001)(56776001)(85306002)(74876001)(87266001)(66066001)(80022001)(80976001)(53806001)(46102001)(51856001)(65816001)(2656002)(81342001)(69226001)(83072001)(81542001)(74366001)(77096001)(76786001)(76796001)(56816003)(74316001)(33646001)(47446002)(74482001)(74502001)(31966008)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB155; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:84.92.41.201; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: aberdeen.ac.uk
Cc: perpass <perpass@ietf.org>, Phillip Hallam-Baker <hallam@gmail.com>
Subject: Re: [perpass] Unauthenticated, ephemeral keying in HTTP/1.0 without TLS
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 17 Nov 2013 09:27:29 -0000

>> 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?

Iain.

--
Iain R. Learmonth MBCS
Electronics Research Group
School of Engineering
University of Aberdeen
Kings College
Aberdeen
AB24 3UE

Tel: +44 1224 27 2799

The University of Aberdeen is a charity registered in Scotland No.SCO13683

v2.23.0 | Report a Bug | By Email