Re: [TLS] Prohibiting SSL 3.0

mrex@sap.com (Martin Rex) Fri, 31 October 2014 01:03 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3711A8A28 for <tls@ietfa.amsl.com>; Thu, 30 Oct 2014 18:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E71GE7tRG24 for <tls@ietfa.amsl.com>; Thu, 30 Oct 2014 18:03:17 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691B71A8A48 for <tls@ietf.org>; Thu, 30 Oct 2014 18:03:12 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 4357754B08; Fri, 31 Oct 2014 02:03:10 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3A42442DC8; Fri, 31 Oct 2014 02:03:10 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2F9631AF6E; Fri, 31 Oct 2014 02:03:10 +0100 (CET)
In-Reply-To: <BLU177-W4981235CC3AA2325B8CC01C39F0@phx.gbl>
To: Yuhong Bao <yuhongbao_386@hotmail.com>
Date: Fri, 31 Oct 2014 02:03:10 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141031010310.2F9631AF6E@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UfTiMw5zSTl9GT5QM_MTGpLoBjA
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Prohibiting SSL 3.0
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 31 Oct 2014 01:03:20 -0000

Yuhong Bao wrote:
> I hope that a Internet-Draft prohibiting SSL 3.0 will be next.
> Maybe make an exception for things like browser download sites
> (it is easy to enable TLS 1.0 in IE6 but for these kind of sites
>  it is probably not worth the effort).

No, why?

This may be unknown to you, but SSLv3 is still perfectly safe to use
within its stated design goals.  Even within the Design Goals stated
for TLSv1.2!

Remember the TLSv1.2 product warning label:

  https://tools.ietf.org/html/rfc5246#page-16

   Any protocol designed for use over TLS must be carefully designed to
   deal with all possible attacks against it.  As a practical matter,
   this means that the protocol designer must be aware of what security
   properties TLS does and does not provide and cannot safely rely on
   the latter.

And recap the stated properties of the protocol:

  https://tools.ietf.org/html/rfc5246#appendix-F

  https://tools.ietf.org/html/rfc5246#appendix-F.2


TLS up to and including TLSv1.2 similar to its predecessor SSLv3
*NEVER* *EVER* promised to provide any protection against attacks
such as BEAST, CRIME, Poodle or the RC4-attacks.  All of these
attacks have the prerequiste of almost full control over the behaviour
of an endpoint.  Remove the control-over-the-endpoint from these
attack scenarios, and none of these attacks will be possible anymore.

Btw. when I just did online-banking a few hours ago, I noticed
a longer numeric "token" variable at the end of the URL that changed
with every mouseclick and navigation on the page.  Seems like someone
properly realized that the root of all evil is applications on top
of TLS using disclosing authentication schemes.



Poodle targets the final block of CBC padding, and has an "efficiency"
of recovering 1 byte of plaintext per 256 TLS sessions during which
the server encounters 255 MAC errors on the app data (something that
normally occurs one per week or less).
As such Poodle looks like an extremely "noisy" attack to me.


The plaintext pattern that Poodle is trying to achieve for the final
CBC block of an SSL record looks like this:

       64-bit blockcipher (DES, 3DES, IDEA)
                 XX XX XX XX XX XX XX 07
      128-bit blockcipher (AES, CAMELIA, SEED, CAST):
                 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 0F


Does anyone remeber Serge Vaudenay's original problem as a result from
the incorrect ordering of pad and mac in the SSL GenericBlockCipher
PDU processing, i.e.
the use of the unsafe "mac + pad + encrypt"
rather than a safe "pad + mac + encrypt":

       http://lasec.epfl.ch/php_code/publications/search.php?ref=Vau01
       http://lasec.epfl.ch/php_code/publications/search.php?ref=Vau02a

Didn't the the plaintext pattern that Vaudenay suggested in trying to
achieve for the final CBC block look like this:

       64-bit blockcipher (DES, 3DES, IDEA)
                 XX XX XX XX XX XX XX 00
      128-bit blockcipher (AES, CAMELIA, SEED, CAST):
                 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 00

I can not see much of a difference between original Vaudenay and Poodle,
and the efficieny is exactly the same: plaintext recovery of 1 byte per 256
TLS sessions.


Just that the TLS WG actually *NEVER* followed Vaudenay's advice
by moving to "pad + mac + encrypt", which would have reliably
thwarted Lucky thirteen and Poodle.

If there was ever reason to "Panic", this was back in 2001 when the
problem was first described.  IMHO.


-Martin