On 1/30/08, Ken Schaefer <[EMAIL PROTECTED]> wrote: > Kurt Buff wrote: > > 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, > > Who said that the traffic has to be HTTP? Over SSL/TLS you can send whatever > you like, and the proxy would not know any different. > > And that is the problem - if some wants to do something bad (either an inside > job, or a malicious outside attacker that comprises your machines through > malware), they can just use the universal firewall bypass port :-)
See my last comment, below. heh. > > 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, > > Really? How does this work? SSL/TLS is designed to be resistant to exactly > this > form "inspection", otherwise it would be possible to mount MitM attacks > against > SSL/TLS. I don't know. I do know that it's one we're installing - cutting over on Friday, but we didn't pay for that option, nor for the add-in board that would be useful to go with it. > > 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 > > No - RPC over HTTPS can be any RPC traffic. You can tunnel ADO over HTTP if > you want. Or almost any other type of RPC traffic. All that's required is > that the > client library support it. > > MAPI is just one client that supports such tunnelling. I see - well, I suppose that makes it all better then, doesn't it? :) Kurt ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~
