Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

Carl Mehner <> Mon, 17 July 2017 16:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61E12131CB2 for <>; Mon, 17 Jul 2017 09:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O3Yl1aVOLQVf for <>; Mon, 17 Jul 2017 09:32:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 373A0131CAA for <>; Mon, 17 Jul 2017 09:32:43 -0700 (PDT)
Received: by with SMTP id 35so54813588uax.3 for <>; Mon, 17 Jul 2017 09:32:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=cem; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t+v3QtdKv7OF+U8UEZVrqWEd0kFNQWsZDF7ov8sTuf0=; b=FrMamC1f/ZOcDwxuGCLEHECGJJnbzsoJxKfg/IhK+uv60LeOcbYi/3t38U2AOQ6Uwt wP4ushCleh6+xTyjptkHkUytZ9j5Dk+hLjIQGk7F0L+Kamd4rRuDp1aKTu4ayp0nnnNJ t5arYoAN8tzmLzezhlra9xycQWrEdTNLup2IU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t+v3QtdKv7OF+U8UEZVrqWEd0kFNQWsZDF7ov8sTuf0=; b=kRlwK4oiIxJ0+xoUotboomhoWZXKljFYHPZDNWydZSt6eLcVA0O0xKZRZLssshCeaA EvUVJYSGf3ALCLcelMKWX6C5W5xRaTAzAMtjUKyG6obtYajUxRAl2W+6By4dum2yh/qj 68AGg/+yXdodSwXSUwm6AUeyIbZ2AtInOheXo4vGUXkBKRKyeEaK1MByXmXRvmKE6yoH Qa9EkGNRJmC+B4qGQ81Ey1cNMlX2vWO+gJpuSxz1xzs1/M7bxv0DtQkcH1zBQaSOt9BQ /ou4fPOvLhg6o79zbu81AJqt5cSZUQOyWGplCDo/nTFLdC2H4u/s30kTYdNMQU3R5DMX v7ow==
X-Gm-Message-State: AIVw111Q8QpI4dV7c6BULefhSYST476uSBvFr9RlY63dNzWCPD5vvvPq x89LutugjZWx1eon+Sy7xDIKIyLWsdi4zhYIxQ==
X-Received: by with SMTP id y6mr8784570uae.76.1500309162063; Mon, 17 Jul 2017 09:32:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 17 Jul 2017 09:32:41 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Carl Mehner <>
Date: Mon, 17 Jul 2017 11:32:41 -0500
Message-ID: <>
To: Roland Dobbins <>
Cc: Russ Housley <>, IETF TLS <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Jul 2017 16:32:45 -0000

On Mon, Jul 17, 2017 at 10:32 AM, Roland Dobbins <> wrote:
> On 17 Jul 2017, at 16:52, Carl Mehner wrote:
>>  Do you have an example of where malware would be on your intranet where
>> using this
>> draft would help you?
> Sure - detecting attempted additional compromise and lateral movement
> utilizing exploits within TLS-encrypted traffic.
Why is the malware setting up servers that have been explicitly
configured to use this draft and communicate with your enterprise
static key server? An common used example is metasploit, this sets up
its own keys and servers for communication and exploitation, another
is powershell empire, which sets up its own listeners rather than
using existing servers for intranet cross node communication.

> Another is detecting (and subsequent blocking of) the download of malware by
> intranet users.
Why not just use an endpoint solution and delete the malware from your
servers? Endpoint agents seem the best place architecturally for this

> Detecting data exfiltration is also a common use of this technique in
> intranet environments.
Exfiltration sounds like something done on the path towards the
Internet, where a proxy would site terminating TLS. DLP solutions
currently exist that take care of this requirement without needing
this draft.

> I understand what you're saying; but, conversely, isn't it in the interests
> of all of us working within this WG to help define practicable solutions
> that network operators can use on their own intranets to troubleshoot and
> ensure the security of those networks without requiring iatrogenic measures?
I don't think it's the WG's job to define network architecture. There
are ways to change the network that allow the necessary
troubleshooting. This goes back to Rich's question of is TLS 1.3 going
to be mandated within 5 years. If not, then you have 5 years to pivot
on architectural designs and deployed software to gain the same ends
by different means.

> Does that make more sense?
I agree that seeing the presence of superencryption is valuable.

>> I recently analyzed some malware that was sending encrypted traffic
>> back and forth nested inside TLS. But we didn't need to open up the
>> TLS stream to know that it was malware.
> Understood - you were able to user some other mechanism, like traffic
> analysis or an endpoint mechanism, to determine the the presence of this
> particular malware, yes?
> Unfortunately, this isn't always going to be the case, in many circumstances
> and contexts.
>> it wouldn't have even helped determine that the crypto was doubled.
> Was the malware in question using countersurveillance/obfuscation techniques
> that made it more difficult to infer the presence of the additional layer of
> encryption?
nope, it was reaching out to a malicious site. That's why it's a bad example.