On Jul 11, 2017, at 2:39 PM, Steve Fenter <steven.fente...@gmail.com> 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 realize that you are making a substantive comment here and might not welcome 
a sales pitch, but FWIW there are ways of addressing this that don't involve 
examining each stream, and are likely as effective.   E.g., malicious domain 
redirect based on the domain name in the URL.   This is a lot cheaper than 
doing decryption and inspection of the contents of every TLS stream.   It also 
allows for other methods than payload analysis for detecting probably 
malware—e.g., pattern analysis.   I'm pretty sure that Stephen will tell you 
that this is an attack as well, and he's not wrong, but it has the virtue of 
not requiring that TLS be broken.

Also, please note that the proposal you are referring to does not solve this 
problem at all, unless the malware is already on a server on your network 
(which is the scenario you are describing).   If that's the case, why is TLS 
intercept the most cost effective way to detect this malware?   It seems to me 
that it would be a lot easier to just scan the file on the server before making 
it available for download.

Can you explain why that's not the right solution for this particular use case?

Also, although there was a lot of talk about how you need to do 
decryption-and-inspection rather than using proxies for performance, that 
actually just doesn't make sense.   Is it because the proxy is too close to the 
edge, resulting in trombone routes?   Otherwise I don't see how it could 
possibly be more efficient to decrypt and eavesdrop than to proxy.   Can you 
explain?

Sorry to hold your feet to the fire, but what you are saying here just doesn't 
make sense to me.

As for threat detection, again I'm not seeing how decryption and packet 
analysis is a win here.   Can you explain?

I see why it's helpful for troubleshooting, although again a proxy would take 
care of that.   But in any case, for the other two examples, it doesn't make 
sense even from a performance perspective.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to