Re: [TLS] Breaking into TLS to protect customers

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 15 March 2018 14:59 UTC

Return-Path: <kathleen.moriarty.ietf@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 4CD5C12D87C for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 07:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 EX60Qg-Jviee for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 07:59:56 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 25735124D6C for <tls@ietf.org>; Thu, 15 Mar 2018 07:59:56 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id d21so8927010ioc.5 for <tls@ietf.org>; Thu, 15 Mar 2018 07:59:56 -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:content-transfer-encoding; bh=kPZLBE6Mjf+HYSx8yIShYGKy2Bw/NNULmHOekRU8Qb0=; b=N29eq8hmSQSTd2shiEcq/cvq1OaJnNUISRUMR03XGt322qKSQGE9IUJXeU7ttV4mgG 1stualzaSn+QWAdB/lQGhwu7oV5Wu5tcBR8Bn7HGD/b+KqEAOB/ecSJLO9c8xniZ8lM4 JldR8l4ubZBPpMTUYnLZH1gVyUS2vLQoMO+TLK+kcl7MSYYoXyIfawcetnHgxbD+G76M dcAo0xviF2zB42V5hj2zWWiywUTLlq9UEUshlxceXDhyOuZf77omF3zw0EvTvUNI/Ys0 8i/ySIY0UFieLOR4ZUeq6GsOvrs//09pNvrj5h6YjrR/E3flcH2hsbPNtD+tO5AjBmz3 Zy1g==
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:content-transfer-encoding; bh=kPZLBE6Mjf+HYSx8yIShYGKy2Bw/NNULmHOekRU8Qb0=; b=SZNpuBMsiG37G8pi9WlwpHkU6+Iz90tMiE+V8fRRIWI22I37BX3+kFCNnT1y8kXaZb GkfeL7pwLScCGKqLrTM8T1juoWhlEa4cMkqVrYLxsXNFSIe2Trxbrrgs5msW+mW+VVnC g/4Jo1hZPe1kKI63lRxilacn/i/ZEYY3lhj6XNVAJ4iip1E2hZPq09Qt3ApjwdwXiC9n TgFyt904ph09oOwRbZuOjxGHxXojPU+qtFvcou78icnnRZPZBw3cQw7CKFsMAT3JeMD6 ntuoZIX8cgcEIZ4LNjNQg+lqxLW5HfKImJXkw/1rHmY23sZBwqKxA1Q8JLQBrPQL7v7S fKKw==
X-Gm-Message-State: AElRT7GsZVlpdGYCsQ297GfX2zbvfhtJaWlzEWIU0cdRz4IddeWRXhj0 AfaGlCcwTJ141x2LBJLmDZf16SzxQgI8n5GVX7A=
X-Google-Smtp-Source: AG47ELvdAv0ICHuTl9pyykk0hrxNsyHldsUxB3gXolKcIxl3P7034ZgLICK2gr1q2a7SiZMjquDxjaSBGaqXH8RNr/o=
X-Received: by 10.107.34.80 with SMTP id i77mr9036788ioi.220.1521125995165; Thu, 15 Mar 2018 07:59:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.192.156.137 with HTTP; Thu, 15 Mar 2018 07:59:14 -0700 (PDT)
In-Reply-To: <0bd7ed2d174a45d993026c8ed0443ae8@LXDOMEXC01.ssidom.com>
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com> <0bd7ed2d174a45d993026c8ed0443ae8@LXDOMEXC01.ssidom.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 15 Mar 2018 10:59:14 -0400
Message-ID: <CAHbuEH7tF3CwxKdFBpC_6VKOX-TJ__u21GgtUKwBrRqfBW_aBQ@mail.gmail.com>
To: Ion Larranaga Azcue <ilarra@s21sec.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, Rich Salz <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TdqalDlTCX-jL2uiWZtI4x1OiEY>
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 14:59:58 -0000

On Thu, Mar 15, 2018 at 4:53 AM, Ion Larranaga Azcue <ilarra@s21sec.com>; wrote:
> 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…
>
>

In an effort to help clear up the use case and not weighing in on the
discussion...

I think what Yoav is referring to by detecting BOTS within the
network, is really so called advance persistent threat (APT) actors
that are moving around the internal network leveraging existing access
rights of compromised accounts and privilege escalation
vulnerabilities.  These might be detectable with 'visibility'.
Patterns and behavior might be used to detect the APT use case whether
or not encryption protects the stream, but it is more difficult.

If an attacker was using their own server and the fingerprints were
different, detection with encryption would be possible even if it is
more difficult. Threat sharing groups do exchange detection techniques
that involve encrypted traffic for the latter case.  And I think
everyone agrees, that this is not a use case the proponents are trying
to cover.

Best,
Kathleen

>
> 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>; 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
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen