IETF Logo Mail Archive

Re: [TLS] Suspicious behaviour of TLS server implementations

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 21 September 2016 15:53 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 07F6912B4FE for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 08:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level:
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 V_oayubU28vg for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 08:53:41 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4A712B17C for <tls@ietf.org>; Wed, 21 Sep 2016 08:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1474473221; x=1506009221; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XmvNpM1tjYnvKX51+AEzDYwZxg1cNk0v2fD4reZurdM=; b=3uiqCXfg4tztAnQI5dEBL9SgeJwsZGqsMuZNuGrRJLNfw1R1GBACPN6t BJVX9LGZhAy6zkacEO7u/DWGAME4qA1vFdRo0+dPqv8ozi4kUNEVIpUtM gbF7HQmiyuTwvh8k9A+s8yayFWOT9vJfcCBxLi1rbA7vqyZ32hkoMahC8 kUN9Rnwl+c2CPEFObvUev/GHk3+zxk3Sn9ZW0o3t3MIDZU7vSizVbIvq/ cNCJ59S8JFvuC7uJ+/3XPJ7dePPd1a7ermeWouxYfse2gkf8xSgZBwhCJ +KaYonq6pJreIlGIBuLP94PmpwqLXBhmA4DdaJBwwXZeHjsYuYtxsTxIM g==;
X-IronPort-AV: E=Sophos;i="5.30,374,1470657600"; d="scan'208";a="106852287"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Sep 2016 03:53:34 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 22 Sep 2016 03:53:34 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 22 Sep 2016 03:53:33 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Andreas Walz <andreas.walz@hs-offenburg.de>, "martin.thomson@gmail.com" <martin.thomson@gmail.com>
Thread-Topic: [TLS] Suspicious behaviour of TLS server implementations
Thread-Index: AQHSCqXVmMdwMkXxhEmPq8Svce2cg6Bwf1GAgAhiD77//1nRAIAKl8wAgAABIICAACcigIABLwcE
Date: Wed, 21 Sep 2016 15:53:33 +0000
Message-ID: <1474473207998.35647@cs.auckland.ac.nz>
References: <57D2E218020000AC0011B17E@gwia2.rz.hs-offenburg.de> <20160909152901.9008C1A552@ld9781.wdf.sap.corp> <1473853106532.3256@cs.auckland.ac.nz> <57D96E34020000AC0011B73F@gwia2.rz.hs-offenburg.de> <57E25106020000AC0011BF3A@gwia2.rz.hs-offenburg.de> <CABkgnnX7X+21wjChxkW-uhd8WXAMyp5f1F74H5ja=1mui4POiQ@mail.gmail.com>, <57E272CB020000AC0011BF63@gwia2.rz.hs-offenburg.de>
In-Reply-To: <57E272CB020000AC0011BF63@gwia2.rz.hs-offenburg.de>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YtsEqzXHfKD6MY-y0EFAu7tkaV4>
Cc: "tls@ietf.org" <tls@ietf.org>
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 15:53:43 -0000

Andreas Walz <andreas.walz@hs-offenburg.de> writes:

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

And how many implementations are going to do this?  Consider the error-message
litmus test I proposed earlier, reasons for failing to connect to (say)
amazon.com:

  Error: Couldn't connect to Amazon because its certificate isn't valid.
  
  Error: Couldn't connect to Amazon because no suitable encryption was
         available.

  Error: Couldn't connect to Amazon because <explanation for 
         decoding_error alert>.

What would you put for the explanation for this case?  And if you say "decode
error" the user's response will be to switch to some less buggy software that
doesn't have problems connecting.

If you're writing a strict validating protocol parser than disconnecting in
this case is a valid response, but if it's software that will be used by
actual humans then failing a connect based on something like this makes no
sense.

Peter.

v2.23.0 | Report a Bug | By Email