IETF Logo Mail Archive

Re: [TLS] Prohibiting SSL 3.0

Manuel Pégourié-Gonnard <mpg@polarssl.org> Wed, 29 October 2014 21:02 UTC

Return-Path: <mpg@polarssl.org>
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 E85671A1A2D for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 14:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level:
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 m-WC1IEFASkY for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 14:02:40 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2731A902B for <tls@ietf.org>; Wed, 29 Oct 2014 14:02:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=Ouz93Pl93VA3Kix+ZiAEfxkg9YShzdxqAcz2HIDhrGc=; b=E7uTUNzv/X8AloswGbialgIP8N3EZ9JnTMnyq/me53Ju/GERNlGhHmWCUhERZdGb+6lUaXTkAvJFcYHo6s5W19qlDk8ywEvXgyPpuiblLmNaR0bEr7gChMLp2yjynlbmtEHe9p9FUUG86a20SIyUPw7xUMCxp3u/GRJbHCfmM6E=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1XjaNq-0001uP-5K; Wed, 29 Oct 2014 22:02:31 +0100
Message-ID: <545155E2.2070203@polarssl.org>
Date: Wed, 29 Oct 2014 22:02:26 +0100
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: mrex@sap.com
References: <20141029204311.3E9611AF68@ld9781.wdf.sap.corp>
In-Reply-To: <20141029204311.3E9611AF68@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9vDpUm-qkRahidf9X6ZWKo2uK50
Cc: Florian Weimer <fw@deneb.enyo.de>, tls@ietf.org
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 21:02:42 -0000

On 29/10/2014 21:43, Martin Rex wrote:
> Manuel Pégourié-Gonnard wrote:
>> Unless I'm mistaken, there is no point for a client to send a SSLv2
>> compatible ClientHello unless the client is prepared to actually
>> negotiate SSLv2. If think if fair to say that client MUST NOT do that.
> 
> [...]            A number of broken servers screwed up the protocol
> version negotiation (which is performed EXCLUSIVELY through
> ClientHello.client_version) by choking on the record layer PDU encoding
> protocol_version when it differs from ClientHello.client_version.
> 
> Now the advantage of the SSL VERSION 2.0 CLIENT-HELLO is that it comes
> with only a single protocol version -- and it seems that less server
> implementors got that wrong.
> 
Ok, I didn't know, thanks for the info.

>> OTOH, accepting an SSLv2 ClientHello on the server makes sense even if the
>> server will never negotiate SSLv2. So I guess the MAY here is ok.
> 
> We already settled the SSLv2 ClientHello issues.
> 
> http://tools.ietf.org/html/rfc6176#section-3
> 
Yes, I'd forgotten that until Bodo mentioned it.

Manuel.

v2.23.0 | Report a Bug | By Email