Re: [TLS] Deprecating SSLv3

Hubert Kario <hkario@redhat.com> Mon, 24 November 2014 12:19 UTC

Return-Path: <hkario@redhat.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 821AA1A1B36 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 04:19:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LYTvgWXuqZTy for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 04:19:00 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7571A1B1B for <tls@ietf.org>; Mon, 24 Nov 2014 04:19:00 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAOCIxVB006001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Nov 2014 07:18:59 -0500
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAOCIubU011513 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2014 07:18:58 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 24 Nov 2014 13:18:56 +0100
Message-ID: <1723354.osyxesJJiI@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.2 (Linux/3.16.7-200.fc20.x86_64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <1416816989.2533.7.camel@dhcp-2-127.brq.redhat.com>
References: <CABkgnnWw9zsrqQzHVU0vXLJM+HBK3QYxJAZE+0kgGkEQEzwS=w@mail.gmail.com> <20141122105659.GA26446@roeckx.be> <1416816989.2533.7.camel@dhcp-2-127.brq.redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b-u-2660CAVadsQ0UarcKUZLuaY
Subject: Re: [TLS] Deprecating SSLv3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 12:19:02 -0000

On Monday 24 November 2014 09:16:29 Nikos Mavrogiannopoulos wrote:
> On Sat, 2014-11-22 at 11:56 +0100, Kurt Roeckx wrote:
> > On Sat, Nov 22, 2014 at 05:40:27AM -0500, Nikos Mavrogiannopoulos wrote:
> > > That highlights the main difference
> > > with SSL 2.0 and rfc6176; there were no SSL 2.0-only services when it
> > > was published.> 
> > There still are SSLv2 only services on the internet.  Hubert Kario
> > last scan results
> > (https://lists.fedoraproject.org/pipermail/security/2014-October/001989.ht
> > ml) said:
> > Supported Protocols       Count     Percent
> > -------------------------+---------+-------
> > SSL2                      44800     10.2755
> > SSL2 Only                 5536      1.2698
> 
> I believe that this shows more about issues with the sample of the test
> rather than functioning SSLv2 only servers. Given that there is no way
> to connect to them anyway, they could be misconfigured non functional
> servers or honeypots.

This is actually a result of their intolerance to SSLv3 ClientHello with large 
amount of ciphers (or RC4 placed after 64th position in the list - the win 2k3 
TLS bug).

I've extended the scanner to try more fallbacks when testing (retry with a 
much smaller client hello) and the stats for this month look like this:

Supported Protocols       Count     Percent
-------------------------+---------+-------
SSL2                      38835     8.7934
SSL2 Only                 100       0.0226
SSL3                      204062    46.2059
SSL3 Only                 2195      0.497
SSL3 or TLS1 Only         108575    24.5847
SSL3 or lower Only        2293      0.5192
TLS1                      438481    99.2856
TLS1 Only                 46428     10.5127
TLS1 or lower Only        143729    32.5447
TLS1.1                    281522    63.7453
TLS1.1 Only               25        0.0057
TLS1.1 or up Only         443       0.1003
TLS1.2                    292517    66.2349
TLS1.2 Only               337       0.0763
TLS1.2, 1.0 but not 1.1   13585     3.0761

(the script managed to connect to about 100 more servers with even smaller
client hello, most of which accepted just v2-compatible client hello, but I've 
not implemented the scan for such intolerant servers yet)


I think we can safely banish a protocol that only 0.5% of servers require for
interoperability.



Regarding the SSLv3 MUST NOT: we have to remember that we're talking about a 
security protocol *used* for security. In such context SSLv3 should not be 
used.

Just like MD5 use for digital signatures is completely broken but is 
completely fine to use it as a checksum to verify proper download of a file 
over internet (people use CRC32 for that!), use of SSLv3 for interop is fine, 
but not if it is used for confidentiality.


+1 to MUST NOT
-- 
Regards,
Hubert Kario