SSL and IPS (was RE: ssh and ids)

Peter_Schawacker_at_NAI.com
Date: 06/25/04

  • Next message: Barry Fitzgerald: "Re: Anomaly Based Network IDS" 
    Date: Thu, 24 Jun 2004 17:07:39 -0700
To: <security@brvenik.com>, <focus-ids@securityfocus.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.

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

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

  • Next message: Barry Fitzgerald: "Re: Anomaly Based Network IDS"

    Relevant Pages

    • Re: Antw: Re: LDAP Authentication Problem
      ... TLSv1 und wird auf einen SSL Client Hello Request mit TLSv1 nicht ... antworten anstatt ein SSLv3 Server Hello. ... the LDAP PAM module and the shadow package. ...
      (de.comp.sys.novell)
    • Re: SSL/TLS & renegotiation and Internet Explorer
      ... When IE closes the connection with the server and prompts the user to choose ... recovery logic the SSL session is discarded. ... If the user only has one suitable client certificate, ...
      (microsoft.public.security)
    • Re: RDP Printing by station
      ... flagged as non-printing stations can not print for ANY users. ... multiple NIC's on the terminal server. ... I'd then just have to ensure that the client stations that are ... session is limited to NIC # 1. ...
      (microsoft.public.windows.terminal_services)
    • Re: Using SSL with IIS 5.0 - how does it work.
      ... Description of the Secure Sockets Layer (SSL) Handshake ... username and password when users authenticates to server (e.g. to check ... his/her e-mail) (client sends this data to the server) ... If you want your users to trust your SSL certificate ...
      (microsoft.public.inetserver.iis.security)
    • Trying to setup FreeNX
      ... I've installed FreeNX server and the NX client from ... Below is a copy of the failure as recorded by my NX client trying to ... NX> 103 Welcome to: bhf user: bob ... NX> 703 Session type: unix-kde ...
      (alt.os.linux.suse)