Re: [TLS] Addressing cookie theft (think BEAST) with channel bound

Martin Rex <mrex@sap.com> Thu, 29 September 2011 02:39 UTC

Return-Path: <mrex@sap.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 B945C1F0D20 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 19:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.063
X-Spam-Level:
X-Spam-Status: No, score=-10.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 H-QueSkU1Go0 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 19:39:03 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 06F511F0D1E for <tls@ietf.org>; Wed, 28 Sep 2011 19:39:02 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8T2fqKh006229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 04:41:52 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109290241.p8T2fp7J002311@fs4113.wdf.sap.corp>
To: tom@ritter.vg
Date: Thu, 29 Sep 2011 04:41:51 +0200
In-Reply-To: <CA+cU71moNwfPSrwu=vLc6DegCXWeMdNJHxSdW+g6suBH1x4d4g@mail.gmail.com> from "Tom Ritter" at Sep 28, 11 07:34:34 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 29 Sep 2011 02:39:03 -0000

Tom Ritter wrote:
> 
> I don't think this would work in the (common) case of ssl
> accelerators/forwarders and reverse proxies.  The app just sees HTTP,
> there's no ssl from the point of view of the framework/code a developer
> wrote.

+1

I also do *NOT* want to see any server-side apps to mess/interfere with
TLS session cache management (size and lifetime) on my server or on
whichever backend border component (accelerator/forwarder/rev.proxy)
the SSL session is "first opened".

There is also no guarantee that all client components, that are part
of an application client infrastructure and consciously sharing
HTTP cookies, are accessing the same TLS client implementation and
sharing the TLS session cache.

-Martin