On Wed, 8 Mar 2000, Ng, Kenneth (US) wrote:
> You want the truth? I caught one major firewall vendor in a big lie over
> this one. Their so called proxy was nothing more than a transparent
> connection, yet when I asked them if I put a telnet daemon on another
> machine on port 443, if their proxy would block it, they said it would. I,
> of course, tried it, it didn't. They backpedeled saying their wasn't
> anything they could check because its all encrypted. I countered that the
> hello sequences and the public key exchange sequences were all in clear
> text.
*No* current _firewall_ vendor handles SSL correctly. I've been crusading
on that point for the last few *years* and it's a lost cause. Some were
waiting for key escrow to happen, and others didn't understand the nauture
of the beast or didn't want to deal with exporting the encryption
required to do the client side of things. I even gave two vendors a
step-by-step of how to man-in-the-middle an SSL connection as a valid
proxy, and they weren't interested in spending the time to try it out.
I'm still of the opinion that anyone passing unbounded SSL to clients on
the internal network needs their head examined, connect method or not.
Netscape actually had a reverse SSL feature in their proxy a while back
that would have been a good start.
Other options are hacking the Mozilla source and adding a new method or
using a remote display protocol to allow SSL from a machine outside the
firewall.
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.]
