Re: [TLS] Suspicious behaviour of TLS server implementations

Hubert Kario <hkario@redhat.com> Wed, 21 September 2016 10:30 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 1A42A12B1EC for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 03:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.238
X-Spam-Level:
X-Spam-Status: No, score=-9.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 zMQwNblEEAXA for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 03:30:57 -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 E010112B09E for <tls@ietf.org>; Wed, 21 Sep 2016 03:30:57 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 970CA31B335; Wed, 21 Sep 2016 10:30:57 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8LAUuAc019474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2016 06:30:57 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 21 Sep 2016 12:30:55 +0200
Message-ID: <6252067.4xmaPzFlG6@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.1 (Linux/4.7.3-200.fc24.x86_64; KDE/5.26.0; x86_64; ; )
In-Reply-To: <57E272CB020000AC0011BF63@gwia2.rz.hs-offenburg.de>
References: <57D2E218020000AC0011B17E@gwia2.rz.hs-offenburg.de> <CABkgnnX7X+21wjChxkW-uhd8WXAMyp5f1F74H5ja=1mui4POiQ@mail.gmail.com> <57E272CB020000AC0011BF63@gwia2.rz.hs-offenburg.de>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1691400.uHhCgGRYKR"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 21 Sep 2016 10:30:57 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zL6fl4l4JCSBE04LbJqnps5y00k>
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, 21 Sep 2016 10:31:00 -0000

On Wednesday, 21 September 2016 11:45:15 CEST Andreas Walz wrote:
> Ok, thanks. This is close to my sense of it. Actually, I wasn't aware of the
> fact that the TLS 1.3 draft now  explicitly addresses this in the
> Presentation Language section:
> 
>      "Peers which receive a message which cannot be parsed according to the
> syntax (e.g., have a length extending beyond the message boundary or
> contain an out-of-range
> length) MUST terminate the connection with a "decoding_error" alert."

technically TLSv1.2 also is like this, it's just not explicit. All the 
messages and structures must match their definitions exactly, that means any 
kind of trailing data is an encoding error and as such should cause connection 
abort.

at least in theory if implementation does not reject such malformed fields or 
messages, it may be possible to trick it into talking with a different 
protocol that just happens to be parseable as TLS. Multiple checks on self-
consistency of messages make that unlikely.

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