Re: [TLS] TLS interception technologies that can be used with TLS 1.3

Ion Larranaga Azcue <ilarra@s21sec.com> Thu, 15 March 2018 23:26 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 1D438127599 for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 16:26:12 -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 bjkgj2hPJWmA for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 16:26:08 -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 89650120454 for <tls@ietf.org>; Thu, 15 Mar 2018 16:26:07 -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] TLS interception technologies that can be used with TLS 1.3
Thread-Index: AQHTu/L3ZuQWzxcKRUqiCXf/BhURyqPQuqyAgABxswCAAGzOAIAAEDcAgAA1IACAAAciAIAAADcAgAACGACAAAchgg==
Date: Thu, 15 Mar 2018 23:26:03 +0000
Message-ID: <1521156363579.84825@s21sec.com>
References: <CACsn0cmNuuG4dhkouNzb=RDfYwG25VaKN7cGhm21wfLk-NmS5A@mail.gmail.com> <9B30F837-8F6A-4AF0-A3BD-69F9AFED5D7B@gmail.com> <2832089.SA8sAEVfAM@pintsize.usersys.redhat.com> <6BC4335A-D2E9-41FC-9F72-04B06594883B@gmail.com> <5CFD360D-818E-41A0-A140-59C283DC6CB0@akamai.com> <CAL02cgQQ7vve5+ndj1tUNgO+eH8cro2Mhhwj-bfBK=BnxECfRw@mail.gmail.com> <A2B23437-63DE-42B0-A29E-3A0635BCA85E@gmail.com> <619FD02D-8F30-4261-BFE9-22CCFD145BE7@akamai.com>, <1E3319E8-E6E6-4317-B427-3AE5B10BE3F6@gmail.com>
In-Reply-To: <1E3319E8-E6E6-4317-B427-3AE5B10BE3F6@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_152115636357984825s21seccom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1Sfa9bkRIpt5KUI1ZlNiqnU2trk>
Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3
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 23:26:12 -0000

Unless I'm wrong, with the visibility draft the client side is also unable to identify who the key material is being transferred to. Only the server-side can know it, so I think it's a similar case.

Imagine a malicious user is able to subvert the communication between the server and the middlebox. If this user manages to convince the server that it should use its own keys instead of the ones the middlebox owns, the attacker is able to happily decrypt all traffic by using a mechanism we have provided him with, and nobody would realize it (because the client has no way to know who the key material is being shared with)

And yes, if the key material is shared out-of-band we have a similar problem, I don't deny it. I think that this comes down to a philosophycal dylemma. We have two different mechanisms that amount to a similar security level:

- key material is shared out-of-band using some additional mechanism, defined outside of TLS
- key material is shared in-band using the TLS extension

Both mechanisms seem to provide, in theory, similar security levels. The difference is that if TLS extensions handle it, it's TLS the responsible for the security downgrade, whereas in the other case... well, we can't prevent anyone from doing what they want with their key material so...

I would vote for out-of-band sharing if enterprises need it, delegating this in a completely different protocol. TLS should be as clean and as secure as possible.

________________________________
De: TLS <tls-bounces@ietf.org>; en nombre de Yoav Nir <ynir.ietf@gmail.com>;
Enviado: jueves, 15 de marzo de 2018 23:49
Para: Rich Salz
Cc: tls@ietf.org
Asunto: Re: [TLS] TLS interception technologies that can be used with TLS 1.3

Yeah, as log as we know who we're shipping it to and the user intends for us to send it to this entity.

For the debugging case that we were talking about in Prague, sending the keys out-of-band should work fine.

For some middlebox that needs to decrypt the traffic online, it needs the keys before the first data record goes out. I don't see how we can do that without interleaving it with the handshake.



On 16 Mar 2018, at 0:42, Salz, Rich <rsalz@akamai.com<mailto:rsalz@akamai.com>> wrote:

I think if we ship the keys over some kind of secure socket layer we should be okay, right?


From: Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>>
Date: Thursday, March 15, 2018 at 6:41 PM
To: Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>>
Cc: Rich Salz <rsalz@akamai.com<mailto:rsalz@akamai.com>>, Hubert Kario <hkario@redhat.com<mailto:hkario@redhat.com>>, "tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3

IIUC not quite. There is an API, so the application that uses the library can get the keys. The application can then save it to a file, send it to a central repository, send it to the government, or whatever else it might want to do.

There is no built-in setting where OpenSSL writes the keys to a file, nor do applications such as web servers do this AFAIK.

It should not be difficult to write, but is not provided in off-the-shelf software.

Making the library send this in-band in some protocol extension is a far bigger endeavor. It's also a dangerous switch to leave lying around.


On 16 Mar 2018, at 0:16, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:

Just to confirm that I understand the scope of the discussion here:

- TLS libraries have facilities to export keys from the library
- Obviously, it's possible to ship these exported keys elsewhere (`tail -f $SSLKEYLOGFILE | nc $LOGBOX`)

So all we're really talking about is whether to define a way to do the shipment of the exported keys in-band to the TLS session.


On Thu, Mar 15, 2018 at 3:05 PM, Salz, Rich <rsalz@akamai.com<mailto:rsalz@akamai.com>> wrote:
This is what OpenSSL provides:
    https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html


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