[TLS] On SNI and middleboxes

Tor Erling Bjørstad <tor@mnemonic.no> Thu, 13 August 2020 10:15 UTC

Return-Path: <prvs=4875ba468=tor@mnemonic.no>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E6F183A0B3B for <tls@ietfa.amsl.com>; Thu, 13 Aug 2020 03:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mnemonic.no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2muz9xVtjKyN for <tls@ietfa.amsl.com>; Thu, 13 Aug 2020 03:15:55 -0700 (PDT)
Received: from osl-ironport2.mnemonic.no (osl-ironport2.mnemonic.no []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5363A0B35 for <tls@ietf.org>; Thu, 13 Aug 2020 03:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mnemonic.no; i=@mnemonic.no; q=dns/txt; s=norge; t=1597313755; x=1628849755; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=7apGxqXXqCnY+b+feWJIGzhx5OReL+HBeLQstKOG/B8=; b=vc2DEARbwQq6iLAbiZYByA3pBAcM+5s4vVpEfYwi3V4esnEWfo5PuSes 1IfDm7MHafFxBQXaQ9Y8bolMYXdJKQGQZXDh6vfaXivFe41lNX61NqMb4 wnJT/vU3amO7tk8R8NG1PrqfEagx4Zzj0Uu7zR/CM29spRp131TaYCLYJ E=;
Received: from osl-mailrelay1.mnemonic.no ([]) by osl-ironport2.mnemonic.no with ESMTP; 13 Aug 2020 12:15:48 +0200
Received: from svg-exchange2.ad3.mnemonic.no (svg-exchange2.ad3.mnemonic.no []) by osl-mailrelay1.mnemonic.no (Postfix) with ESMTP id 495C42055B30 for <tls@ietf.org>; Thu, 13 Aug 2020 12:15:48 +0200 (CEST)
Received: from svg-exchange2.ad3.mnemonic.no ( by svg-exchange2.ad3.mnemonic.no ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Thu, 13 Aug 2020 12:15:47 +0200
Received: from svg-exchange2.ad3.mnemonic.no ([fe80::78de:5e18:760e:b658]) by svg-exchange2.ad3.mnemonic.no ([fe80::78de:5e18:760e:b658%8]) with mapi id 15.01.2044.004; Thu, 13 Aug 2020 12:15:47 +0200
From: Tor Erling Bjørstad <tor@mnemonic.no>
To: "tls@ietf.org" <tls@ietf.org>
CC: Morten Marstrander <mortenm@mnemonic.no>
Thread-Topic: On SNI and middleboxes
Thread-Index: AQHWcVq2xbG2YS1u/UqS7Lrdkb3w8Q==
Date: Thu, 13 Aug 2020 10:15:47 +0000
Message-ID: <B6883A09-3605-4D6F-B591-263F9D743AD5@mnemonic.no>
Accept-Language: en-GB, nb-NO, en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/16.39.20071300
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <5E373C9948273A4397B03A1DEDAA5AA1@mnemonic.no>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/N_JFVSTiyNtHmQq78LhaSnNCb08>
Subject: [TLS] On SNI and middleboxes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 13 Aug 2020 10:15:58 -0000

Dear list,

Two of my colleagues, Morten Marstrander and Matteo Malvica, just published a bit of research on using the SNI field to bypass middleboxes for TLS inspection / filtering. They’ve made a nice writeup and PoC (linked below), which also gives some insight into how these solutions are commonly implemented. The work reminds me of several previous discussions on this list, and I hope it may be of interest.

The quick summary is that middleboxes working as a half-open proxy often let the ClientHello through, even for disallowed domains, and that the content of those packets is not necessarily logged and alerted quite as one might expect. So they use the SNI to establish a 2-way channel that is basically invisible to the monitoring solution.

Not sure if they’ve also looked into the particulars of TLS 1.3 and ESNI, otherwise that might be a good follow-up topic. I put Morten on CC, he can provide additional technical details.

Products from Palo Alto, F5, and Fortinet were successfully bypassed in the lab. I expect that there are additional bug-compatible solutions out there.

* Blogpost: https://www.mnemonic.no/blog/introducing-snicat
* PoC tool: https://github.com/mnemonic-no/SNIcat
* Vendor advisory: https://support.f5.com/csp/article/K20105555
* Vendor advisory: https://security.paloaltonetworks.com/CVE-2020-2035

Kind regards,
Tor E. Bjørstad