On Wednesday, March 08, 2000 4:37 PM, John Adams [SMTP:[EMAIL PROTECTED]]
wrote:
> 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.
It also raises the bar on what someone must do to get around the policies
that I am supposed to enforce. If I don't let telnet traffic out, but let
SSL as a blind proxy out, then all someone needs to do on the outside is to
run in.telnetd on port 443 in /etc/inetd.conf to circumvent my policy. If
the firewall tracks the initialization sequences, this doesn't work, and a
more dedicated program needs to be written and deployed on both ends. Do
these programs exist now? Maybe. Can they be written? You bet. But
security is not all or nothing, with the exception of the Marcus wire cutter
firewall (I will ignore any mention of electrons quantum tunneling through
to the other wire :-) ). Its always risk against value. The vendors should
support that. I remember when I brought up checking the checksums on the
SSL data stream, the vendor shot back "that would take up too much cpu". I
responded: "then in your GUI, have two check boxes, check SSL
initialization, check SSL completely. If both are checked, then you check
everything. If I want that kind of checking, I'll buy the hardware to throw
at it. If I don't, then I have the option to turn off the checking. If I
want the middle ground, I should select SSL init only, and you should check
only that".
> Someone earlier was discussing getting at the actual data, and I was
> trying to explain to them that this was impossible.
Ok, assuming sufficient key lengths and sufficiently random random number
generators, the data should be reasonably secure.
> > 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)
Thanks I'll look there when I get a chance.
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.
*****************************************************************************
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
