Re: Inspecting encrypted traffic

[Jim Cheetham <jim.cheetham () OTAGO AC NZ>]

Excerpts from Angelo Rodriguez's message of 2016-01-21 05:10:06 +1300:
> Without SSL inspection, limited URL filtering can be done (using cert common name) but you cannot block keywords, 
> perform complex filtering or inject block/splash pages. Likewise applications might show up as “https” or “SSL” so 
> app visibility and control may be limited. Threats via IPS, malware and other vectors will also be hidden from the 
> DPI engine and go right through (the way they do now on many legacy FW’s or those that are not inspecting SSL). Our 
> own analysis from +1m active sensors (NGFW’s) shows encrypted traffic levels at nearly 60% and growing faster than 
> http. In some places it will be lower/higher of course.

You are correct, if you build your expectations of security enforcement
around "the network" being a use-case-neutral platform that has to affect
the security posture of your users, then you need to invest in content
inspection like this, even though your return on investment in terms of
coverage is already diminishing the gains in visibility you get in the
short term may well be compelling.

On the other hand, *with* TLS inspection MITM in place, you break an
increasing number of applications that correctly verify ("pin") their own
certificates, and therefore refuse to operate at all. Applications using
DANE (DNS-based Authentication of Named Entities, built on top of DNSSEC)
should also block in the face of MITM.

Increasingly, if an application is found that allows a MITM to proceed,
this is treated as a vulnerability, and fixed. The whole model of trusting
"any CA" to issue a given target certificate is being seen as damaged.

For most networks, this rejection of even an OS-blessed MITM represents an
effective false positive rate that is unacceptable. Causing perfectly
valid applications to fail is not seen as a good result.

Additionally, the typical vendor inspection regime requires the inspection
CA to be installed and trusted on end-user devices; this is only
successful if you already control the endpoints, and in a student/BYOD
environment (and increasingly an Internet of Broken Things) this
requirement cannot be met completely, if at all. In any case, the
administration & support costs are significant.

> Think of all the common use sites/apps (anything Google or MS, most social media sites, CRM  and ERP, financials, 
> medical, etc) that introduce threat vectors if they are not being inspected (via MitM or similar). Inspection is 
> required to peform full URL, App control, IPS and malware prevention else, in effect you are only protecting ~50% of 
> your traffic/users.

Yes, but that's only part of the "Cloud Security" picture anyway.
Separating out data domains within the network is the better long-term
approach, and from my perspective you're better spending money there,
rather than chasing the closing door of network-based content inspection.

-- 
Jim Cheetham, Information Security, University of Otago, Dunedin, N.Z.
✉ jim.cheetham () otago ac nz    ☏ +64 3 470 4670    ☏ m +64 21 279 4670
⚷ OpenPGP: B50F BE3B D49B 3A8A 9CC3 8966 9374 82CD C982 0605

Attachment: signature.asc
Description: