Re: [TLS] Breaking into TLS to protect customers

Roland Zink <roland@zinks.de> Thu, 15 March 2018 18:22 UTC

Return-Path: <roland@zinks.de>
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 29FDC12D80E for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 11:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zinks.de
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 W2pWI_5TYlxh for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 11:22:05 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C9C1252BA for <tls@ietf.org>; Thu, 15 Mar 2018 11:22:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1521138122; s=strato-dkim-0002; d=zinks.de; h=Content-Type:In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=41EwsdeYjN+Zi5z1WSXuQWZ3rEPhcy2wPj+lNwALnpk=; b=gPOcELvB20Z8vz9ESrns9vjyscM9h96j5ACu78oq1WlkMOXgmNQawrIc7H0WUgJUVW 4puG338AxhIhZsd5ruTx5tKBdl93We0dwVvgf5xAiYacxupMAHB1Xz/mCRYgZG1eT7PL kseCw0CS3NBQhTkZtzR8IX7L/P8abUSwbP2tXpGUxFyH4xCVyjV8PxNCiLMvPoYPCTOV 11/vkJIqOgcACy8vGlrqCuFeYz6ZgEZJfA1krl07TtIoRCO/gOHWrhYgc68Hz7DmYO+R Nk4P3gPypUdFd+ROmJtFuxEv44M01yqSljE3Q61hEV6KmTBfxtxgnphxK/qLuKzhUuxH 00Ow==
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1YaZ2OgvlDQIHae3Hc8=
X-RZG-CLASS-ID: mo00
Received: from [10.33.22.7] (p54A6DFEF.dip0.t-ipconnect.de [84.166.223.239]) by smtp.strato.de (RZmta 42.19 DYNA|AUTH) with ESMTPSA id 60a425u2FIM2ZEx (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <tls@ietf.org>; Thu, 15 Mar 2018 19:22:02 +0100 (CET)
To: tls@ietf.org
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com> <0bd7ed2d174a45d993026c8ed0443ae8@LXDOMEXC01.ssidom.com> <CAHbuEH7tF3CwxKdFBpC_6VKOX-TJ__u21GgtUKwBrRqfBW_aBQ@mail.gmail.com> <CAEa9xj46VWWQzuHG0=s6pavaXMQ7=PFuKTWANhn_tmnRQ1rDJQ@mail.gmail.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <793eabfb-d977-dc74-e3fd-b7bd75a56ce7@zinks.de>
Date: Thu, 15 Mar 2018 19:22:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAEa9xj46VWWQzuHG0=s6pavaXMQ7=PFuKTWANhn_tmnRQ1rDJQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------CDE23142E72A5A00F203A308"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ih17T83GQnJNtnNpffVgR7Pdj4w>
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 18:22:09 -0000

Am 15.03.2018 um 17:58 schrieb Carl Mehner:
>
>
> On Thu, Mar 15, 2018 at 9:59 AM, Kathleen Moriarty 
> <kathleen.moriarty.ietf@gmail.com 
> <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
> > 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.
>
> Yes, they might, however, the best place for malware detection is on 
> the edge (which is out of scope for "in the Datacenter" type 
> connections) and the endpoint, where an agent is able to run that does 
> not need to 'break in' to the TLS session. Yes, the Fenter draft talks 
> about how malware endpoints can be anywhere in the network, and that 
> they can delete logs as a reason to require out of band network 
> decryption. However, if "breaking TLS" becomes an effective malware 
> mitigation means, more malware makers may move to using app-level 
> encryption (as some already have). Therefore, the conclusion we can 
> draw is that malware is not a reasonable reason requiring this 
> enhanced "visibility".
>
I don't think you can make this conclusion when the fact that app-level 
encryption is used can be detected and blocked. However there might be 
ways to hide like steganography.

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