[TLS] Suspicious behaviour of TLS server implementations

"Andreas Walz" <andreas.walz@hs-offenburg.de> Fri, 09 September 2016 14:23 UTC

Return-Path: <andreas.walz@hs-offenburg.de>
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 328C312B1B9 for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 07:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Level:
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de
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 V2JAmfHYl-3R for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 07:23:57 -0700 (PDT)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E695312B166 for <tls@ietf.org>; Fri, 9 Sep 2016 07:23:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id 3FA29DCE06E for <tls@ietf.org>; Fri, 9 Sep 2016 16:23:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:subject:subject:from :from:date:date:x-mailer:message-id:received:received:received; s=default; t=1473431034; x=1474295035; bh=kUpRX7scRJrxvKTtzjr5/ 2ukoIMsBYa2cZEHHWxFLXk=; b=N1npGKVddPhfTc4hUHN6edRCtaRYVb/ZT7yq5 zDwA/2sKQPrINsWEDXBeN/K+HEGs3JbtIi+4itoFrOK2FtNSzHvK+61mBnlU2you IDD8mcenA7mST9ZmLGU7/lm31H669JvK7Ad6TWbXiC+poKhGsl0c4A4oNSQMx/tX 27l1DA=
X-Virus-Scanned: amavisd-new at hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 858YIs0ExmwK for <tls@ietf.org>; Fri, 9 Sep 2016 16:23:54 +0200 (CEST)
Received: from gwia2.rz.hs-offenburg.de (stud.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id AE00CDCE069 for <tls@ietf.org>; Fri, 9 Sep 2016 16:23:54 +0200 (CEST)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Fri, 09 Sep 2016 16:23:54 +0200
Message-Id: <57D2E218020000AC0011B17E@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1
Date: Fri, 09 Sep 2016 16:23:52 +0200
From: "Andreas Walz" <andreas.walz@hs-offenburg.de>
To: <tls@ietf.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC0F648E8.0__="
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/T88SgCCL6OxtLrm55y3q_RcU10I>
Subject: [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: Fri, 09 Sep 2016 14:23:59 -0000

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). While running our tests against a bunch of different TLS (server) implementations, we found several types of suspicious behaviour (see below). As the TLS specification left me with doubts on what the correct behaviour should be, I'd like to raise this questions here (please let me know if this is not the appropriate place or this has been answered before).

(1) Several server implementations seem to ignore the list of proposed compression methods in a ClientHello and simply select null compression even if that has not been in the ClientHello's list. The specification is rather clear that null compression MUST be part of the list. However, I'm not aware of any clear statement about what a compliant server should do in case it receives a ClientHello without null compression. My best guess would have been that in such cases the server should abort the handshake (at least if it does not support whatever the client proposed).

(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.

(3) If a ClientHello contains multiple extensions of the same type, several server implementations proceed with the handshake (even if they parse these specific extensions). The specification again is clear that "there MUST NOT be more than one extension of the same type". However, what should a server do in case there are? Again, my guess would be that it should abort the handshake. Should this also be the case for extensions that a server simply ignores (as it e.g. doesn't know them)?

Thank you very much.

Cheers,
Andi