Re: [TLS] Network middlebox corrupting TLS session resumes
David Benjamin <davidben@chromium.org> Fri, 09 February 2018 20:02 UTC
Return-Path: <davidben@google.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 637FA1242F7 for <tls@ietfa.amsl.com>; Fri, 9 Feb 2018 12:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 vbC7MHnSvMcH for <tls@ietfa.amsl.com>; Fri, 9 Feb 2018 12:02:24 -0800 (PST)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 B41BF120726 for <tls@ietf.org>; Fri, 9 Feb 2018 12:02:23 -0800 (PST)
Received: by mail-qt0-x235.google.com with SMTP id s27so12044073qts.4 for <tls@ietf.org>; Fri, 09 Feb 2018 12:02:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o1MypUa2DkpoJFE5lDTrm1mW8shTdX3Y04seUDf9NAw=; b=HOzOTINtrI+zLiYHCl9di5voAt7kFs55fy4EyL4rjrIXtYllcBusBRM6cVngzHH6Tk 1qnFonULNWeOMOxIZ7Zjol4uSxAz7kSDnoM+dxMQms7K8t+3ZkYDZso4H9uttYaRQwev ssQuUGckEWiZ0YH1HskMhTewixGaGDOUTTaKk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o1MypUa2DkpoJFE5lDTrm1mW8shTdX3Y04seUDf9NAw=; b=nC8eECEAqZW3oJ6D3iquwXa/jyHPYq6XRo1pr2Rc84F2bnWw0tNTiMwDPET8/FLL3D Ve2Q9IUcn6IdSgxVZViE5ks4Aw4oy/pm8vECDVF2/ib6d6WSKmJmdcOC03j3zGslH5uQ oUAoVktwyCg5+sAS1ztHSejEQDFrItJe2suWEuK/EELD6qyCXcxsQYJFcgm2t0HTerOD +2I+MQCHEMqk6w+s7XKtMXFSDzmhDyLhHcUI2H/wbpWQobhyUed+tPyn+bBI3nYF3dX8 S0YMrce8h6GHAU0lqqnpt2gUgIeyZszzeCCOsa/c7BDLK2v2084aEfWm0ihEMkfp2FSk ZOMg==
X-Gm-Message-State: APf1xPDsMnsiK/5fTkgSbWJHxNqIgn0qsCDu0vSm6YemWPOX14uPHz+9 nisv7skEI19QUF7/y994TTXMfEPWlt7l9WvZ2fiI
X-Google-Smtp-Source: AH8x224A18jhoF5dGR9xM2HPgX0c1JsLPcjEoLJQCGZupZpWgT8BlT4IcDXYz9sTL06w6JnrMF9+Mk33Uxv9a5uke4c=
X-Received: by 10.200.82.4 with SMTP id r4mr6415966qtn.75.1518206542721; Fri, 09 Feb 2018 12:02:22 -0800 (PST)
MIME-Version: 1.0
References: <20180209194524.1EDD5409B@ld9781.wdf.sap.corp>
In-Reply-To: <20180209194524.1EDD5409B@ld9781.wdf.sap.corp>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 09 Feb 2018 20:02:11 +0000
Message-ID: <CAF8qwaDv5JmGEXt4wC_g53_6ZzGR3kLzGA3EYgtBxJJnGbXF1Q@mail.gmail.com>
To: mrex@sap.com
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="f4f5e80c6c9cad34780564cd01f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mi8sj6dHnka0bJ90ojm3jfXAimQ>
Subject: Re: [TLS] Network middlebox corrupting TLS session resumes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 09 Feb 2018 20:02:26 -0000
I don't think we've observed this particular issue. We have observed middleboxes which, when they see a ServerHello they can't parse (such as the pre-draft-22 TLS 1.3 ServerHello), drop the ServerHello record on the floor, but pass through any following application_data records as-is. That's similar to your (2), though not quite as we didn't observe the record headers getting mangled. (TLS 1.3 did not include a CCS then, so I don't know if it would have mangled a CCS's record header.) I think if there's anything I've learned from this mess, it is that there are no bounds on how badly broken middleboxes are. We've seen middleboxes that break when we change our cipher suite preferences, because they suddenly start detecting our ClientHellos as SIP messages! (Yes, SIP. The text protocol.) David On Fri, Feb 9, 2018 at 2:45 PM Martin Rex <mrex@sap.com> wrote: > Hi, > > During the analysis of a recent customer support call, I determined > from a wireshark/network trace that the cause of unexpected failures > of TLS session resumption handshakes were caused by some broken > network middlebox, which allegedly was configured for "SSL inspection". > > I would like to know whether this problem is visible on the telemetry > data collections of any browser folks. > > > The network middlebox was seemingly *NOT* doing MitM-Attacks on the > connection, because the full handshakes with (remote 3rd-party) servers > succeeded just fine with genuine TLS server certs. > > > I noticed what looked like three subtly different kind of failures, > but only got the wireshark trace of one of these for analysis. > > TLS session resumes were corrupted by that "SSL inspecting" > network middlebox in the follwoing fashion: > > (1) non-critical (but negligent) corruption: > the protocol version number of the TLS record that carries > ServerHello was changed from (3,3) to (3,1) by that > network middlebox on TLS session resume attempts. > This change did not occur on TLS full handshakes, and the > genuine server sends (3,3) at the record layer both times. > > (2) fatal corruption: > the 5-byte TLS record header of the ChangeCipherSpec handshake > message was missing (removed from the network stream). and > the remaining content byte (01) is obviously not a valid start > of a new TLS record, causing our TLS client to abort the handshake > with a fatal TLS illegal_parameter alert (although it seems > that the appropriate alert would be decode_error). > > The genuine server was sending the TLS record with ServerHello > and the TLS record with ChangeCipherSpec in the same > TCP segment and IP datagram (152 bytes on the wire), > and the filtered response that went through that network > middlebox was just 147 bytes on the wire, with the > 5-byte TLS record header of ChangeCipherSpec missing. > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Network middlebox corrupting TLS session re… Martin Rex
- Re: [TLS] Network middlebox corrupting TLS sessio… David Benjamin