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

Hubert Kario <hkario@redhat.com> Wed, 04 April 2018 16:37 UTC

Return-Path: <hkario@redhat.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 2230F120724 for <tls@ietfa.amsl.com>; Wed, 4 Apr 2018 09:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] 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 Wyh5fFJ_tqL6 for <tls@ietfa.amsl.com>; Wed, 4 Apr 2018 09:37:12 -0700 (PDT)
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94312126D3F for <tls@ietf.org>; Wed, 4 Apr 2018 09:37:12 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7F3934023112; Wed, 4 Apr 2018 16:37:11 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.34.247.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id 844CA10B2B51; Wed, 4 Apr 2018 16:37:10 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 04 Apr 2018 18:37:03 +0200
Message-ID: <1715803.mF2QBD68G2@pintsize.usersys.redhat.com>
In-Reply-To: <fa7e34cd-e052-6d05-cbab-4b30342958a9@zinks.de>
References: <1521920255951.94271@s21sec.com> <1727401.ncI4dqslgy@pintsize.usersys.redhat.com> <fa7e34cd-e052-6d05-cbab-4b30342958a9@zinks.de>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1934838.pBjHOxOYCL"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 04 Apr 2018 16:37:11 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 04 Apr 2018 16:37:11 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:''
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4kTWm0nNMwLPlPrXtGnZ03aDEg8>
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: Wed, 04 Apr 2018 16:37:15 -0000

On Wednesday, 4 April 2018 16:46:36 CEST Roland Zink wrote:
> Am 04.04.2018 um 14:43 schrieb Hubert Kario:
> > On Friday, 30 March 2018 11:42:23 CEST Vakul Garg wrote:
> >> Hi Martin
> >> 
> >>> -----Original Message-----
> >>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
> >>> Sent: Thursday, March 29, 2018 4:47 AM
> >>> To: Steve Fenter <steven.fenter58@gmail.com>
> >>> Cc: tls@ietf.org
> >>> Subject: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't
> >>> do
> >>> it)>
> >>> 
> >>> Steve Fenter <steven.fenter58@gmail.com> wrote:
> >>>> To clarify for anyone who has confusion on the enterprise TLS
> >>>> visibility use case, I think enterprises need to be able to do
> >>>> out-of-band decryption anywhere in the network that they own.
> >>> 
> >>> This is argument is so lame.
> >>> 
> >>> In Germany, monitoring communications between individuals or between
> >>> individuals and legal entities, including communications over corporate
> >>> networks, was made a serious crime in 2004 (TKG 2004) with a penalty of
> >>> up
> >>> to 5 years in prison for listening into such communication.
> >>> 
> >>> The world didn't end.  Really, consider it proven that there is no need.
> >> 
> >> Could monitoring could be legally done if user provided his consent at
> >> the
> >> time of login into enterprise managed terminal?
> >> I guess that's the case in enterprise managed networks.
> > 
> > No, even then the employer needs to establish a concrete case for
> > inspection of the communications of an employee.
> > Employer also must not continue inspection of an email as soon as it has
> > noticed that it is part of a private message.
> > 
> > https://www.lexology.com/library/detail.aspx?g=f946064a-05d0-4603-ace9-384
> > 6b1c7536d
> > 
> > and this is true, to a large degree, for the whole of EU:
> > https://www.theguardian.com/law/2017/sep/05/romanian-chat-messages-read-by
> > -employer-had-privacy-breached-court-rules> 
> >  From the ECHR ruling:
> > "An employer[...] cannot reduce private social life in the workplace to
> > zero. Respect for private life and for the privacy of correspondence
> > continues to exist, even if these may be restricted in so far as
> > necessary."
> 
> This is true, but at the same time the employer is required in many
> countries including Germany to archive many emails and other relevant
> messages. See for example https://en.wikipedia.org/wiki/Email_archiving
> or https://www.intradyn.com/email-retention-laws/. This is often in
> conflict with the above mentioned laws, for an example see
> https://www.theguardian.com/business/2016/jan/08/volkswagen-withhold-emissio
> ns-documents-investigations.
> 
> 
> I don't think breaking TLS is the way to fulfill such requirements but I
> also think TLS connection to a company shouldn't end up at a third party
> providing hosting or CDN services.

it's not in conflict, just because you control of have the data doesn't mean 
you are allowed to access it - think phone companies listening on customer 
conversations

What it does mean, is that realtime access to TLS connections is definitely 
not necessary to retain messages for criminal investigations, that can and 
should be done at the endpoint in control of the company, not in transit at 
network boundary.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic