On Tue, 5 Jun 2001, Steve Riley (MCS) wrote:
> I think we all here agree that encryption is a good thing. I won't
Not really, I think encryption can be a bad thing - as can tunneling in
general, hence my article in the last Information Security Magazine
issue...
> 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.
Nothing is ever "good" or "bad", only its uses.
>
> 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.
It's worse on the client end, since supposedly on the server end you can
at least do normal HTTP through a proxy mechanism after the SSL tunnel is
broken out and then do all the NIDS or whatever that makes you happy.
Clients are much less well-protected and everyone's firewall just tunnels
HTTPS right on through.
> 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.
If it's Internet-connected, you'd better be (a) keeping it very up to
date, and (b) watching its logs. By the time your IDS vendor has the
attack all figured out and added, (a) will probably have covered it.
> 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
If your SSL servers are serving normal HTTP, or other non-encrypted
protocols, you're already breaking the encryption boundary for that
particular host.
> 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
They don't know when the database at the backend is queried from an
unencrypted client on the backend, or when the administrator shares out
the drive, or what happens to the backup tapes... The "trust" isn't the
best anyway- but breaking the encryption is going to happen somewhere in
the path, so doing it in front of the transaction server probably isn't
that bad. SSL works ok for protecting information in transit, but
nobody's really attacking the information in transit at the moment, so
it's not like it's a huge win or like breaking the boundary after transit
is that big of a deal.
> traffic? Does the desire to "know everything going in and out of my
> network" mean that I should block all IPSec?
It means you should evaluate how hardened the endpoints are and how far
out you want to extend trust. The extension of trust shouldn't change
because of in-transit protection, just the issues with the channel's
protection and the confidentiality of the information should be given a
higher assurance for the points where it's encrypted.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
