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

Martin Rex <mrex@sap.com> Wed, 21 September 2011 02:59 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 539C321F8CB6 for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 19:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.05
X-Spam-Level:
X-Spam-Status: No, score=-10.05 tagged_above=-999 required=5 tests=[AWL=0.199, 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 6VX1IHUo5Y21 for <tls@ietfa.amsl.com>; Tue, 20 Sep 2011 19:59:29 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2157C21F8CB3 for <tls@ietf.org>; Tue, 20 Sep 2011 19:59:28 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8L31kiV013667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2011 05:01:46 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109210301.p8L31jLK013412@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Wed, 21 Sep 2011 05:01:45 +0200 (MEST)
In-Reply-To: <4E794CF9.5080408@extendedsubset.com> from "Marsh Ray" at Sep 20, 11 09:33:29 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: asteingruebl@paypal-inc.com, geoffk@geoffk.org, tls@ietf.org
Subject: Re: [TLS] Rizzo claims implementation attach, should be interesting
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: Wed, 21 Sep 2011 02:59:30 -0000

Marsh Ray wrote:
> 
> 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

That is a vital prerequisite.  The Javascript of the BEAST trojan
would have to be dribbling out SSL records based on the very same
TLS Connection status (and watch that encrypted network traffic
to learn the last Cipherblock in the SSL record that will be used
as IV to the next SSL record in SSLv3&TLSv1.0 in order to fabricate
the next guess for the plaintext (->adaptively chosen plaintext).

But in order for the attack to succeed so fast in guessing
(10 minutes for the PayPal cookie) I would expect that there needs
to be a small block size (3DES-EDE-CBC) plus a fairly low entropy
in that Cookie.   A sensible cookie would be base64-encoded and
contain at least 128-bit strong random (meaning up to 48 bits of
entropy per cipher block and 2-3 blocks to recover).  Much less guessing
if it uses an unsafe low-entropy cookie or a very inefficient encoding
(but more blocks to guess).


> (constructed from the ciphertext 
> block containing secret cookie data), would it actually be a requirement 
> that they re-send the cookie then?

No, one cookie is sufficient if the connection does not abort during
the attack.  But spreading the attack over multiple successive or
parallel requests (one for each cipher block, each request with its own
encryption keys and encrypted cookie) and combinding the results should work.

> 
> Even if there were CSRF restrictions on cookies, would they apply to GET 
> and POST equally?

Since the client needs to send a significant number of small SSL records
with stuff that will look like junk to the Server.  The server might be
more patiently with a (dribbling) POST than a GET in this respect.


-Martin