IETF Logo Mail Archive

Re: [http-state] cake and session stealing

Adam Barth <ietf@adambarth.com> Tue, 27 July 2010 08:18 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51DD33A6A07 for <http-state@core3.amsl.com>; Tue, 27 Jul 2010 01:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.717
X-Spam-Level:
X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 fqHys+GDUo8L for <http-state@core3.amsl.com>; Tue, 27 Jul 2010 01:18:02 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 407133A6BB7 for <http-state@ietf.org>; Tue, 27 Jul 2010 01:17:48 -0700 (PDT)
Received: by iwn38 with SMTP id 38so3805317iwn.31 for <http-state@ietf.org>; Tue, 27 Jul 2010 01:18:10 -0700 (PDT)
Received: by 10.231.17.7 with SMTP id q7mr5314682iba.57.1280218689832; Tue, 27 Jul 2010 01:18:09 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id r3sm4583772ibk.19.2010.07.27.01.18.08 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 01:18:08 -0700 (PDT)
Received: by iwn38 with SMTP id 38so3805298iwn.31 for <http-state@ietf.org>; Tue, 27 Jul 2010 01:18:07 -0700 (PDT)
Received: by 10.231.148.20 with SMTP id n20mr9917608ibv.196.1280218686504; Tue, 27 Jul 2010 01:18:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.79.85 with HTTP; Tue, 27 Jul 2010 01:17:45 -0700 (PDT)
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB773720@SISPE7MB1.commscope.com>
References: <8B0A9FCBB9832F43971E38010638454F03EB773659@SISPE7MB1.commscope.com> <AANLkTi=2y+EDtyer3vn-eX8j-ao0U9jGnS-PDirqSojB@mail.gmail.com> <8B0A9FCBB9832F43971E38010638454F03EB773720@SISPE7MB1.commscope.com>
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 27 Jul 2010 10:17:45 +0200
Message-ID: <AANLkTikB-Xn-t-_0pHoY+9eWZueAUyXLfnd5cF=mJO9G@mail.gmail.com>
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "http-state@ietf.org" <http-state@ietf.org>
Subject: Re: [http-state] cake and session stealing
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jul 2010 08:18:03 -0000

On Tue, Jul 27, 2010 at 9:13 AM, Thomson, Martin
<Martin.Thomson@andrew.com> wrote:
>> > An attacker that can control where you go (the URL) can equally
>> control what cookies you get.  What am I missing here?
>>
>> Cake is never sent from the server to the client.  It's only ever sent
>> from the client to the server, and then only over TLS.  An active
>> network attacker cannot interact with the cake for HTTPS.  (Of course,
>> he can steal the HTTP cake, but there's no way to defend HTTP from
>> network attackers anyway.)
>
> That's where my concern arose.  An attacker that is playing MITM can simply use their own cake.  Are we basically looking for something with basically "leap of faith" characteristics?

There's no leap of faith.  How does the MITM alter the cake in the TLS tunnel?

> I suppose that it is an advantage that the attacker needs to arrange for an attack by playing MITM for all requests, which requires a degree more premeditation.  I'm not convinced that it's significantly better than the mechanisms we already have.

The protocol is designed to resist MITM attacks.  Cookies cannot.  The
security property are demonstrably stronger.

Adam

v2.23.0 | Report a Bug | By Email