RE: [fw-wiz] tunnel vs open a hole
From: Melson, Paul (PMelson@sequoianet.com)
From: "Melson, Paul" <PMelson@sequoianet.com> To: "Dave Piscitello <email@example.com>@AICNOTES" <IMCEANOTES-Dave+20Piscitello+20+3Cdave+40corecom+2Ecom+3E+40AICNOTES@sequoianet.com>, <firstname.lastname@example.org> Date: Tue, 8 Apr 2003 15:23:27 -0400
I was hoping someone would mention this as well. HTTP tunneling is something that can be restricted or prevented using even a fairly basic application proxy, like the ones found in many modern firewall products. But tunneling SSL or SSH is what gives me nightmares, and I'd be interested to hear what other organizations do to address this.
It is my understanding that if you allow HTTP/SSL, then you must 1) allow the use of 'CONNECT' proxying, which allows a tool like `bouncer` to subvert your security policy or 2) use a MITM style SSL proxy which robs the client of verifying the server certificate, possibly making outbound SSL connections susceptible to additional MITM attacks. Worse yet, if you -don't- allow HTTP/SSL (TCP/443) traffic through your firewall, then your users may be submitting passwords in clear text across the Internet (assuming you allow HTTP through your aforementioned application proxy).
SSH is just as bad, or possibly worse, since most clients and daemons support port redirection.
> -----Original Message-----
> From: Dave Piscitello <email@example.com>@AICNOTES
> Sent: Tuesday, April 08, 2003 1:17 PM
> To: firstname.lastname@example.org
> Subject: Re: [fw-wiz] tunnel vs open a hole
> No one discussed the benefits of using an encrypted, authenticated
> tunnel (SSL, SSH, ...), which do provide additional controls. If I were
> developing/deploying a (presumably) distributed application *today*,
> I would begin with the assumption that I need stronger authentication
> than UIPW, message integrity, and message confidentiality. Many of
> the problems we struggle to correct today stem from the fact that
> we think of security as something orthogonal to application functionality
> rather than a core component/requirement.
firewall-wizards mailing list