IETF Logo Mail Archive

Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs

Marsh Ray <marsh@extendedsubset.com> Wed, 28 September 2011 21:17 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664CA21F8E11 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 14:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level:
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 My0biCZKjHHS for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 14:17:54 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 68D5421F8E0C for <tls@ietf.org>; Wed, 28 Sep 2011 14:17:54 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1R91YY-000NkF-Jy; Wed, 28 Sep 2011 21:20:42 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C15446067; Wed, 28 Sep 2011 21:20:39 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19WGKYwwHbW9kBCTiAN2RaOqnKH0tx+7aA=
Message-ID: <4E838FA6.6090203@extendedsubset.com>
Date: Wed, 28 Sep 2011 16:20:38 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <CAK3OfOjKwn16uKN44AjDDYoFxJwdghK=21zEKr6zSrp4gzATFQ@mail.gmail.com> <E4076194-2A43-4282-B282-37B14CBCB488@checkpoint.com>
In-Reply-To: <E4076194-2A43-4282-B282-37B14CBCB488@checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Wed, 28 Sep 2011 21:17:55 -0000

On 09/28/2011 04:01 PM, Yoav Nir wrote:
>
> If the server-side HTTP stack has that, why would such an application
> even need cookies? Cookies are generally keys to a saved server-side
> state. If you have access to the TLS session ID, you might as well
> use that as the key to the saved server-side state.

It seems that most web apps are developed using some type of framework. 
These frameworks are often optimized for the plain-HTTP case.

Often HTTPS, and the certs, etc. aren't brought in until somewhat late 
in the development process. Apps get developed using cookies, then 
(occasionally) deployed with TLS as an encrypted tunnel for security. So 
we end up with all these insufficiently-bound channels needing channel 
binding.

When apps are developed with using TLS from the beginning, the result 
ends up looking much more integrated. But we also need to look for 
solutions that benefit all the other apps out there.

- Marsh

v2.23.0 | Report a Bug | By Email