Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Steve Fenter <[e-mail]>]

> On Jul 11, 2017, at 2:15 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> To add to Ted's clarification requests:
> 
>> On 11/07/17 19:39, Steve Fenter wrote:
>> Network security monitoring is not just monitoring traffic that
>> results from communications with customers and partners.  All it
>> takes is for one user to click on a phishing email and there is
>> malware inside the enterprise.  Once this happens, TLS becomes the
>> enemy, because 30% of malware is TLS encrypted, and any TLS features
>> intended to thwart payload inspection work against the enterprise.
> 
> I'd appreciate a citation for that 30% figure.

30% came from Cisco Systems at a recent Cisco Live conference.  Their numbers indicated 10% in 2015 and 30% today
> 
> And if you had one an estimate for how much malware does it's own
> obfuscation or home-grown crypto in addition or instead of using TLS.
> The reason to ask is that as soon as malware does that then you
> are back to analysis based on ciphertext only. From descriptions
> of advanced attack schemes, they do seem to do both when calling
> home or exfiltrating data. In which case I think your argument
> falls.

I don't have any numbers for home-grown crypto.  I would think the odds are better for the enterprise if they can decrypt and inspect whatever portion is TLS.
> 
>> Malware does not always phone home out to the Internet on day 1 of
>> infection.  
> 
> In what circumstance will malware phone home to a TLS server that
> is playing your wiretap game? That seems utterly illogical but
> maybe I'm missing a reason why someone's malware will use TLS to
> talk to a server that is controlled by the victim network as part
> of phoning home. Please clarify.

Phone home would have to be caught by an inline solution on the way out the Internet.  I was just suggesting that malware could be caught earlier in the process with multiple inspection points throughout the enterprise.
> 
> S.
>