Re: [TLS] Deprecating SSLv3
mrex@sap.com (Martin Rex) Mon, 24 November 2014 18:30 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 5CCD21A0673 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 10:30:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 joElNDBBsEGf for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 10:29:57 -0800 (PST)
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 884DE1A872B for <tls@ietf.org>; Mon, 24 Nov 2014 10:29:57 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 5DA713A126; Mon, 24 Nov 2014 19:29:53 +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 A703A41CB7; Mon, 24 Nov 2014 19:29:53 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9C8251B004; Mon, 24 Nov 2014 19:29:53 +0100 (CET)
In-Reply-To: <1572947.5ky0fL2FGE@pintsize.usersys.redhat.com>
To: Hubert Kario <hkario@redhat.com>
Date: Mon, 24 Nov 2014 19:29:53 +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: <20141124182953.9C8251B004@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/I5ULbPJIyRnu2vCwzO5-UeGagOs
Cc: tls@ietf.org
Subject: Re: [TLS] Deprecating SSLv3
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: Mon, 24 Nov 2014 18:30:06 -0000
Hubert Kario wrote: > On Monday 24 November 2014 18:06:22 Martin Rex wrote: >> Hubert Kario wrote: >> > Anyway, you should file a complaint to the manufacturer that it haven't >> > addressed the POODLE vulnerability in their product (or that it doesn't >> > implement advertised protocols properly). >> >> Poodle is a *PURE* Web-Browser and client problem. >> Servers are not vulnerable to Poodle, and this site *REQUIRES* >> TLS client certs for authentication. >> >> Disabling SSLv3 on servers is only a practical mitigation against >> the stupid "downgrade dance" that so many browsers perform. >> It's difficult for me to understand how someone could implement >> the downgrade dance and *NOT* provide a switch to turn it off after >> addressing the rfc5746 tls renegotiation issue. > > To exploit POODLE you need fallback dance *or* support just SSLv3. It's not > limited to web browsers (and there are some clients that do fallback and are > not browsers, e.g. curl). > > Also, are you saying that an *automated* system won't retry on connection > failure? _very_ few, if any. Exactly none of ours. > > We're talking about average of 128 failed requests per byte decrypted, > even if we fail just every first connection on a system that queries > remote server every 5 minutes 24/7 that will require just a month to > decrypt 16 byte password/authentication string. There have been far > more dedicated and longer attacks in the wild. You may have not understood the Problem. It's a plaintext recovery of 1 byte per 256 requests on average and you can only recover the last byte of any CBC ciphertext block, not the other 7 (3DES/IDEA) or other 15(AES). And you will need a high probability that the secret you want to recover is at a static position of the requests that you're attacking. A poodle attack will be pretty "noisy" on the server, so for many usage scenarios, this will be sufficient deterrent, just like many apartments have no bullet-proof windows and many doors have not pick-proof locks. And you could add random URL-parameters or other insert additional header fields before the credentials if you absolutely want to keep doing disclosing authentication rather than simply switching to using TLS client certs for the requests. > > SSLv3 has known security problems, > more issues may be discovered in the future. TLS has long known weaknesses and well-documented limitations. When you remain within the safe usage areas, even SSLv3 is still secure. Really, what we should worry about is the current usage scenarios where even TLSv1.2 can not provide protection, and one of these is Cross-Site-Request-Forgery as currently offered by Web-Browsers. > > So while use of certificates may mitigate this problem, we may not > ever know if it mitigates all problems SSLv3 has. I'm not expecting any. Honestly. > > For example, issues like 3-shake won't be fixed in SSLv3. I never offered TLS renegotiation to applications in our implementation, and I hardwired it to a fatal alert on the server in 2010. Conservative designs don't have to care about 3-shake. There are several more implementation pitfalls hidden in the TLS renegotiation design. > > In my opinion, continued use of it for security-critical applications > qualifies for gross negligence. Nope. Continued offering of SSLv3-only is the problem here. The original SSLv3 and TLS design protects the security parameters of the TLS handshake, so a TLSv1.0 capable client that does not send ClientHello.client_version = { 3,1 } (or can be coerced to not signale TLSv1.0 support by a network-based attacker) is the problem. > > Do we really need the repeat of the MD5 signatures story or can we learn on > our own (as in industry) mistakes? It would already be an improvement if the TLS WG stopped (mostly) ignoring problems (such as Vaudenay's), or didn't add new problems (such as making (rsa,md5) a mandatory-to-implement TLSv1.2 signature algorithm). -Martin
- [TLS] Deprecating SSLv3 Martin Thomson
- Re: [TLS] Deprecating SSLv3 Matt Caswell
- Re: [TLS] Deprecating SSLv3 Martin Thomson
- Re: [TLS] Deprecating SSLv3 Manuel Pégourié-Gonnard
- Re: [TLS] Deprecating SSLv3 Martin Thomson
- Re: [TLS] Deprecating SSLv3 Stephen Checkoway
- Re: [TLS] Deprecating SSLv3 Nikos Mavrogiannopoulos
- Re: [TLS] Deprecating SSLv3 Alfredo Pironti
- Re: [TLS] Deprecating SSLv3 Nikos Mavrogiannopoulos
- Re: [TLS] Deprecating SSLv3 Ronald del Rosario
- Re: [TLS] Deprecating SSLv3 Alfredo Pironti
- Re: [TLS] Deprecating SSLv3 Martin Thomson
- Re: [TLS] Deprecating SSLv3 Nikos Mavrogiannopoulos
- Re: [TLS] Deprecating SSLv3 Kurt Roeckx
- Re: [TLS] Deprecating SSLv3 Salz, Rich
- Re: [TLS] Deprecating SSLv3 Nikos Mavrogiannopoulos
- Re: [TLS] Deprecating SSLv3 Hubert Kario
- Re: [TLS] Deprecating SSLv3 Martin Rex
- Re: [TLS] Deprecating SSLv3 Hubert Kario
- Re: [TLS] Deprecating SSLv3 Martin Rex
- Re: [TLS] Deprecating SSLv3 Kurt Roeckx
- Re: [TLS] Deprecating SSLv3 Hubert Kario
- Re: [TLS] Deprecating SSLv3 Martin Rex
- Re: [TLS] Deprecating SSLv3 Hubert Kario
- Re: [TLS] Deprecating SSLv3 Manuel Pégourié-Gonnard
- Re: [TLS] Deprecating SSLv3 Watson Ladd
- Re: [TLS] Deprecating SSLv3 Nico Williams
- Re: [TLS] Deprecating SSLv3 Yoav Nir
- Re: [TLS] Deprecating SSLv3 Bill Frantz
- Re: [TLS] Deprecating SSLv3 Nico Williams
- Re: [TLS] Deprecating SSLv3 Henrick Hellström
- Re: [TLS] Deprecating SSLv3 Yuhong Bao
- Re: [TLS] Deprecating SSLv3 Hubert Kario
- Re: [TLS] Deprecating SSLv3 Martin Rex