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

["Roland Dobbins" <[e-mail]>]

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.

Another is detecting (and subsequent blocking of) the download of 
malware by intranet users.

Detecting data exfiltration is also a common use of this technique in 
intranet environments.

> Thirdly, just because something is prevalent and important
> and has been used for many years, doesn't mean that it should
> continue.

Sure - but it's also important to understand the mechanisms and 
techniques which are important to network operators, and to provide 
non-burdensome, non-iatrogenic ways for them to continue fulfilling 
critical functions within their own intranet environments.

>
> Non-FS was ok, because it's "intranet", now, it is not tools and 
> designs will have to
> change.

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?

> (And since we are throwing around PCI hypotheticals.. maybe
>  PCI will mandate forward secrecy without static keys because it's 
> more
>  secure.. we just don't know.)

Agree with you 100%.  That being said, the PCI/DSS board are quite 
well-versed in the monitoring techniques utilized by relevant 
organizations, so (hopefully!) they'll take this into account, when the 
time comes.

But you're absolutely right - we just don't know.

> The bar, as Steven pointed out earlier, is for you to prove. You
> should be proving that it is necessary, not just that it is prevalent
> or easier.

The problem is that in many cases, the changes required to accommodate 
pervasive PFS within the intranet have the potential to be both 
impractical as well as iatrogenic in nature.  I completely agree with 
you that PFS is very important whenever sending/receiving traffic across 
multiple spans of administrative control, like the public Internet.

> I'm trying to get you to explain how this draft helps with that.

It helps because if the intranet network operator has visibility within 
the TLS tunnel on his own intranet, he has the opportunity to infer the 
existence of unknown and unexpected traffic types, including possible 
superencryption.

Just being able to something that looks out of place and warrants 
further investigation, without being able to instantly classify it, is 
very valuable, in a security context.

Does that make more sense?

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

-----------------------------------
Roland Dobbins <[e-mail]>