Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

Steve Fenter <steven.fenter58@gmail.com> Mon, 26 March 2018 11:48 UTC

Return-Path: <steven.fenter58@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 929D2127137 for <tls@ietfa.amsl.com>; Mon, 26 Mar 2018 04:48:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 sxRFRcIZUWhH for <tls@ietfa.amsl.com>; Mon, 26 Mar 2018 04:48:55 -0700 (PDT)
Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (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 6CF80127286 for <tls@ietf.org>; Mon, 26 Mar 2018 04:48:55 -0700 (PDT)
Received: by mail-pl0-x22e.google.com with SMTP id s24-v6so1385726plq.6 for <tls@ietf.org>; Mon, 26 Mar 2018 04:48:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=s70HU06j5g/RQZqn7dR7lLnOACdPBa5UChh56SHKVZY=; b=oP4dUNKGCVuh+wBJrkXfucyCuq4nMYEdDsBaP1aEUQM6RI8Ffek4LwAF+c0X3XOIAR yHCpOqcaOtSTFZnct4bi6zuFdbb/ewx8FKIbmB9vBcL+mfWpol2rDvpwMxmFc0YXVrCV 6gTvIKL4LoN/xMl12lvA6InhTStUBHbpaGshe7gIzJR5P+LgkkfFIrIe+2vaCgCglH0s r0yc4RE8v6TnJOH6ezId8KtRKhodMRsIrJbRpnBzoJTWpyxKRNyA7SwXe/sPtlXlDlvz nwmJQ6HppD8/Zy9WYCP2Bc6UmhdhxfYtY8u16VFmHbn/qTXqQ42u92l/tCVl7+/0Moe0 b6VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=s70HU06j5g/RQZqn7dR7lLnOACdPBa5UChh56SHKVZY=; b=keXSJ/kn7qHv4GexqSgJ2uL6MonGnylMHgt/Q+IPW8pID9E+GVbKzHe3D+p9o5dBif eI4Yl6+Q0o+GgTMP59cAmeMURf6I29F783d3g6+TL+9tPjRNPd+9ILBmLsa36Xv5KgpZ MEkQEaMrrKQWl6ADsmsooQILQwLiJ7txHVq8Q3V9Drb4IlCykieiZ1szEaKiEXu1qITU 2OwfqGxvakkBpk6g7h10bDb4CaOxlOsKik1bRG1Gq+jCzhnYdwLTxpy66Aq8qLetOGW6 2GikYJnaKCQFFC4wKZAV7thYNtiv76TOaM0TTxVdt5KeJRpGoiqes1PH+HcmV2olR363 LvDQ==
X-Gm-Message-State: AElRT7GZXQqgOCWCmt+eV8M37bfee+1OPbsxNBidlFYQjdb23/Ff0kVP CGb7hoELkKchTwH+qYKJ6XY=
X-Google-Smtp-Source: AG47ELuSUu/ethncB03w9jyezrqboxbmxMVXikJFLquzo3lvlKH0JOXBfTMRHoMCqfHB1eUo++PJWw==
X-Received: by 2002:a17:902:d695:: with SMTP id v21-v6mr29840221ply.34.1522064935027; Mon, 26 Mar 2018 04:48:55 -0700 (PDT)
Received: from [100.110.110.216] (70.sub-174-214-9.myvzw.com. [174.214.9.70]) by smtp.gmail.com with ESMTPSA id s68sm26003061pgb.43.2018.03.26.04.48.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Mar 2018 04:48:54 -0700 (PDT)
References: <810C31990B57ED40B2062BA10D43FBF501C45B43@XMB116CNC.rim.net> <CAMqknA4rE_R08_2abVYP2ii5CFn_PuC22+tHxi0hxt=OEDp0NQ@mail.gmail.com> <CAHOTMVJtn0x6xyAoePvfB9JNr5mAeD95DUsqYX3yO7vqrpZ=zQ@mail.gmail.com>
In-Reply-To: <CAHOTMVJtn0x6xyAoePvfB9JNr5mAeD95DUsqYX3yO7vqrpZ=zQ@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-81A06C69-F76C-4CC8-B1D8-BB11CB8B3B83
Message-Id: <9130E305-B231-4BE9-B4F6-78F3A4D8012A@gmail.com>
Cc: Alex C <immibis@gmail.com>, "tls@ietf.org" <tls@ietf.org>
X-Mailer: iPad Mail (11D201)
From: Steve Fenter <steven.fenter58@gmail.com>
Date: Mon, 26 Mar 2018 12:48:52 +0100
To: Tony Arcieri <bascule@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Gix4E4YYO1s3wBrSkKbRWwcPS8c>
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: Mon, 26 Mar 2018 11:48:59 -0000

MITM as a solution doesn't scale for the needs of the enterprise.  Packet decryption and inspection is needed at many locations within the data center: at many tiers of an application, within the virtual environment, and within the cloud environment, all of which may be TLS encrypted.  Speaking as a troubleshooter, a problem can happen anywhere in the enterprise network, and there are thousands of locations where I need to be able to take a packet trace and decrypt it in order to find a slow or failing transaction.

The biggest problem I see with the key escrow solutions being suggested is that decryption is in some cases taking place in real time, even though it's out of band. This is being done, for example, for security inspection, for fraud monitoring, and for application performance monitoring.  TLS decryption appliances are going to be getting packets off of 100 gig links, and when the packet arrives the keys have to be there.  At this speed there's not a lot of time for queuing packets and waiting for keys. If we are going to use exported ephemeral keys, I think placing them in the packet as in draft-rhrd is the only scalable way to accomplish this.

In response to unwillingness to change, enterprises are doing things today that work and that solve our business problems. The alternative suggestions being made, like MITM and endpoint monitoring, don't solve our business problems.

In response to how much time we have, it was recently stated on the list that NIST has published a draft that disallows all non-DH cipher suites, which includes TLS 1.2.  TLS 1.2 with Diffie-Hellman only will be just as big of a problem for enterprises as TLS 1.3 is.  I don't have a crystal ball, but I don't I think the RSA key exchange is going to last five years as has been suggested.  And whenever RSA is deprecated, it takes a long time to implement a new solution in a large enterprise, so we have to be well out in front of the problem,

Steve Fenter

> On Mar 24, 2018, at 3:31 PM, Tony Arcieri <bascule@gmail.com>; wrote:
> 
>> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls