Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs
Michael D'Errico <mike-list@pobox.com> Wed, 28 September 2011 21:08 UTC
Return-Path: <mike-list@pobox.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 065AE1F0C7A for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 14:08:09 -0700 (PDT)
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 gPAIfd78uf-e for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 14:08:02 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1671F1F0C73 for <tls@ietf.org>; Wed, 28 Sep 2011 14:08:00 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 52B4978FB; Wed, 28 Sep 2011 17:10:49 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=vmG30h8YidFl IiBNR9c1HZvRcT4=; b=QqNw90ERf1iiiHmsyBi2kSb6z1fseRiPdKYJZ6y16BJ3 Wk3YCx0DKLhw4LScZV6AUcj+eQNXI21ZHzhTwuzVUoelPox6wpmsoh631Chs5p/K PE493mZGO48yqpCAmiOQYEDAlmKTwxpGAGZ0wFTfxWT7SgjRINQ1fyhkM5K/fwE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=lzuTpN lszdVjQQm4hb2i/mg1JKfzeajTdkkz7YsVPM1EvgZDaLAj1kRswVOnQYPX8K17+P m9blIL1XTpoD1e0DlHCPY2OPsyqJNczVbntzbZfnwGDq3YXIVaX0Q2SEhcvIGADN h56K3cWdWwViFzvLlCcVsouJu70rOjQpYgNas=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 4B94678FA; Wed, 28 Sep 2011 17:10:49 -0400 (EDT)
Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 9709E78F9; Wed, 28 Sep 2011 17:10:48 -0400 (EDT)
Message-ID: <4E838D57.4050303@pobox.com>
Date: Wed, 28 Sep 2011 14:10:47 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <CAK3OfOjKwn16uKN44AjDDYoFxJwdghK=21zEKr6zSrp4gzATFQ@mail.gmail.com>
In-Reply-To: <CAK3OfOjKwn16uKN44AjDDYoFxJwdghK=21zEKr6zSrp4gzATFQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 56D39DC8-EA16-11E0-9521-65B1DE995924-38729857!a-pb-sasl-sd.pobox.com
Cc: 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:08:09 -0000
I haven't gone through this in detail, but one problem I see is that it is the client that chooses the session ID for a resumed session when a session ticket is used. In fact the first (full) handshake doesn't even have a session ID! Of course the server can stick whatever identifiers it wants in the ticket (since it is opaque to the client), so this might not be a big deal. Mike Nico Williams wrote: > A while back Dirk Balfanz proposed something he called "origin bound > certificates" and "channel bound cookies". A lighter-weight > alternative (i.e., involving no protocol changes) would be nice. > Mine: use TLS session IDs as the channel binding. > > Suppose you have a server with a TLS stack that generates nice, large, > [pseudo-]random TLS session IDs, and that supports session resumption > (preferably with session tickets). Now have the app's login page bind > the TLS session ID into the cookies it generates for the user's > application session. > > So, if a cookie consists of E(app_service_key, username || > app_session_data) now make it E(app_service_key, username || > app_session_data || tls_session_id). Similarly for other cookie > construction techniques. > > And, critically, change the cookie validation code to check that the > TLS session ID of the connection over which a request was received > matches the cookie's binding. > > This is a pure server-side fix for cookie theft attacks, including BEAST. > > Pre-requisites for this concept to be workable: > > - client support for TLS session resumption (preferably also with > support for session tickets); > - server (concentrator!) support for session resumption (preferably > also with ...); > - TLS session lifetimes matched to cookie lifetimes; > - TLS session IDs must be exposed up the TLS and HTTP server-side > stack (including any concentrators); > - TLS servers that generate large session IDs (32 bytes is the max) > using a suitable [P]RNG. > > Advantages: > > - purely server-side solution; > - does minimal violence to web applications (only cookie generation > and validation are affected); > - can be deployed at any rate; > - no standards-work is required because no protocols are modified > (except, perhaps, in the form of a BCP that we might want to issue > describing this, and maybe a new header by which the server can > advertise that it's channel binding cookies); > - some web server frameworks will probably be able to implement > channel bound cookies transparently to the server application; > - RFC5056-compliant. :) > > Disadvantages: > > - not all server stacks will meet the requirements listed above on day 1; > - we may need a method for detecting clients that don't support > session resumption, if there exist such clients (which I'm sure is > true); however, if such detection can be done from, say, the > user-agent string sent in an HTTPS request (say, the login form POST), > at least we won't have a downgrade attack. > > Can this work? Or is my feverish imagination misleading me? I think > it can work. > > Yes, there's a concern over collisions in the session ID space, but > it's up to 256-bits. It suffices that attackers not have any way to > force a TLS session's ID to match another's. So I don't think this is > a concern. > > It'd be nice, too, if the server could advertise to the user-agent > that its cookies are channel bound, so the user-agent can apply policy > requiring channel bound cookies if it wishes. > > Nico
- [TLS] Addressing cookie theft (think BEAST) with … Nico Williams
- Re: [TLS] Addressing cookie theft (think BEAST) w… Yoav Nir
- Re: [TLS] Addressing cookie theft (think BEAST) w… Nico Williams
- Re: [TLS] Addressing cookie theft (think BEAST) w… Michael D'Errico
- Re: [TLS] Addressing cookie theft (think BEAST) w… Marsh Ray
- Re: [TLS] Addressing cookie theft (think BEAST) w… Nico Williams
- Re: [TLS] Addressing cookie theft (think BEAST) w… Tom Ritter
- Re: [TLS] Addressing cookie theft (think BEAST) w… Nico Williams
- Re: [TLS] Addressing cookie theft (think BEAST) w… Martin Rex
- Re: [TLS] Addressing cookie theft (think BEAST) w… Steve Dispensa
- Re: [TLS] Addressing cookie theft (think BEAST) w… Nikos Mavrogiannopoulos
- Re: [TLS] Addressing cookie theft (think BEAST) w… Florian Weimer
- Re: [TLS] Addressing cookie theft (think BEAST) w… Nico Williams