I think we all here agree that encryption is a good thing. I won't
preach to the choir by enumerating the reasons. But what about when
encryption prevents legitimate inspection? This has been on my mind
lately, and I'll admit that I haven't really figured out yet where I
stand, if indeed it's even possible to choose sides.
Consider a web server. Normally, the site can be quite well secured with
various combinations of firewalls, intrusion detection, and content
inspection. ISA Server's HTTP filter is quite good at this. The site can
know what's coming in and going out, and take appropriate action based
on what it sees. But what if, instead of regular in-the-clear HTTP, the
traffic is SSL? Now you've just gotten around the firewall and the IDS:
there's no way to know what's passing through. The server accepts the
traffic and does whatever its told.
Would the following not-entirely-well-considered rumination be a
possible scenario? An attacker uses an SSL-enabled tool to compromise a
web server. This tool just happens to exploit the latest discovered
vulnerability. The server, unfortunately, hasn't yet been patched. The
tool uses SSL to get past firewalls and IDSs, and that's the key, since
the site's network has an IDS that would have been triggered had the
tool used clear-text HTTP. Now the attacker has control of one box, and
can use it to compromise the entire network -- all over SSL and
practically invisible to the watchers.
I'm curious to know how others have approached the intersection of the
seemingly incompatible technologies of encryption and inspection. Is IDS
really all that useful, for example? Is it best to put SSL web servers
in a separate subnet, kept apart from the rest of the DMZ by yet another
firewall? Hardware accelerators (and even ISA) can decrypt then
re-encrypt traffic, but wouldn't this appear to break the chain of
trust, since I as a user don't know that an intermediate device --
rather than the destination web server -- is actually decrypting the
traffic? Does the desire to "know everything going in and out of my
network" mean that I should block all IPSec?
___________________________________________________________
Steve Riley
Microsoft Telecommunications Consulting in Denver, Colorado
[EMAIL PROTECTED] +1 303 521-4129 (mobile)
[EMAIL PROTECTED] (MSN Messenger)
www.microsoft.com/ISN/tech_columnists.asp
<www.microsoft.com/ISN/tech_columnists.asp>
Applying computer technology is simply finding the right wrench to pound
in the correct screw.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
