Re: [http-state] cake and session stealing

"Thomson, Martin" <Martin.Thomson@andrew.com> Tue, 27 July 2010 08:25 UTC

Return-Path: <Martin.Thomson@andrew.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 0EFE53A6B9A for <http-state@core3.amsl.com>; Tue, 27 Jul 2010 01:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.222
X-Spam-Level:
X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599]
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 KzVqzz9yFKaz for <http-state@core3.amsl.com>; Tue, 27 Jul 2010 01:25:16 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 1EF3C3A6B98 for <http-state@ietf.org>; Tue, 27 Jul 2010 01:25:16 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:57037 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S343854Ab0G0IZh (ORCPT <rfc822; http-state@ietf.org>); Tue, 27 Jul 2010 03:25:37 -0500
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 27 Jul 2010 03:25:37 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 27 Jul 2010 16:25:35 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Adam Barth <ietf@adambarth.com>
Date: Tue, 27 Jul 2010 16:27:47 +0800
Thread-Topic: cake and session stealing
Thread-Index: AcstZEC8tit2jDQaSzmXNEygkipRmwAAGrHg
Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB77373E@SISPE7MB1.commscope.com>
References: <8B0A9FCBB9832F43971E38010638454F03EB773659@SISPE7MB1.commscope.com> <AANLkTi=2y+EDtyer3vn-eX8j-ao0U9jGnS-PDirqSojB@mail.gmail.com> <8B0A9FCBB9832F43971E38010638454F03EB773720@SISPE7MB1.commscope.com> <AANLkTikB-Xn-t-_0pHoY+9eWZueAUyXLfnd5cF=mJO9G@mail.gmail.com>
In-Reply-To: <AANLkTikB-Xn-t-_0pHoY+9eWZueAUyXLfnd5cF=mJO9G@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
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:25:17 -0000

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

We were talking about the step from unsecured TCP to TLS.  The problem was that state accumulated prior to this step is attributed to the client.

Cake ensures that the same client can be identified.

If you have a MITM, then you can do this:

Accept the client cake C and forward their requests on using a different cake F.  State A is established against cake F.

In parallel, establish desired state against cake C.  Then when the client hops to a secured connection, they start using your desired state.

The only solution I see to this is to treat anything that comes in on an unsecured connection as suspect.  Online shopping services do this - you build a cart, but they confirm again on the secured part (sometimes several times).

--Martin