The problem I see with the proposed configuration is that the firewall
can't/won't be able to apply any protection against attacks on
incoming SSL connections. If the SSL application is breached due to a
flaw in the server software (like what happened with ncsa httpd,
syslog, etc, etc) then the attacker is on a machine *INSIDE* your
security perimeter.
Another problem is that SSL (as usually implemented for supporting
https) can only authenticate the server (which you already trust) and
tells you nothing about the client. If SSL gave you client
authentication data (which it doesn't) then the firewall could screen
incoming SSL connections and only allow those from trustworthy
sources. Instead, the server software has to go through a bunch of
SSL transactions and then a bunch of http transactions via some series
of web pages before you can tell if the client connection comes from
someone you trust. If the connection comes from an attacker, he's had
lots of time exchanging protocol with your server, and can exploit any
bugs that may exist in the protocol software he uses.
Rick.
smith @
sctc .
com secure computing corporation
|
|
