IDS mailing list archives
SSL and IPS (was RE: ssh and ids)
From: <Peter_Schawacker () NAI com>
Date: Thu, 24 Jun 2004 17:07:39 -0700
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. --------------------------------------------------------------------------- ---------------------------------------------------------------------------
Current thread:
- SSL and IPS (was RE: ssh and ids) Peter_Schawacker (Jun 25)
- Re: SSL and IPS (was RE: ssh and ids) Michael H. Warfield (Jun 29)