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.]
