Re: [TLS] datacenter TLS decryption as a three-party protocol
"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 20 July 2017 20:15 UTC
Return-Path: <prvs=837464833d=uri@ll.mit.edu>
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 A2D4A131B9C for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 13:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 xayn6KjTrxMQ for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 13:15:06 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id DEB0D131B90 for <tls@ietf.org>; Thu, 20 Jul 2017 13:15:05 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6KKF4op040681 for <tls@ietf.org>; Thu, 20 Jul 2017 16:15:04 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] datacenter TLS decryption as a three-party protocol
Thread-Index: AQHTAJB0GJJTXEJ9Nke26Xc5y2RlZKJbn/KAgAAClACAAAm5AIAAAWoAgAAB0ICAAFVOAIAABBqAgAB/KoCAAASqgIAACjOAgAAC6wCAAJbcgIAAAy8AgAADmACAADBYAP//wM6A
Date: Thu, 20 Jul 2017 20:15:03 +0000
Message-ID: <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu>
References: <CAAF6GDeFuRy0DN6w3FwmR_nh1G=YBi4+qiEcw0MfSRj4SUCbZQ@mail.gmail.com> <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp>
In-Reply-To: <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3583412103_2119082059"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707200312
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tsBJztXN-dQD7BcYblUAZVS1FUc>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
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, 20 Jul 2017 20:15:10 -0000
Maybe we are better off just retrofitting RSA-key-transport back into TLS-1.3? In that case at least the peer could refuse this method of key establishment, and one could safely assume that if a peer insists on that key establishment mechanism, this session will be surveilled? If I had to choose between the two evils, RSA-key-transport seems a lesser one (or at least a more obvious/visible one). -- Regards, Uri Blumenthal On 7/20/17, 16:01, "TLS on behalf of Martin Rex" <tls-bounces@ietf.org on behalf of mrex@sap.com> wrote: Colm MacCárthaigh wrote: > > If you maintain that draft-green is Wiretapping, then that is also the > correct term for what is happening today. Today, operators are using a > static key, used on the endpoints they control, to decrypt traffic > passively. The only difference is DH vs RSA, and I know you'll agree that's > not material. What I'm currently seeing in the installed base for getting at the plaintext of TLS-protected traffic, are these two approaches: (1) Server-side: Reverse-proxy (2) Client-side: TLS-intercepting proxy and neither of these needs to break TLS and neither needs to break forward secrecy of the SSL/TLS-protected(!) communication. While Server-side reverse proxies (1) _might_ be used to "inspect/monitor" traffic, more often it seems to be used for scaling / load-balancing to multiple backend servers of a server farm. We ship such functionality for the backend specifically for scaling/load-balancing, and for placing the SSL termination point into a DMZ (firewalled backend servers). We a proprietary scheme to forward SSL/TLS client certs from the reverse proxy to the backend servers. (2) is often used by so-called "AV-Software" of the "Internet Security" kind, and studies have shown over and over again just how badly many of that stuff breaks security (by botching the TLS server certificate validation and/or server endpoint identification). I also see (2) being used by some of our customers in the form of TLS intercepting internet proxies, mostly in countries that lack constitutional strong privacy protections (US, UK&CommonWealth, middle EAST). It regularly breaks outgoing communication scenarios and confused application admins, because the fake TLS server certificates will be rejected by our app client unless the trust in explicitly configured. Something which IT/networking departments occasionally fail to properly explain to their colleague application admins. Whenever outgoing communication requires the use of SSL/TLS client certs, existing TLS intercepting proxies don't work (and I'm really glad that they break). A growing number of legal/governmental data exchange scenarios use SSL/TLS client certs (something I really appreciate, because the use of client certs fixes a number of problems). :-) Personally, I consider server-side reverse proxies primarily as an implementation detail of the backend (how workload is distributed within the backend). The client-side TLS intercepting proxies, however, are a constant security problem, and unless it is a ***TRUELY*** voluntary, consenting opt-in, and running on the same machine as the user, and with the user in full control on whether and how that intercepting proxy is used. If presence & use of a TLS intercepting proxy is the result of anything along the lines of "compliance", "policy" or "conformance", then it is wire-tapping, with a probability near certainty. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [TLS] datacenter TLS decryption as a three-party … Benjamin Kaduk
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Roland Zink
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Yoav Nir
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Derrell Piper
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Benjamin Kaduk
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… BITS Security
- Re: [TLS] datacenter TLS decryption as a three-pa… Martin Rex
- Re: [TLS] datacenter TLS decryption as a three-pa… Martin Rex
- Re: [TLS] datacenter TLS decryption as a three-pa… Salz, Rich
- Re: [TLS] datacenter TLS decryption as a three-pa… Roland Zink
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Tony Arcieri
- Re: [TLS] datacenter TLS decryption as a three-pa… Andrei Popov
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Andrei Popov
- Re: [TLS] datacenter TLS decryption as a three-pa… Salz, Rich
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Colm MacCárthaigh
- Re: [TLS] datacenter TLS decryption as a three-pa… Martin Rex
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ilari Liusvaara
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ilari Liusvaara
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Christian Huitema
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Jeffrey Walton
- Re: [TLS] datacenter TLS decryption as a three-pa… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] datacenter TLS decryption as a three-pa… Felix Wyss
- Re: [TLS] datacenter TLS decryption as a three-pa… Ted Lemon
- Re: [TLS] datacenter TLS decryption as a three-pa… Stephen Farrell
- Re: [TLS] datacenter TLS decryption as a three-pa… Brian Sniffen
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Paul Turner
- Re: [TLS] datacenter TLS decryption as a three-pa… Brian Sniffen
- Re: [TLS] datacenter TLS decryption as a three-pa… Paul Turner
- Re: [TLS] datacenter TLS decryption as a three-pa… Kyle Rose
- Re: [TLS] datacenter TLS decryption as a three-pa… Sean Turner
- Re: [TLS] datacenter TLS decryption as a three-pa… Ilari Liusvaara