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

["Rob Shein" <shoten () starpower net>]

To determine the symmetric key that results from a DH exchange, all you need
is the private key of one party (provided here by key escrow, as Peter
Schawacker described) and the public key of the other party (captured off
the wire).  You then perform the same calculation as the party whose private
key you hold, and voila; you become a third party with the symmetric key.
This is exactly why private keys are so sensitive, and there's nothing
miraculous about it.  The same goes for any rekeys, which are also done with
DH.  They aren't breaking DH, they're just taking advantage of the fact that
their device is, like the SSL server, a trusted device which is granted
access to private keys.

> -----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!


---------------------------------------------------------------------------

---------------------------------------------------------------------------