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