IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Fri, 23 September 2016 04:59 UTC

Return-Path: <martin.thomson@gmail.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 766BC12B493 for <tls@ietfa.amsl.com>; Thu, 22 Sep 2016 21:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 0hWoLiap8ksB for <tls@ietfa.amsl.com>; Thu, 22 Sep 2016 21:59:14 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CEE12B259 for <tls@ietf.org>; Thu, 22 Sep 2016 21:59:14 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id 38so47841252qte.1 for <tls@ietf.org>; Thu, 22 Sep 2016 21:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=kWlqRrarMWWxJf19E54FS5OzTgsU9OXv9AOhpMSntiU=; b=UBoExvcZeht4GzmTgjoD/LykmguuGXCAJCwsc12zL/j9ylLm47RTMMC6LXPU/iIBXG QH3XzUPP4f6K3iE1BFi+cmXQK/avDbEo2U+D/JBxdIPEX4isziwGxHg/sFkZDc9z97HL NLtwQnG0/8cY0ElA2VNq9XSWKwMpMtakkMWcHGr9wSIfg7y4hoswAa2WO4cNoEWN0LxC HRDv34Bfxu8W4a9OBgW2G/f+UEom0oqSfKl1O4hZMNFK/FRwMgZVYc59fokqfyL/MbFU rVG6iCFkaqd2CXlEvyDOfEI+6/U8zGbqVdJqxRV4/HmFJIZbXF1U4cpU0Cv1ItDKofNS SdKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=kWlqRrarMWWxJf19E54FS5OzTgsU9OXv9AOhpMSntiU=; b=a0x61WVR9OlPMmfJ7bFFjdrEOS9Q6m/DdD34Zy+rWvjfjoLM6gDQNk9Yh0miPmVz9w c09GgVZ5uZUvw6+tbm1baCu/UD8ioYaMeH0qOh9CHMdLnQ0RLbqWD8ay3jRlV0nxP7TX KN5YWGyJeGZv/e6InhblA81yzzi8qCuNtErYpRUgbZWNhZxlVS33UfL827IebCoRRqvV m2mRs/K7HTrRkekNcZ9GJO/GLajcAQIEnlnLCD/wuLxFEjIJaOQTKQfBZw7MDBvsWrQN pWixtlQVXCJpxY5jgfeXaM/3w9d0xNTiJ45LF+f8GRtgNSYdfJ6wggKGRCOiZ7IP9G6V y1pw==
X-Gm-Message-State: AA6/9RlRJWdnjUEF1ATe1IanauZRtTZ2p3Ul2fcccsXSt4OQWHaVpfWzRPK75r5n+BzF7J2zWcw+c/avwq05uQ==
X-Received: by 10.237.55.225 with SMTP id j88mr6020532qtb.131.1474606753577; Thu, 22 Sep 2016 21:59:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.146 with HTTP; Thu, 22 Sep 2016 21:59:12 -0700 (PDT)
In-Reply-To: <7E0E72C7-F4A4-41C9-BFA8-56EE51EEDC6D@dukhovni.org>
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> <7E0E72C7-F4A4-41C9-BFA8-56EE51EEDC6D@dukhovni.org>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 23 Sep 2016 14:59:12 +1000
Message-ID: <CABkgnnWknKo1zO+Q8gDawW-3R0Xue1jKoGijK58+ZxYdYoAYig@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/63eEvRxU9IAGJFRZam3xv5s_MUg>
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 04:59:16 -0000

On 23 September 2016 at 00:47, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>> I see your point here. However, where would you draw the line between "I can't" and "I don't want to"? Think of a cipher suites list with 3 bytes in a ClientHello. You can still find one cipher suite that could be ok to work with. However, how can you trust the first two bytes if you find that third byte telling you something's abnormal?
>
> The server tries that first cipher, if mutually supported, and if it
> works, it guessed right.  If the finished message from the server is
> valid, the client's handshake as seen by the server was presumably
> exactly what the client sent, so the client gets what it paid for...
>
> Servers don't have to be that forgiving, but it is a plausible approach.

Another view on this (web view):
https://annevankesteren.nl/2016/05/client-server

Why a server would tolerate rubbish and all the associated complexity,
when none of the users it cares about produce that sort of drivel is
beyond me.

v2.23.0 | Report a Bug | By Email