On Jan 30, 2008 6:56 PM, Ben Scott <[EMAIL PROTECTED]> wrote: > On Jan 30, 2008 9:17 PM, Kurt Buff <[EMAIL PROTECTED]> wrote: > > The only cure is an application proxy that actually understand the > > protocols, and enforces them, and that's nearly unobtainable. > > It's not actually that rare. It's a Simple Matter of Programming to > confirm that the traffic on TCP/443 actually is SSL. (As I'm sure Tom > will point out, ISA Server can do this (I believe)). The real problem > is that SSL, by design and intent, prevents you from looking inside > the secure tunnel. (If it didn't, it wouldn't be very secure, now > would it?) You don't know what the SSL tunnel is being used to carry. > Could be HTTP. Could be a backdoor to an attacker.
SMOP? Not quite - I don't know of any application proxy that actually does well with all of the verbs, etc., in the HTTP suite, especially when you throw javascript, xml, activeX controls, etc., etc., etc. at it. I do know of at least one firewall that will decrypt SSL as it passes through, though, for inspection purposes - of course, that means some tricky work with certs, but even assuming that, you have the underlying protocol that's being tunneled, and if it's not HTTP, then it gets really tricky. For instance, how about RPC/HTTPS? Basically, it's MAPI over SSL - know any good application layer proxies for that, which will robustly interpret and enforce correct semantics for that protocol? I'll bet even ISA won't do what we really want it to do for enforcement of MAPI over SSL. > Default deny with whitelisting of SSL sites is one approach, but > that's an obvious hassle. Yes, and I'm nearly ready to go there. > Approaches which explicitly open the payload to trusted inspection > have been proposed. The idea is, have the client software create an > SSL tunnel to the proxy. Using a special protocol over that > connection, the client requests an SSL tunnel to the real destination. > The proxy creates that SSL tunnel. The client then sends the payload > (without further encryption) over the tunnel to the proxy, which can > inspect it and (if it passes inspection) forward it over its own SSL > tunnel. Special protocol - ye gods, another one? Will it have its BNF diagram ready to go? > The problem is there are no standards for this (that I'm aware of), > and there are cases which are non-trivial to handle. (What if the > remote's CA is unknown? What about client certificates?) Even if we > get standards, adoption is going to take some time. There are also > obvious security implications with deliberately defeating the > end-to-end security model. Presumably one can manage that risk > internally, but it's still an issue. > > -- Ben I say, let's kill all the users - then we'll have good security, eh? :) Or maybe just the programmers. Or protocol designers, or ... :):) It's terribly frustrating. Kurt ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~
