[TLS] Network middlebox corrupting TLS session resumes
mrex@sap.com (Martin Rex) Fri, 09 February 2018 19:45 UTC
Return-Path: <mrex@sap.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 DD8DD12708C for <tls@ietfa.amsl.com>; Fri, 9 Feb 2018 11:45:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 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, 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 xQoTG6HdeNFB for <tls@ietfa.amsl.com>; Fri, 9 Feb 2018 11:45:26 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CCA1242F7 for <tls@ietf.org>; Fri, 9 Feb 2018 11:45:26 -0800 (PST)
Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3zdQX420fwzR0 for <tls@ietf.org>; Fri, 9 Feb 2018 20:45:24 +0100 (CET)
X-purgate-ID: 152705::1518205524-0000081F-D681418C/0/0
X-purgate-size: 2021
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail08.wdf.sap.corp (Postfix) with ESMTP id 3zdQX41DQlz2xF5 for <tls@ietf.org>; Fri, 9 Feb 2018 20:45:24 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1EDD5409B; Fri, 9 Feb 2018 20:45:24 +0100 (CET)
To: tls@ietf.org
Date: Fri, 09 Feb 2018 20:45:24 +0100
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20180209194524.1EDD5409B@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MHEwYoQSxAKDdxIkO3f0-d8qXLM>
Subject: [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 19:45:29 -0000
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] Network middlebox corrupting TLS session re… Martin Rex
- Re: [TLS] Network middlebox corrupting TLS sessio… David Benjamin