SSL and IPS (was RE: ssh and ids)

[<Peter_Schawacker () NAI com>]

Jason,

Great questions.  You'll find answers in-line.  I reformatted your
questions for the sake of clarity.  Hopefully I haven't  distorted the
meaning of your original message.

Cheers,

Peter

Peter Schawacker, CISSP
IPS Technical Evangelist
McAfee
Office 760 200 4258
Mobile 760 880 4258
ps () nai com


-----Original Message----- 
From: Jason [mailto:security () brvenik com] 
Sent: Mon 6/21/2004 7:54 PM 
To: focus-ids () securityfocus com 
Cc: 
Subject: Re: ssh and ids

Martin Roesch wrote:

[...]

> I know the NAI guys just released a mod to their sensors that allow 
> them to do real-time SSL decryption...

"This is an interesting area I think deserves more conversation. I want
to toss out a few questions and hopefully someone  will have first hand
experience and can elaborate."

"Simply doing the escrow of the private key allows the capture of the
symmetric key but...
How many simultaneous SSL sessions can be tracked?"

On the I-4000 sensor, IntruShield supports a maximum of 100,000
connections and 200,000 sessions.  

"What are the DoS potentials to detection by forcing a constant rekey?"

I assume you're talking about a case in which the client constantly
tries to create new sessions, which would then require  large numbers of
RSA decrypts.  This becomes a capacity planning exercise. 

"How is spoofing handled? If you walk the possible session id space and
attempt a connection you force every existing session  to rekey and
tracking of each possible session for a period of time, this is
expensive to track."

I'm not sure I understand what you mean here.  A session ID is 32-bytes.
For comparison, a SHA-1 hash is 20-bytes and there  are no known hash
collisions.  The server chooses the session ID, so it's essentially
impossible for a client that's not in  on the session creation to guess
it without a broken server implementation.  Even if an inappropriate
client guesses the  session id, it doesn't affect any other SSL
connections.  If I've missed the mark, please try me again off-list and
I'll take another crack at your question.

"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.

"When inline what performance impact can be imposed on the network with
a $300 SSL accelerator card and a Perl script?"

Indeed, SSL DoS isn't very difficult, IntruShield or no.  Why bother
with the SSL accelerator?  :-)  Just rebroadcast the  same handshake
over and over again, and both the sensor and the SSL server will do an
RSA decrypt for each connection.  The  handshake will eventually fail
due to some security checks, but the server has already paid the RSA
price.  This is basically the same question as the constant rekey
question above.  Your point is a fair one.  It doesn't take much
creativity to bring anything that needs to do RSA decrypts to its knees.

"What ciphers are supported?"

SSLv2 Cipher Suites
- SSL_CK_RC4_128_WITH_MD5
- SSL_CK_RC4_128_EXPORT40_WITH_MD5
- SSL_CK_DES_64_CBC_WITH_MD5
- SSL_CK_DES_192_EDE3_CBC_WITH_MD5

SSLv3/TLS Cipher Suites
- TLS_NULL_WITH_NULL_NULL
- TLS_RSA_WITH_NULL_MD5
- TLS_RSA_WITH_NULL_SHA
- TLS_RSA_WITH_RC4_128_MD5
- TLS_RSA_WITH_RC4_128_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA

"How are new ciphers handled?"

A new cipher suite requires a change to the sensor software, which can
be updated remotely.  New cipher suites are released  very rarely, by
the way.  The only one that's been released since the original SSL RFC
is AES.

"What if an unsupported cipher is used?"

If a connection is negotiated for which IntruShield has the private key,
but it doesn't support the cipher suite, the sensor  raises a system
event.  This shows up in the IntruShield user interface and directs the
user to configure the server to only  allow supported cipher suites.
Obviously, that connection won't be followed.

"Does it validate the trust chains?

No, because there's really no reason to do so.  The server is obviously
trusted, since the key is loaded into the sensor.   The client
certificate will be validated by the server (which we trust), and if it
doesn't like it, it will send an SSL alert  message and kill the
connection.  

"Anything in the SSL session?" 

I don't know exactly what you mean.  As above, we assume the server is
trusted, so we count on it to detect things it doesn't  like.  We have
signatures defined for attacks against SSL server vulnerabilities, but
we've been able to do that in the  sensor for a long time.

"Time..."

There is no concept of time in SSL other than how long a session can be
resumed.  This is configured in the manager and needs  to match the
server's value.

"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."

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.  

"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 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.

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

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