Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact

Roelof DuToit <r@nerd.ninja> Thu, 20 August 2020 13:59 UTC

Return-Path: <r@nerd.ninja>
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 06B2F3A0B5E; Thu, 20 Aug 2020 06:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja
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 JU-LWT2_zrB5; Thu, 20 Aug 2020 06:59:09 -0700 (PDT)
Received: from sender4-of-o54.zoho.com (sender4-of-o54.zoho.com [136.143.188.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764B13A0B3F; Thu, 20 Aug 2020 06:59:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1597931945; cv=none; d=zohomail.com; s=zohoarc; b=mAii3b7EYyJKhfylGnrqgpeyyzWlRg6+LsFpkjPCmP812GNSGgdTIJqVpxNjK8BFk7KF2vKpPcfcp6/I9pMJBVJIQRLbTZ1YlhaWzubD2d2Yg66HkF9EZXpBWA9IVzcqn+C11vX4jbkCOogLeELHbN1aWWIg6KDlExjlRgfgJv8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1597931945; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=NC9Rsszsk3WGBbl+HOKUxJe8PiyksXH/fEY8pUk+Igk=; b=JreDLZ1ZULSh7DMyhD2ed7O6w5OY/XjinfOAruOW8eFfhAdSxTjuMk5loTqiF2qepZL6H4vzp50S2yWAjJh00JSLyyvNSflIFQqbzeIS83AY2RNBJj6Ow6KEzraenYN+nn0+AGSk0DmTZZ+IIAHYI3QpWDXGkwaYEOPmUpLlr00=
ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=nerd.ninja; spf=pass smtp.mailfrom=r@nerd.ninja; dmarc=pass header.from=<r@nerd.ninja> header.from=<r@nerd.ninja>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1597931945; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; bh=NC9Rsszsk3WGBbl+HOKUxJe8PiyksXH/fEY8pUk+Igk=; b=po3bBT6WhNgI/m+jWo3t9gS6RX9/jJhweinpTtFR4Lz4e2UEpJ37Vtmksdj8be/H uPkyAgLFDMDEb/e9EdMTVhunQOVGJ0ubt57ieUTybliOCF5A3clax9ZHc018n0pAw2s FWjjXsZYly92NBYHOtfCuTXSLFn12SfiJFxNABvI=
Received: from [192.168.123.155] (dynamic-acs-24-112-241-136.zoominternet.net [24.112.241.136]) by mx.zohomail.com with SMTPS id 1597931941340423.92304621580763; Thu, 20 Aug 2020 06:59:01 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Roelof DuToit <r@nerd.ninja>
In-Reply-To: <20200819234314.29c3bbdc@totoro.tlrmx.org>
Date: Thu, 20 Aug 2020 09:58:58 -0400
Cc: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "opsec@ietf.org" <opsec@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <387460EC-D00A-4D12-9E12-713E9E0049B1@nerd.ninja>
References: <20200817163938.07580cee@totoro.tlrmx.org> <2B1FF3B4-949A-4A29-ABDC-B2B91878B947@cisco.com> <20200819234314.29c3bbdc@totoro.tlrmx.org>
To: Nick Lamb <njl@tlrmx.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-ZohoMailClient: External
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-Vh10_Hc28Ok8ZYjgEKrM6cZO4Q>
Subject: Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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 Aug 2020 13:59:18 -0000

As co-author I am not a proponent of passive TLS inspection - not least because of the ossification implications.  It cannot be labeled as ineffective though (see further comments below), even if the document strongly hints at not using passive TLS inspection in a post-TLS-1.2 world.

> On Aug 19, 2020, at 6:43 PM, Nick Lamb <njl@tlrmx.org> wrote:
> 
> The passive eavesdropper can indeed see the handshake in TLS 1.2, but
> since they were not a participant they don't actually know what it
> means even though it wasn't encrypted.
> 
> For example, suppose an RSA certificate is sent and the handshake seems
> to agree RSA key exchange and Client sends an EncryptedPreMasterSecret.
> The passive eavesdropper has no idea if that's actually encrypted to the
> RSA public key from the certificate, it's just an opaque blob.
> 
> 
> Thus it's easily possible for an eavesdropper to witness a handshake in
> which the eavesdropper believes what happened is:
> 
> Client proposed to do RSA key exchange
> Server showed a certificate for www.local-hospital.example
> Client sent an EncryptedPreMasterSecret to the local hospital
> both agreed this all worked fine and continue encrypted
> 
> The eavesdropper's "Don't eavesdrop on people's medical stuff" policy
> kicks in and it allows the connection unmolested. Unfortunately what
> really happened is:
> 
> Client proposed to do RSA key exchange
> Server showed a certificate for www.local-hospital.example
> Client sent an EncryptedPreMasterSecret for the GRU data exfiltration
> server ignoring the bogus certificate
> $5Bn of stolen commercial documents are uploaded to the server


Advanced passive TLS inspection devices use a combination of techniques to defend against those attacks for TLS 1.2 (and below):
1. Policy-based control over the use of RSA key exchange.  It should not be allowed.
2. Checking the signature in the ServerKeyExchange message when (EC)DHE key exchange is used.
3. Not trusting the destination IP address.  The hostname from the SNI is resolved and compared.

None of those techniques are perfect given an advanced adversary that controls the client + DNS in the enterprise + the flow of traffic on the server side of the TLS inspection device.
(Side note: If I’m an attacker that has control over DNS then I would not bother with TLS-based attacks for data exfiltration).
In other words, nation state attacks might succeed but it does not mean that passive TLS inspection devices are not effective against other attacks.

—Roelof