Re: [TLS] Rizzo claims implementation attach, should be interesting

Marsh Ray <> Wed, 21 September 2011 02:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2A7021F8C83 for <>; Tue, 20 Sep 2011 19:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.638
X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y-UEHgCum6r1 for <>; Tue, 20 Sep 2011 19:31:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 025A221F8C88 for <>; Tue, 20 Sep 2011 19:31:04 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.72) (envelope-from <>) id 1R6Ccu-0001S1-8n; Wed, 21 Sep 2011 02:33:32 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 32498606C; Wed, 21 Sep 2011 02:33:30 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX19OUNl5L4vPdZbSoBP/Sjrj5j6iMA5oyXo=
Message-ID: <>
Date: Tue, 20 Sep 2011 21:33:29 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Sep 2011 02:31:05 -0000

On 09/20/2011 08:42 PM, Martin Rex wrote:
> But that would also suggest that BEAST is not attacking the
> Cookie from the Server response, but instead the cookie from a
> client request.  (If the browser automatically inserts the cookie into
> arbitrary requests issued by the attackers malware, then this would
> mean that a serious Cross-Site-Request-Forgery problem in the browser
> is a prerequisite for the BEAST attack to succeed.

But such an attack would only need the cookie sent once 
client-to-server. A GET request which sends the secret cookie would work 
just fine. If there happened to be additional request(s) over that 
channel transmit the adaptive plaintext (constructed from the ciphertext 
block containing secret cookie data), would it actually be a requirement 
that they re-send the cookie then?

Even if there were CSRF restrictions on cookies, would they apply to GET 
and POST equally? If cookie restrictions applied to GET, how would work?

Sorry if I sound nonsensically hypothetical. I'm still trying to figure 
out what I've promised not to say vs. what I already knew. :-)

- Marsh