On Wed, 8 Mar 2000, Ng, Kenneth (US) wrote:
> > No no no. It did SSL proxy by passing the SSL along. Noone can do content
> > analysis of an SSL connection, even if the entire conversation is
> > monitored through the firewall. It's mathematically infeasible.
>
> It is mathematically infeasible to get the SESSION KEY and therefore look at
> the DATA. The INITIALIZATION SEQUENCES are sent CLEAR TEXT. There is a
> HELLO sequence, there is a sequence that says the encryptions you can do,
> and then the encryptions selected. The DH public keys used to determine the
> session key is sent clear text. They have to be because at that point you
> have not arrived at a session key. All these things the application gateway
That's fine if all you want to do is ensure that you're recieving a proper
SSL startup, and it's a good rule for the FW to implement. I think it
gains us little in the way of actual security unless this sort of
algorithm can be implemented for every protocol that could possibly pass
through the firewall.
Someone earlier was discussing getting at the actual data, and I was
trying to explain to them that this was impossible.
> Also, does anyone have a URL that explains SSL in EXTREME GROSS technical
> detail? When I did the research for the previous time I found some URLs' on
> the net, but have since lost them. I'm drawing all the above material from
> memories of long conversations with the vendor about what the claim and what
> they were doing.
The SSL RFCs on the Netscape Developer Site are your best bet for this, or
the OpenSSL Site. (www.openssl.org)
-john
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
