Re: [TLS] Suspicious behaviour of TLS server implementations

Hubert Kario <hkario@redhat.com> Wed, 14 September 2016 14:42 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 BADE912BC92 for <tls@ietfa.amsl.com>; Wed, 14 Sep 2016 07:42:42 -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 teAXO8Uu1uIi for <tls@ietfa.amsl.com>; Wed, 14 Sep 2016 07:42:39 -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 51D9812BCFF for <tls@ietf.org>; Wed, 14 Sep 2016 07:02:50 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 2968F14FA5F; Wed, 14 Sep 2016 14:02:50 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8EE2mac018877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2016 10:02:49 -0400
From: Hubert Kario <hkario@redhat.com>
To: Andreas Walz <andreas.walz@hs-offenburg.de>, tls@ietf.org
Date: Wed, 14 Sep 2016 16:02:42 +0200
Message-ID: <10462720.prT61rZgUA@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.7.2-201.fc24.x86_64; KDE/5.26.0; x86_64; ; )
In-Reply-To: <57D96E34020000AC0011B73F@gwia2.rz.hs-offenburg.de>
References: <57D2E218020000AC0011B17E@gwia2.rz.hs-offenburg.de> <1473853106532.3256@cs.auckland.ac.nz> <57D96E34020000AC0011B73F@gwia2.rz.hs-offenburg.de>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2790671.roLu2tjnOZ"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 14 Sep 2016 14:02:50 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/M-_IscpTfYbycSqUm9wA0RgpSfE>
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: Wed, 14 Sep 2016 14:42:43 -0000

On Wednesday, 14 September 2016 15:35:16 CEST Andreas Walz wrote:
> Hi,
> 
> >>> Hubert Kario <hkario@redhat.com>; 09/12/16 6:56 PM >>>
> > 
> > are you aware of the tlsfuzzer framework?
> > https://github.com/tomato42/tlsfuzzer
> 
> @Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the
> repository before and I skimmed through the code. However, I didn't run the
> code and I don't know details about the way it is generating input. Is
> there some paper or presentation about it?

there are presentation slides in the docs/ directory

Decision which messages are to be generated is done using scenarios that 
describe conversations between client and server. See in scripts/ for them; a 
simple example is scripts/test-conversation.py while an example of negative 
test would be scripts/test-early-application-data.py

in tlsfuzzer/messages.py is the code that generates the messages, client hello 
is here:
https://github.com/tomato42/tlsfuzzer/blob/master/tlsfuzzer/messages.py#L306

Example of a test case you were asking about (the one with data extending past 
extensions) would be scripts/test-truncating-of-client-hello.py

The messages themselves are generated through a combination of sensible 
defaults and "guessing" expected values by inspecting already exchanged 
messages (think TLS state machine that explicitly has support for any state 
transitions).

In general, it allows you to both negotiate connections and send arbitrary 
messages (through changing their order, modifying them pre or post encryption, 
or sending raw values). In particular, it does support renegotiation despite 
the the fact that the underlying tls library doesn't.
-- 
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