On 6/21/07, Chuck Kollars <ckollars9@xxxxxxxxx> wrote:
I think what we really need is just the much simpler blacklist/whitelist capability. If we can transparently intercept, and give a thumbs-up/thumbs-down to every destination IP address (perhaps after doing a reverse DNS lookup on it), that's all we need.
No need to transparently intercept for this, and no need for new code. Just configure the client to proxy SSL via Squid, and use the existing ACLs to set the policy for the 'CONNECT' method, similar to what I showed in a previous post in this thread.
In my experience, fingerprinting the type of traffic turns out to not be very useful ...after all the difficulty of implementing it. Why?
Fingerprinting is relatively easy, but is not nearly as effective (or invasive) as doing true MITM where you actually break the end-to-end encryption to inspect the payload.
1) There's "legitimate" traffic on 443 that's not web traffic (for example LogMeIn or SSH). Forbidding everything that's non-web is just shooting yourself in the foot.
I strongly disagree: LogMeIn and SSH-over-443 are illegitimate, and should be forbidden in any environment with real security policy (that is, anywhere except a public ISP).
2) A big problem is https: proxies, as they're real easy to use and will completely bypass all filters. But they _do_ look like web traffic, so they couldn't be forbidden by reasonable fingerprinting.
True. That's where a blacklist/whitelist for general HTTPS traffic comes in. Or better yet, use real MITM interception, and the https: proxies no longer bypass your filters, since no SSL/TLS traffic can make it out of your network alive. Kevin
