IETF Logo Mail Archive

Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 23 September 2016 08:38 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 ABDFC12B694 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 01:38:47 -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 h9jXlntrJC8d for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 01:38:46 -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 49A1512B391 for <tls@ietf.org>; Fri, 23 Sep 2016 01:38:46 -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=1474619926; x=1506155926; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ngWXXu7ld6Xo6NqfOSdrILj3fjIMyNDiicFdCuXhliY=; b=rMftbitVPwSywDV4HacttPhKuH8qzNA/VFnLgN1BWANTE5AciNm/x58/ hPgTiUV5UAhL+RxtAjJxVlHg9ZTYSyEGoLrwM5LDYq5KgwnOI/v8B8yGZ Gz/pTgIoQCrOllOq5yErv63GrpkJDKkr5RsgCBtccqNj5ycCXNgS6EOV5 rjNYR4u7dRJMbRNhgsZXsuOJBL31Rmtf48zz+U7sHc9hywfLppJSLrARc swkaWMzM9oEjPSbMiiJaj6mubadPHGbMERK+uYmwjI/PArEGUFqVuapi8 bz4cQzSto/ZzYG1H1RlXWhwMHqAXaemoWROqzpaIZXuxO00h5UUwZhS6W A==;
X-IronPort-AV: E=Sophos;i="5.30,381,1470657600"; d="scan'208";a="107138432"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-c.UoA.auckland.ac.nz) ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Sep 2016 20:38:44 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 23 Sep 2016 20:38:44 +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; Fri, 23 Sep 2016 20:38:44 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Andreas Walz <andreas.walz@hs-offenburg.de>
Thread-Topic: Antw: Re: Antw: Re: [TLS] Suspicious behaviour of TLS server implementations
Thread-Index: AQHSCqXVmMdwMkXxhEmPq8Svce2cg6Bwf1GAgAhiD77//1nRAIAKl8wAgAABIICAACcigIABLwcE//9TpACAAYjZtv//sYmAAENt/2A=
Date: Fri, 23 Sep 2016 08:38:44 +0000
Message-ID: <1474619914890.15531@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> <1474473207998.35647@cs.auckland.ac.nz>, <57E2E068020000AC0011BFD4@gwia2.rz.hs-offenburg.de> <1474520407230.85774@cs.auckland.ac.nz>, <57E3E821020000AC0011C0DC@gwia2.rz.hs-offenburg.de>
In-Reply-To: <57E3E821020000AC0011C0DC@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/dB5nQCl2HjtV2FJPgU8EfdCD1pQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Antw: Re: Antw: Re: 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, 23 Sep 2016 08:38:48 -0000

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

>However, where would you draw the line between "I can't" and "I don't want
>to"?

It's one of those judgement-call things, I don't know if you can strictly
define it but as a rule of thumb I'd say that if you encounter it during
normal processing it's an I-can't problem while if you have to add special-
case checks to identify it and refuse to continue it's an I-don't-want-to
problem.

Using again the example of "Couldn't connect to Amazon because no suitable
encryption was available", if the server or client accidentally memset()s the
cipher suite block to 0xDEADBEEF then you've run into an I-can't-continue
problem, while if the length fields don't quite match up (the MUST NOT that
was cited at the start of this thread), something that you wouldn't even
notice unless you added special-case code to check for it, then it's an I-
don't-want-to-continue problem.

Peter.

v2.23.0 | Report a Bug | By Email