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
- [TLS] Prohibiting SSL 3.0 Yuhong Bao
- Re: [TLS] Prohibiting SSL 3.0 Martin Thomson
- Re: [TLS] Prohibiting SSL 3.0 Florian Weimer
- Re: [TLS] Prohibiting SSL 3.0 Hubert Kario
- Re: [TLS] Prohibiting SSL 3.0 Peter Gutmann
- Re: [TLS] Prohibiting SSL 3.0 Florian Weimer
- Re: [TLS] Prohibiting SSL 3.0 Ilari Liusvaara
- Re: [TLS] Prohibiting SSL 3.0 Manuel Pégourié-Gonnard
- Re: [TLS] Prohibiting SSL 3.0 Bodo Moeller
- Re: [TLS] Prohibiting SSL 3.0 Eric Rescorla
- Re: [TLS] Prohibiting SSL 3.0 Manuel Pégourié-Gonnard
- Re: [TLS] Prohibiting SSL 3.0 Salz, Rich
- Re: [TLS] Prohibiting SSL 3.0 Hubert Kario
- Re: [TLS] Prohibiting SSL 3.0 Yoav Nir
- Re: [TLS] Prohibiting SSL 3.0 Hubert Kario
- Re: [TLS] Prohibiting SSL 3.0 Yoav Nir
- Re: [TLS] Prohibiting SSL 3.0 Hubert Kario
- Re: [TLS] Prohibiting SSL 3.0 Martin Rex
- Re: [TLS] Prohibiting SSL 3.0 Manuel Pégourié-Gonnard
- Re: [TLS] Prohibiting SSL 3.0 Martin Rex
- Re: [TLS] Prohibiting SSL 3.0 Watson Ladd
- Re: [TLS] Prohibiting SSL 3.0 Martin Rex
- Re: [TLS] Prohibiting SSL 3.0 Geoffrey Keating
- Re: [TLS] Prohibiting SSL 3.0 Watson Ladd
- Re: [TLS] Prohibiting SSL 3.0 Bodo Moeller
- Re: [TLS] Prohibiting SSL 3.0 Watson Ladd
- Re: [TLS] Prohibiting SSL 3.0 Bodo Moeller
- Re: [TLS] Prohibiting SSL 3.0 Watson Ladd
- Re: [TLS] Prohibiting SSL 3.0 Sean Turner
- Re: [TLS] Prohibiting SSL 3.0 Joseph Salowey
- Re: [TLS] Prohibiting SSL 3.0 Yuhong Bao
- Re: [TLS] Prohibiting SSL 3.0 Yoav Nir
- Re: [TLS] Prohibiting SSL 3.0 Dave Garrett
- Re: [TLS] Prohibiting SSL 3.0 Jeffrey Walton
- Re: [TLS] Prohibiting SSL 3.0 Yoav Nir