And just to add a little icing to this whole cake, have you heard of a
company that woos folks into signing up with them to *speed up their
download times*. What really happens is a program they download from them
changes settings in their browsers to use a proxy server at the company.
What they don't exactly make entirely clear, is that any SSL connection
between the user and a web site is not really done that way. The user
actually goes secure with a server at the company. Then another server at
the company attempts to establish a SSL connection with the server the
person wanted to connect to. The only weird thing the user sees is the
first time to a particular site, the browser presents them with message
saying that the certificate belongs to (url you typed), (the companies name)
Proxy, US and asks if they want to accept it even though it *seems* invalid!
There's more, the company says in the disclosure that they'll be recording
all the data (that you thought was encrypted) and doing *market analysis* on
it (LOL). Last time I checked they were doing fantastic, signing up lot's
of folks.
Kind of makes me wonder why we're all even making an effort...
Later,
Michael Sorbera
Webmaster
Randolph-Brooks Federal Credit Union
P.S. I can't name the company because we're still contemplating whether to
try something in the legal arena...
----- Original Message -----
From: "Paul Murphy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 6:38 AM
Subject: Re: Encryption vs. inspection.
>
> A partial answer is to use host IDS on the destination machine. But this
scenario is flawed in my mind.
>
> Lets ignore SSL for the moment. In your scenario you have an unpatched
webserver that is being exploited, yet you have an IDS system that knows
about the exploit...
>
> I guess you could have a scenario where your IDS was upgraded
automatically, and the patch was overlooked.
>
> So host IDS, put an IDS sensor on the webservers that can analyse the
traffic as it is decrypted.
>
> Is that possible?
>
>
>
> >>> "Steve Riley (MCS)" <[EMAIL PROTECTED]> 6/5/2001 11:57:46 pm >>>
> 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.]
>
>
>
> --------------------------------------------------------------------------
-------------------------------------------------
> CRESTCo Ltd. The views expressed above are not necessarily
those
> 33 Cannon Street. held by CRESTCo Limited.
> London EC4M 5SB (UK)
> +44 (020) 7849 0000 http://www.crestco.co.uk
> --------------------------------------------------------------------------
-------------------------------------------------
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
