Re: [TLS] Prohibiting SSL 3.0

Hubert Kario <hkario@redhat.com> Wed, 29 October 2014 13:26 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 AD6541A00B9 for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 06:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 6t747sIPJ8HD for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 06:25:53 -0700 (PDT)
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 370AC1A00B5 for <tls@ietf.org>; Wed, 29 Oct 2014 06:25:53 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9TDP6cW015695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Oct 2014 09:25:06 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9TDP3ep012258 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 09:25:05 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 29 Oct 2014 14:25:02 +0100
Message-ID: <3210934.mtebjy4dFk@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <20141029111859.GA29912@LK-Perkele-VII>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB0B2@uxcn10-5.UoA.auckland.ac.nz> <20141029111859.GA29912@LK-Perkele-VII>
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.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tMjpf535cokpOrM_XC_T4uZkOk0
Subject: Re: [TLS] Prohibiting SSL 3.0
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: Wed, 29 Oct 2014 13:26:02 -0000

On Wednesday 29 October 2014 13:18:59 Ilari Liusvaara wrote:
> On Wed, Oct 29, 2014 at 10:51:39AM +0000, Peter Gutmann wrote:
> > Hubert Kario <hkario@redhat.com> writes:
> > >Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2
> > >compatible client hello with server support being stated as MAY.
> > 
> > Good grief, it's still allowing SSLv2 after nearly *twenty years*?  This
> > should have been MUST NOT for both client and server years ago, and at an
> > absolute minimum SHOULD NOT SSLv3 as well.
> 
> Also, one can't even use SSLv2 compatible ClientHello for TLS v1.3 because
> TLS v1.3 backward compatiblity mode requires extensions, and SSLv2 can't
> pass those.
> 
> Checking SSL pulse (which I think scans global Internet, not all kinds of
> odd internal sites nobody cares about) gives ~19% for SSLv2 (this isn't
> the compatiblity hello, this the whole protocol!), which is scary.

In my scans (a bit bigger set than SSL Pulse), I see over 1% of servers that 
don't support anything but SSLv2!

I also see a bit smaller set of SSLv2 protocol compatible servers, at ~10%. 
The difference may come from the fact that my test is counting only those that 
have SSLv2 ciphers configured, while Ivan Ristic scanner detects SSLv2 
enabled, but no ciphers set, I'd guess it may count those towards the ~19% 
total.
-- 
Regards,
Hubert Kario