On Thu, 4 Feb 1999, Michael Sorbera wrote:
> Here's the clarification questions/comments...
> You're concern with SSL seems to be that someone could maliciously get some nasty
> code through whatever defenses you have and into your "internal" network. (or the
> opposite way) Am I on the right track here?
Yep.
> Since I have nothing other than the web server to protect, what could possibly be
> "tunneled" into my web server that could do me harm? (I know I'm gonna regret saying
> that!) I don't allow any PUT of any kind, no FTP, just HTTP and SSL.
PUT, like POST is an HTML method, if you get information from the user
you do it. Web sever security is a different issue than network
security, and its focus should be the integrity of the computing base -
that is access to the machine, the programs that interact with users,
etc. In my opinion (and I'm sure there are disenting ones) if you've
done the right homework in selecting the Web server platform, a
traditional "firewall" in front of it has no useful value (packet
filtering still has the "eggs and baskets" value of a first-layer defense).
Web server security is all about host and application security -
tunneling shouldn't be an issue (unless it's tunneling customer data
after exploitation). Every service the server allows needs to be trusted
at some level - remote administrative logins if allowed (I probably
wouldn't - especially from the Internet), DNS services if used (again, I
probably would disable these), the TCP/IP stack (including its handling
of redirects), the HTTP daemon itself, the SSL encryption engine, any
server-side scripts, the change mechanism for the HTML pages...
The problems arise because people setting up server machines typically
don't have the expertise or resources to evaluate all of the above (heck-
even if you did you'd still have a chance of getting it wrong). I happen
to think that long-term trust or privacy models in the OS start to
address much of this. Short term, there's a fair body of knowledge built
up in host security and a reasonable body of knowledge for any particular
OS.
Since firewalls really isn't the right venue for server host security
discussions I'll cut this short with a more on-topic finish - if
you're allowing SSL and you're comfortable that the sites your users are
connecting to know enough about host security to never get compromised,
then the tunneling risk is lessened except in the case of a targeted
attack or bad employee. While I happen to think that MLS systems can
provide "Can't be broken into over the Net" Web servers, the number of
places buying, or capable of configuring such beasts is pretty low.
Given the Web server compromises that happen daily (for any
general-purpose OS that is fairly well represented in the server community)
and the fact that people think SSL *is* security, compromising a Web server
offering such services and getting the end-user to download an application
would seem to be fairly trivial. Heck, my bank won't even use its own
domain and server certificate.
I'd be happy to discuss this more in private e-mail, but I think
host security outside of the risks involved in connecting to such
machines or when applicable to firewalling or firewalled systems is
probably mostly off-topic on this list.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
