Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
Tony Arcieri <bascule@gmail.com> Sat, 24 March 2018 15:32 UTC
Return-Path: <bascule@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 91371129C59 for <tls@ietfa.amsl.com>; Sat, 24 Mar 2018 08:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 qTX-lZLyXyjI for <tls@ietfa.amsl.com>; Sat, 24 Mar 2018 08:32:11 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 DC34C1201F2 for <tls@ietf.org>; Sat, 24 Mar 2018 08:32:10 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id c40so9581314uae.2 for <tls@ietf.org>; Sat, 24 Mar 2018 08:32:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TTm9IQu8bmwZvwO0ADVLeUicFoseJHNpDmXnqhlSy1c=; b=dgikVOmmLMg9LJspUWXfNMF2w96npFpTYwvwSrMAyD/ExCkT6k2gUiEgcgkO4mSPmE HyfkFwQxIFSk2VXsL1ALYMKuX+UYUmGxV7fcHxcTw92IHmGZ1mhHH95gOnFRFZNeX3U0 7M+LKgh7rq03Hau4lmF4ov9etsl6YFSe5jNu75TtkHYelZBHEDkZ+XRRlaQN204IlWX+ Ka7xDCG72T6XBcivb/kC6IyS5XPVRA2n0WHpgUW5jBDfSFrXpThQNDMtlHXykEiSvq/q O8ywi39eWGDImidFISyCzA4I3x76rb9zUVmY/aI3LqDyvI4gU6/gUtsLZzyGz9zSEsB4 v+Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TTm9IQu8bmwZvwO0ADVLeUicFoseJHNpDmXnqhlSy1c=; b=Z7ix2OvTE5BfDgIuS9lSPahiV+WAU1ZVXqz5qLo449mKgbpRG1cIGDQXZHpvZz0cCe oxTS2FPHURyJmnMS7pUHXrGWQ2REU+UkaiSz7QaNwegv5dHJ4pIIKb6fK338UXaIp+C5 EK9/wPhCIVMA5z6EhYy3roOkrrvsBCCvNvUW7XWdrryMqTxDy+Q5v0oBooRx6+ce/94y DxM0D0t5eYwW/6UKf4ThymMMHNheeIiIWxohqmEeFCfrAO9IBHGtYZrsFD8kc8agjq3q oxdy7YSFJIcVq1VGosrFitoKfTtS45RNCwGQuXpB6PrRse9Aweo4k55OS/Z2xu/EgNVJ p4bg==
X-Gm-Message-State: AElRT7GYoRQK2loe4r8QVjnp94zFU+AMMTrnM/D0RDn3Uz+9BrnZSFy9 Zde2H7bah9Kbgvc74+04tmBrW57404kmCfKc5GyTFQ==
X-Google-Smtp-Source: AIpwx4+vUSo4G7FmrLq0UH+fXPb0o4dCaDajZQkx5sJ0DTVvuO+TyZ9dxyOgAp19TIKLzXeVUTPIOCrRvTiV8vl0bus=
X-Received: by 10.159.55.104 with SMTP id a37mr5416074uae.11.1521905529791; Sat, 24 Mar 2018 08:32:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.102.65 with HTTP; Sat, 24 Mar 2018 08:31:49 -0700 (PDT)
In-Reply-To: <CAMqknA4rE_R08_2abVYP2ii5CFn_PuC22+tHxi0hxt=OEDp0NQ@mail.gmail.com>
References: <810C31990B57ED40B2062BA10D43FBF501C45B43@XMB116CNC.rim.net> <CAMqknA4rE_R08_2abVYP2ii5CFn_PuC22+tHxi0hxt=OEDp0NQ@mail.gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Sat, 24 Mar 2018 08:31:49 -0700
Message-ID: <CAHOTMVJtn0x6xyAoePvfB9JNr5mAeD95DUsqYX3yO7vqrpZ=zQ@mail.gmail.com>
To: Alex C <immibis@gmail.com>
Cc: Dan Brown <danibrown@blackberry.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114067be7c2aad05682a3ea7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AUCySM6UxpjO4wb04vvFISAjrEU>
Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
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: Sat, 24 Mar 2018 15:32:12 -0000
On Fri, Mar 23, 2018 at 11:26 PM, Alex C <immibis@gmail.com> wrote: > As I understand it (poorly!) the idea is exactly to have a single system > on the network that monitors all traffic in cleartext. > And more specifically: to be able to *passively* intercept traffic and allow it to be decrypted by a central system. "Visibility" with an active MitM is a solved problem: have the MitM appliance double as an on-the-fly CA and install its root certificate in the trust stores of all the clients you intend to MitM. It's fundamentally impossible to prevent someone from copying all their > traffic to another system in cleartext. If they're going to do it, they > will. > The functionality is exactly the same as what could be achieved by > installing monitoring software on each endpoint, but the logistics are > different since the monitoring is centralized. > The response from "visibility" proponents is "endpoint agents are hard". However, it seems like there is a simple solution to this problem which should be compatible with their existing monitoring architectures and require no changes to TLS: Instrument TLS servers and/or client libraries used by internal enterprise applications with a little shim that extracts the session master secret, then makes another TLS connection to a TLS session key escrow service, and goes "here's the session master secret for a session between X.X.X.X and Y.Y.Y.Y with nonce ZZZZ...". It could even be encrypted-at-rest to a particular public key in advance (which could correspond to e.g. an HSM-backed decryption key). Enterprises could continue to passively collect TLS sessions in whatever manner they already do, and decrypt traffic at will, it would just require looking up the session key for a particular session in a key escrow database rather than having a single key-to-the-kingdom. This approach requires no changes to TLS, no changes to how "visibility" systems collect traffic, and should provide better security in that using session master secrets better scope the authority conferred to the decryption service than D-H keys which can grant authority to e.g. resume TLS sessions. The downsides are you have to instrument clients and/or servers and have the decryption service maintain a key escrow database. However, "visibility" proponents seem unwilling to accept any changes to anything they presently do today. This is coupled with a sort of artificial emergency where they claim (or outright lie) that compliance with industry standards will require them to ship TLS 1.3 everywhere tomorrow. There is a total unwillingness to compromise, and all sorts of weasel words being thrown around, from the "visibility" euphemism itself to claims that TLS 1.3 will make them less secure because it makes implementing a single-point-of-compromise for all their encrypted traffic more difficult. The reality is for these slow-to-change enterprises, the industry standards are also slow-to-change. There is no emergency. Many of them are still using TLS 1.0. The PCI-DSS deadline to adopt TLS 1.1 isn't until this June. I would challenge any "visibility" proponent to cite *any* industry standard which will mandate TLS 1.3 any time in the next 5 years. There is lots of time to solve this problem and better ways to solve it than introducing codepaths which deliberately break the security of the protocol. -- Tony Arcieri
- Re: [TLS] Breaking into TLS for enterprise "visib… Dan Brown
- Re: [TLS] Breaking into TLS for enterprise "visib… Alex C
- Re: [TLS] Breaking into TLS for enterprise "visib… Tony Arcieri
- Re: [TLS] Breaking into TLS for enterprise "visib… Jim Reid
- Re: [TLS] Breaking into TLS for enterprise "visib… Carl Wallace
- Re: [TLS] Breaking into TLS for enterprise "visib… Ion Larranaga Azcue
- Re: [TLS] Breaking into TLS for enterprise "visib… Steve Fenter
- Re: [TLS] Breaking into TLS for enterprise "visib… Steve Fenter
- Re: [TLS] Breaking into TLS for enterprise "visib… Ion Larranaga Azcue
- Re: [TLS] Breaking into TLS for enterprise "visib… Martin Rex
- Re: [TLS] Breaking into TLS for enterprise "visib… Vakul Garg
- Re: [TLS] Breaking into TLS for enterprise "visib… Hubert Kario
- Re: [TLS] Breaking into TLS for enterprise "visib… Roland Zink
- Re: [TLS] Breaking into TLS for enterprise "visib… Hubert Kario