-----Original Message-----
From: Michael H. Warfield [mailto:mhw () wittsend com]
Sent: Friday, June 25, 2004 8:46 PM
To: Peter_Schawacker () NAI com
Cc: security () brvenik com; focus-ids () securityfocus com
Subject: Re: SSL and IPS (was RE: ssh and ids)
On Thu, Jun 24, 2004 at 05:07:39PM -0700,
Peter_Schawacker () NAI com wrote:
"Simply doing the escrow of the private key allows the
capture of the
symmetric key but...
Whoa! TIME OUT!
This sounds like a TAMO (Then A Miracle Occurs). That
cloudy fuzzy step from "escrow of the private key" to
"capture of the symmetric key", that TAMO, definitely needs a
LOT more detail.
Are we talking about the private key associated with
the server's certificate? How in blue blazes does that allow
the capture of the symmetric key? The symmetric key is
negotiated using Diffie-Hellman. It could take place in the
clear and you could not capture the symmetric key even
capturing every bit of data exchanged between the two
parties. If you are not actively engaging in a MITM attack,
you are not going to sniff that and derive the session key
unless you have some access to the individual D-H exponents
on one side or the other. Has absolutely nothing to do with
the authentication or the certificates. Basic D-H key exchange.
:
"When passive what happens if a rekey is missed?"
If a rekey (renegotiation in SSL parlance) is missed, we
won't be able
to follow the flow. I can't imagine this is a very common issue
unless we're under intense load. Also, renegotiation happens very
rarely in normal HTTPS transactions. The client can request
renegotiation, but the server doesn't have to accept it.
Wait a minute. Isn't a rekey handled by Diffie-Hellman
as well? That's the whole principle behind perfect forward
secrecy (PFS). Even if someone busts one ephemeral session
key and listens to the entire key exchange for the next
session key, they still won't have the next session key.
That's a fundamental concept in PFS. This is basic
cryptography here, folks... If the SSL designers screwed
that one up they qualify for a slug-out tie with the
crypto-tards ("Who forgot to invite the cryptographers to the
design meetings?") at IEEE who designed WEP for WiFi.
:
"How does it handle client certs? It cannot possibly know
the private
key for client certs too. IIRC, some servers allow
client/server key
negotiation without requiring authentication."
Ok... So, this tends to confirm that you are referring
to the private key associated with the X.509 certs when you
are referring to the "private key" and not merely using a
misnomer for the internal secret D-H parameters. That
strengthens my arguement that there is no way, even with the
server's private key, to follow the key exchange and recover
the session key. If there were, that, in and of itself,
would qualify as a security advisory and probably make the
annuals of cryptography.
IntruShield can detect attacks without any problems when client
authentication is used. I'm glad you brought this up because it
seems to be a common point of confusion. Client authentication
doesn't affect the keys that are used to encrypt the traffic. The
client just encrypts some data from the handshake with its
private key
that the server verifies with the public key from the
certificate.
Once again, we assume a trusted server that's going to
authenticate the client.
Now HERE is a true statement... "Client authentication
doesn't affect the keys that are used to encrypt the
traffic." VERY true. Because the keys that are used to
encrypt the traffic are negotiated through D-H. That also
means (through induction) that "Server authentication doesn't
affect the keys that are used to encrypt the
traffic." There is no asymetery in SSL that would dictate
that the server authentication would do something to the
symmetrical keys that the client authentication would not.
So how does that get you the session keys, which are derived
on a session by session basis and used for the symmetrical
cryptography, from the server's PK private key? I would love
to see the math here...
"I understand that the intent is to detect attacks over known SSL
channels but these are issues I would like to explore deeper. I do
not think it is possible to properly handle the SSL case without
terminating and watching behind the termination point and
even then
it does not gracefully handle the client cert issue gracefully when
authentication is involved."
I agree whole heartedly with the above statement and
the descriptions of how this is "proported" to work have
reinforced my opinion that this is snake-oil, at least the
descriptions are. What ever it really is, the explanations
above are not cryptographically sound.
I hope I was able to change your mind. If you have any other
questions regarding how IntruShield handles SSL sans termination,
please contact me off-list.
I don't know about the others on this list but you've
convinced me that you're parotting some marketing line laced
with some cryptographic jargon that really doesn't make
sense, cryptographically. I would love to hear some
enlightenment as to HOW you are breaking D-H and yet are not
a featured article in Bruce Schneier's Cryptogram. You might
yet be... He does have a snake-oil section. I may nominate you.
----------------------------------------------------------------------
-----
----------------------------------------------------------------------
-----
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw () WittsEnd com
/\/\|=mhw=|\/\/ | (678) 463-0932 |
http://www.wittsend.com/mhw/
NIC whois: MHW9 | An
optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is
sure of it!
Intro
