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

Martin Rex <mrex@sap.com> Mon, 19 September 2011 18:55 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 15AFC21F8CE4 for <tls@ietfa.amsl.com>; Mon, 19 Sep 2011 11:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.728
X-Spam-Level:
X-Spam-Status: No, score=-9.728 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, 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 St9b00qquAcl for <tls@ietfa.amsl.com>; Mon, 19 Sep 2011 11:55:25 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5B68321F8CE3 for <tls@ietf.org>; Mon, 19 Sep 2011 11:55:25 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8JIviBe027941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Sep 2011 20:57:45 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109191857.p8JIvik9021961@fs4113.wdf.sap.corp>
To: tim@dierks.org (Tim Dierks)
Date: Mon, 19 Sep 2011 20:57:44 +0200 (MEST)
In-Reply-To: <CALpzJPqJ3WCPZ-542om9D2uRNmQ97kxWTJDvJHResjsRdiK-Eg@mail.gmail.com> from "Tim Dierks" at Sep 10, 11 12:41:11 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] 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: Mon, 19 Sep 2011 18:55:27 -0000

Tim Dierks wrote:
> 
> Does anyone have any ideas what Rizzo may be announcing @ ekoparty?
> 
> http://www.ekoparty.org/2011/juliano-rizzo.php
> 
> BEAST: Surprising crypto attack against HTTPS

The first details seem to be leaking:

http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-model-ssl-allows-theft-encrypted-cookies-091611


It seems to be a Man-in-the-Browser attack on SSLv3/TLSv1.0 confidentiality
of ciphers suites with a block cipher in CBC-mode, similar to the original
attack here:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf

The original SSL&TLS protocol was never designed to protect data that
is multiplexed onto a single TLS connection to be protected from each other,
because the traffic-keys are created once per connection.

SSL VPNs, which are an abuse of the SSL&TLS technology clearly beyond
its original design scope, are likely much more difficult to fix than
Web Browsers.  The explicit IVs introduced by TLSv1.1 for block ciphers
with CBC-mode might be an acceptable mitigation, but it is not a clean
solution (because it does not address the underlying design, where the
same symmetric crypto key is reused for data controlled by the attacker.
 
A Web-Browser with a reasonable design of security zones could try to
ensure that requests originating from different security domains
never re-use network sockets from other domains.  Resuming TLS sessions
from other domains is not a problem, because traffic encryption and
mac keys are regenerated for each connection, so you don't need more
TLS handshakes, only more sockets whose scope for reuse/multiplex
is limited.

TLS cipher suites with stream ciphers (like rc4-128) or with block ciphers
abused as stream ciphers (AES GCM or CCM, i.e. the AEAD cipher suites)
are probably not as much affected, because they do not exactly
"reuse" the exact same secret keys for data of the victim and data
of the attacker, I assume.


-Martin