[TLS] ClientHello and record layer version interop
mrex@sap.com (Martin Rex) Sat, 24 January 2015 07:49 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 2D6F51A0143 for <tls@ietfa.amsl.com>; Fri, 23 Jan 2015 23:49:11 -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 Kl2ZbxfnBEZZ for <tls@ietfa.amsl.com>; Fri, 23 Jan 2015 23:49:10 -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 E2A101A0130 for <tls@ietf.org>; Fri, 23 Jan 2015 23:49:09 -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 EBCF13A132 for <tls@ietf.org>; Sat, 24 Jan 2015 08:49:07 +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 A2A7E41F64 for <tls@ietf.org>; Sat, 24 Jan 2015 08:49:07 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9928B1B0D1; Sat, 24 Jan 2015 08:49:07 +0100 (CET)
To: tls@ietf.org
Date: Sat, 24 Jan 2015 08:49:07 +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: <20150124074907.9928B1B0D1@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hpOL5RfpmztylzlNpWQu4smP7Xw>
Subject: [TLS] ClientHello and record layer version interop
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: Sat, 24 Jan 2015 07:49:11 -0000
I'm seeing an increase in customer messages about newly appearing TLS interop problems. There seem to be TLSv1.0 servers who threw out the baby with the bathtub and started rejecting ClientHellos with client_version = (3,1) that come in SSLv3 records. One of the servers identifies itself as "Sun-ONE-Web-Server/6.1" and exhibits the following crazy behaviour: SSLv2-record with SSLv2 CLIENT-HELLO offering TLSv1.0: TLSv1.0 ServerHello *> SSLv3-record with ClientHello offering TLSv1.0 ==> Handshake failure TLSv1.0-record with ClientHello offering TLSv1.0 ==> TLSv1.0 ServerHello TLSv1.2-record with ClientHello offering TLSv1.2 ==> TLSv1.0 ServerHello How widespread is that disease? Does anyone know which kind of servers/software exhibit this flaw and how many of them exist? Server configuration changes (disabling SSLv3) in "response" to Poodle seem to get applied slowly to production servers. -Martin
- [TLS] ClientHello and record layer version interop Martin Rex
- Re: [TLS] ClientHello and record layer version in… Nikos Mavrogiannopoulos