Re: [TLS] Thoughts on Version Intolerance

Hubert Kario <hkario@redhat.com> Thu, 21 July 2016 12:35 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 B681112DA66 for <tls@ietfa.amsl.com>; Thu, 21 Jul 2016 05:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.209
X-Spam-Level:
X-Spam-Status: No, score=-8.209 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=-1.287, 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 4Aeo7YT2HoGs for <tls@ietfa.amsl.com>; Thu, 21 Jul 2016 05:35:44 -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 2BD0C12D65F for <tls@ietf.org>; Thu, 21 Jul 2016 05:35:39 -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 C10363B720; Thu, 21 Jul 2016 12:35:38 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6LCZbBs003133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2016 08:35:38 -0400
From: Hubert Kario <hkario@redhat.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Thu, 21 Jul 2016 14:35:32 +0200
Message-ID: <3605304.gtMSxrymAa@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.23.0; x86_64; ; )
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CCF7C1@uxcn10-5.UoA.auckland.ac.nz>
References: <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4CCF7C1@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3368602.uRosMLnluf"; 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.30]); Thu, 21 Jul 2016 12:35:38 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JQrOkCDI-B9-1_LiezUon3R-H0I>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Thoughts on Version Intolerance
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: Thu, 21 Jul 2016 12:35:48 -0000

On Thursday, 21 July 2016 12:25:48 CEST Peter Gutmann wrote:
> Martin Rex <mrex@sap.com>; writes:
> >Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour.
> >X.509v3 certificates can theoretically include CAT MPEGs and amount to
> >megabytes.
> 
> We really need a TLS scanner that does this just to see what happens.  When
> I created that cat-MPEG cert, I fed it to both MSIE and Netscape.  Both
> happily accepted it, and then essentially become nonfunctional because
> although they saw nothing wrong with accepting a cert of that size, they
> couldn't actually deal with it.  In Netscape's case I had to delete the .db
> file before it could be used again.  I wouldn't be surprised if you can
> quite effectively DoS assorted TLS implementations with stuff like this.

if you have such certificate, you can use this script from tlsfuzzer to test 
if server won't explode by processing it:
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-rsa-sigs-on-certificate-verify.py

(I haven't tested if it actually can send a 2MiB large certificate, but in 
general there are no limits in tlslite-ng or tlsfuzzer, so it should work just 
fine, bugreports welcome if that is not the case).

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