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

• Previous message: Sasha Romanosky: "RE: Anomaly Based Network IDS"
• Maybe in reply to: Rob Shein: "RE: SSL and IPS (was RE: ssh and ids)"
• Next in thread: Michael H. Warfield: "Re: SSL and IPS (was RE: ssh and ids)"
• Reply: Michael H. Warfield: "Re: SSL and IPS (was RE: ssh and ids)"
• Reply: Michael H. Warfield: "Re: SSL and IPS (was RE: ssh and ids)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 30 Jun 2004 13:39:38 -0700
To: <shoten@starpower.net>, <focus-ids@securityfocus.com>

Rob,

Thanks for the comment. What we're doing is really pretty simple. All
an IPS/IDS vendor needs in order to build the same functionality into
their own product is a fast, robust platform (a PC server won't hack
it), development resources (capital) and some vision. In fact, I expect
that whilst certain IDS/IPS vendors are attacking McAfee's decryption
feature, they are quietly working on their own. Some of you may recall
the great hew and cry of last year over IPS. Many people with vested
interests in the failure of the IPS paradigm laid on the FUD at that
time. Now those same vendors offer inline blocking and the FUD has
ceased.

I think we've taken this topic as far as we can on this list. There is
no question that the technology works -- we've had it in beta in real
world networks. The most important question is, "How will the market
value this technology?" Only real-world implementations and time will
tell. Let's just let the market decide the value of IPS decryption,
shall we?

Thanks, Mike (ISS), Marty (Sourcefire) and Jason (Sourcefire) for your
questions and comments. Let's have this chat again six months from now.
;-)

Over and out.

Peter Schawacker, CISSP
Technical Evangelist
McAfee
Office 760 200 4258
Mobile 760 880 4258
ps@nai.com

-----Original Message-----
From: Rob Shein [mailto:shoten@starpower.net]
Sent: Wednesday, June 30, 2004 1:29 PM
To: 'Michael H. Warfield'; Schawacker, Peter
Cc: security@brvenik.com; focus-ids@securityfocus.com
Subject: RE: SSL and IPS (was RE: ssh and ids)

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

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

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

• Previous message: Sasha Romanosky: "RE: Anomaly Based Network IDS"
• Maybe in reply to: Rob Shein: "RE: SSL and IPS (was RE: ssh and ids)"
• Next in thread: Michael H. Warfield: "Re: SSL and IPS (was RE: ssh and ids)"
• Reply: Michael H. Warfield: "Re: SSL and IPS (was RE: ssh and ids)"
• Reply: Michael H. Warfield: "Re: SSL and IPS (was RE: ssh and ids)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]