Re: SSL and IPS (was RE: ssh and ids)

["Michael H. Warfield" <mhw () wittsend com>]

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!

Attachment: _bin
Description: