Paul,
Thanks for the quick and understandable reply. I have a few clarification questions if
you'll please allow me...
First, I'd like to generically explain my situation....
Our web server does not have any "users" connected to it. It's only function in
life is to serve up html, no java, just plain old html with a little javascript embeded
in it. We are about to role out our "online banking" portion of the site. I plan on
forcing that section to use SSL.
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?
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.
Please be gentle, remember I'm new to this arena.
Thanks in advance,
Michael Sorbera
Webmaster/Network Engineer
Randolph-Brooks Federal Credit Union
www.rbfcu.org
[EMAIL PROTECTED]
Paul D. Robertson wrote:
> On Thu, 4 Feb 1999, Michael Sorbera wrote:
>
> > Hello everyone,
> > Paul, you mentioned that SSL was one of your "no's". Could you please explain to
> > me how SSL can be used to encapsulate something? Also why the no? Please keep
>
> Any protocol can be used to encapsulate any other protocol. I'll give
> some examples, then explain why I think SSL has more risk:
>
> RealAudio can be encapsulated over HTTP. If you block "normal" real
> audio, it doesn't matter if people can use HTTP to get that same protocol
> encapsulated in an HTTP conversation. By the same token, most any
> protocol can be encapsulated over HTTP. It's now the default "tunnel out
> of the firewall for a new application" protocol because almost nobody
> blocks it anymore. Heck, you can install OpenBSD on a machine through a
> proxy using a single floppy these days.
>
> All of your wire protocols can be encapsulated over SMTP. All it takes
> is a single program to sniff the wire, UUencode or MIME encode all the
> packets and e-mail them to the other end, then that machine needs a
> program to UUdecode or unMIME the packets and put them back on the wire.
>
> The obvious issues are (a) tracking utilization, and (b) having a level
> of trust in the configuration of client software. Unfortunately, these
> days it's difficult to do (b) by telling people they can, for instance,
> only run approved browser and e-mail software. Worse yet when you take
> companies like Microsoft embedding that functionality into OS DLLs where
> even a non-browser application can intercept the communication of what
> may be a trusted browser by altering a DLL you move pretty quicly to
> having to not allow non-approved software and then having to establish a
> mechanism of testing/approving applications.
>
> Ok, so now we've pretty much ascertained that the next version of (pick a
> trojan - BackOriface is rumored to have HTTP tunneling in development) is
> a significant risk despite almost everything we can do at the firewall
> other than tracking. In an ideal world, we could limit client types (if
> I get a chance I expect to put cryptographic version authentication into
> a test copy of Mozilla for research), limit the size of things like POST
> methods and all kinds of things like that.
>
> HTTP is *not* an application layer protocol, it's a transport protocol
> (it's even in the name) working at the application layer.
>
> Now, take that HTTP traffic and encrypt it so that network administrators,
> intrusion detection devices, and everything else can't possibly monitor or
> trend on it and you've got SSL. A nicely encrypted tunnel out of your
> network with minimal overhead (normal TCP and the CONNECT headers) that
> you can't possibly control, trend, or even see what damage is happening
> if you happen to discover it being used as a tunnel. Maybe that's not a
> big deal to you, but it is to me.
>
> I'm also looking at what it would take to modify Mozilla to use HTTP to
> the proxy and let the proxy use SSL out. That would leave me enforcing
> the same traffic that I do with normal HTTP, and might be advantageous
> under some circumstances.
>
> I'd probably rewrite the https:// method to mitm:// or something like
> that. If anyone wants to beat me to it, I'd be interested in talking
> with them (my time to play seems more limited every day).
>
> For me, the business advantage of allowing SSL would have to be *extremely*
> convincing to even allow it to selected sites by selected authenticated
> users using only approved software. My users want to visit their stock
> brokers and their banks - that doesn't seem compelling to me from the
> business perspective. If those users are willing to allow what's basicly
> a Man In The Middle (MITM) attack on their transactions then I could see
> permitting it under limited circumstances. It's an extension of trust
> issue, I'm not willing to extend trust down to insecure desktop machines
> to that extent, so the users will have to be willing to extend trust up
> to me. That would include signing a letter of understanding prior to
> being allowed access to the service should I be able to make it work
> seamlessly. I'd probably also mean a lot more switched network
> infrstructure.
>
> > the explanation down to a level I can understand.
>
> SSL - making a bad protocol worse.
>
> HTH,
>
> 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.]
