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

[Carl Mehner <[e-mail]>]

On Mon, Jul 17, 2017 at 10:32 AM, Roland Dobbins <[e-mail]> 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
issue.

> 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?
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.