Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
I recognize I may lack context, because I have only seen Steve Fenter's slides, but apart from it not reaching consensus, the scenario it presents (user connecting to online banking service) seems to be visibility of connections from the internet to internal servers. I think that not even visibility proponents agree between them, as sometimes they seem to require "server-to-server" visibility within the data center while periodically use cases appear (such as the one you mention) where traffic to be decrypted goes from internet to the internal network (or even viceversa). I'm starting to understand someone who some months ago said this looked like playing "whack-a-mole". Besides, from what I understand from Steve Fenter's proposal (I may be wrong because I have seen only the slides) , they seem to go for non-visible TLS 1.3 connections from the client to the external layers of the network, and visible TLS 1.3 connections within their internal network. This would match the idea of "visibility only within the datacenter" but in my opinion it requires a finalization of the external tunnel and creation of a new internal one. At that point you obviously have the clear text and you could move your monitor tasks to that point. So maybe it's because the presentation is obsolete or because I lack context but... no, I don't think those specific slides are a valid example today. De: TLS en nombre de Jim Reid Enviado: sábado, 24 de marzo de 2018 16:56 Para: Dan Brown Cc: tls@ietf.org Asunto: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it) > On 19 Mar 2018, at 15:18, Dan Brown wrote: > > PS: I never directly worked on enterprise security (usually, I just think > about the math of basic crypto primitives), but I don't recall hearing about > such a "visibility" feature in the enterprise security work of colleagues > (whom I do _not_ speak for), e.g. one system used forward-secure ECMQV to > establish a connection between smartphones and the enterprise network. Hearsay anecdote is not evidence. :-) There are use cases in enterprise networks, notably in banking and finance. Some of these were presented to the TLS WG. [See Steve Fenter’s presentation at IETF97.] However the WG did not reach consensus on adopting the relevant drafts as work items. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
From: TLS on behalf of Tony Arcieri Date: Saturday, March 24, 2018 at 11:31 AM Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it) > On Fri, Mar 23, 2018 at 11:26 PM, Alex C 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 not a solved problem for mutual authentication scenarios even if you drop the passive requirement (as should be done in such cases anyway). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
> On 19 Mar 2018, at 15:18, Dan Brown wrote: > > PS: I never directly worked on enterprise security (usually, I just think > about the math of basic crypto primitives), but I don't recall hearing about > such a "visibility" feature in the enterprise security work of colleagues > (whom I do _not_ speak for), e.g. one system used forward-secure ECMQV to > establish a connection between smartphones and the enterprise network. Hearsay anecdote is not evidence. :-) There are use cases in enterprise networks, notably in banking and finance. Some of these were presented to the TLS WG. [See Steve Fenter’s presentation at IETF97.] However the WG did not reach consensus on adopting the relevant drafts as work items. signature.asc Description: Message signed with OpenPGP ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
On Fri, Mar 23, 2018 at 11:26 PM, Alex C 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 ...". 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
