Re: [TLS] Breaking into TLS to protect customers

Ion Larranaga Azcue <ilarra@s21sec.com> Thu, 15 March 2018 08:54 UTC

Return-Path: <ilarra@s21sec.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 275131270A7 for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 01:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Mzm0Ww5O_fyu for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 01:53:59 -0700 (PDT)
Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE2212708C for <tls@ietf.org>; Thu, 15 Mar 2018 01:53:58 -0700 (PDT)
From: Ion Larranaga Azcue <ilarra@s21sec.com>
To: Yoav Nir <ynir.ietf@gmail.com>, Rich Salz <rsalz@akamai.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Breaking into TLS to protect customers
Thread-Index: AQHTvA3iixHTI7nuzEOVKDOY2Cg356PQvDUAgAA3RQA=
Date: Thu, 15 Mar 2018 08:53:55 +0000
Message-ID: <0bd7ed2d174a45d993026c8ed0443ae8@LXDOMEXC01.ssidom.com>
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com>
In-Reply-To: <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com>
Accept-Language: es-ES, pt-PT, en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.228.250.16]
x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c
Content-Type: multipart/alternative; boundary="_000_0bd7ed2d174a45d993026c8ed0443ae8LXDOMEXC01ssidomcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kJOA3IVKFiIIqTJt4XmivvUjzqo>
Subject: Re: [TLS] Breaking into TLS to protect customers
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: Thu, 15 Mar 2018 08:54:03 -0000

I fail to see how the current draft can be used to provide visibility to an IPS system in order to detect bots that are inside the bank…

On the one hand, the bot would never opt-in for visibility if it’s trying to exfiltrate data, so this capability would never get activated. And even if the bot was nice enough as to opt-in for visibility, the party responsible for providing the IPS with the required information is the server, which in this case is under control of the attacker. There is no way the attacker’s server will negotiate with the IPS the required keys to decrypt the channel (most likely it can’t even communicate with it).

And if you decide to close that connection because of the lack of visibility, well… 99% of TLS servers in internet will not negotiate visibility keys with your specific IPS, so you could as well close all TLS traffic going outside. And you don’t need visibility for this, only a well-configured firewall.

So, maybe I’m wrong, but I think that this specific use case (analysis of either malicious or legitimate clients’ traffic going from the enterprise network to outside servers) is not covered by the draft under discussion because the remote server will never negotiate the encryption keys with the IPS. For me, the only way to provide visibility within this case is by actively proxying every connection, something that proponents of the need for visibility don’t seem to be comfortable with, and which in my opinion does not require lowering the TLS protocol security level.

Or maybe I misunderstood the use case altogether…


De: TLS [mailto:tls-bounces@ietf.org] En nombre de Yoav Nir
Enviado el: jueves, 15 de marzo de 2018 5:58
Para: Rich Salz <rsalz@akamai.com>
CC: tls@ietf.org
Asunto: Re: [TLS] Breaking into TLS to protect customers

Hi, Rich.

You are conflating customers and users. The customer that may be protected by breaking TLS in a bank’s server farm is the bank itself. An IPS system with visibility into the traffic may detect bots that are there to steal data or mine cryptocurrencies or whatever.

If the customers of the bank are protected, it’s a happy side effect (collateral benefit?). The object is to protect the system integrity and the data.

Yoav


On 15 Mar 2018, at 5:29, Salz, Rich <rsalz@akamai.com<mailto:rsalz@akamai.com>> wrote:

Some on this list have said that they need to break into TLS in order to protect customers.

The thing customers seem to need the most protection is having their personal data stolen.  It seems to happen with amazing and disappointing regularity on astounding scales.  Some examples include
·         retailer Target, presumably subject to PCI-DSS rules
·         Anthem health insurance, presumably a regulated industry
·         Equifax, a financial-business organization (but apparently not regulated)
·         Yahoo, a company created on and by and for the Internet (one would think they know better)
We could, of course, go on and on and on.

NONE of those organizations are using TLS 1.3.

So what kind of “protect the customer” requires breaking TLS?  And what benefits and increased protection will customers see?


_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls