Re: [TLS] Suspicious behaviour of TLS server implementations

Hubert Kario <hkario@redhat.com> Mon, 12 September 2016 16:56 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDAE120727 for <tls@ietfa.amsl.com>; Mon, 12 Sep 2016 09:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.41
X-Spam-Level:
X-Spam-Status: No, score=-8.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 80-EwNHlQS7K for <tls@ietfa.amsl.com>; Mon, 12 Sep 2016 09:56:15 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4065126579 for <tls@ietf.org>; Mon, 12 Sep 2016 09:56:14 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6F3EC201E9; Mon, 12 Sep 2016 16:56:14 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8CGuCgK012462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2016 12:56:13 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 12 Sep 2016 18:56:12 +0200
Message-ID: <2940153.fOUAj57mkm@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.7.2-201.fc24.x86_64; KDE/5.25.0; x86_64; ; )
In-Reply-To: <57D2E218020000AC0011B17E@gwia2.rz.hs-offenburg.de>
References: <57D2E218020000AC0011B17E@gwia2.rz.hs-offenburg.de>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3735381.8LQ5Ez7lj4"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 12 Sep 2016 16:56:14 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3MVpP_49zVA4ud4R9iGVU-g17sQ>
Subject: Re: [TLS] Suspicious behaviour of TLS server implementations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Sep 2016 16:56:18 -0000

On Friday, 9 September 2016 16:23:52 CEST Andreas Walz wrote:
> Dear all,
> 
> we are working on an approach/framework for testing TLS implementations
> (currently only servers, but clients are planned for the future as well).

are you aware of the tlsfuzzer framework?
https://github.com/tomato42/tlsfuzzer

> (2) In a ClientHello several server implementations don't ignore data
> following the extension list. That is, they somehow seem to ignore the
> length field of the extension list and simply consider everything following
> the list of compression methods as extensions. Aside from this certainly
> being a deviation from the specification, I was wondering whether a server
> should silently ignore data following the extension list (e.g. for the sake
> of upward compatibility) or (as one could infer from RFC5246, p. 42) send
> e.g. a "decode_error" alert.

It is explicit in RFC 3546, section 2.1:
https://tools.ietf.org/html/rfc3546#section-2.1

   A server that supports the extensions mechanism MUST accept only
   client hello messages in either the original or extended ClientHello
   format, and (as for all other messages) MUST check that the amount of
   data in the message precisely matches one of these formats; if not
   then it MUST send a fatal "decode_error" alert.  This overrides the
   "Forward compatibility note" in [TLS].

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic