SSL Keywords

You can use SSL rule keywords to invoke the Secure Sockets Layer (SSL) preprocessor and extract information about SSL version and session state from packets in an encrypted session.

When a client and server communicate to establish an encrypted session using SSL or Transport Layer Security (TLS), they exchange handshake messages. Although the data transmitted in the session is encrypted, the handshake messages are not.

The SSL preprocessor extracts state and version information from specific handshake fields. Two fields within the handshake indicate the version of SSL or TLS used to encrypt the session and the stage of the handshake.

ssl_state

The ssl_state keyword can be used to match against state information for an encrypted session. To check for two or more SSL versions used simultaneously, use multiple ssl_version keywords in a rule.

When a rule uses the ssl_state keyword, the rules engine invokes the SSL preprocessor to check traffic for SSL state information.

For example, to detect an attacker’s attempt to cause a buffer overflow on a server by sending a ClientHello message with an overly long challenge length and too much data, you could use the ssl_state keyword with client_hello as an argument then check for abnormally large packets.

Use a comma-separated list to specify multiple arguments for the SSL state. When you list multiple arguments, the system evaluates them using the OR operator. For example, if you specify client_hello and server_hello as arguments, the system evaluates the rule against traffic that has a client_hello OR a server_hello.

You can also negate any argument; for example:


!client_hello, !unknown

To ensure the connection has reached each of a set of states, multiple rules using the ssl_state rule option should be used. The ssl_state keyword takes the following identifiers as arguments:

ssl_state Arguments

Argument

Purpose

client_hello

Matches against a handshake message with ClientHello as the message type, where the client requests an encrypted session.

server_hello

Matches against a handshake message with ServerHello as the message type, where the server responds to the client’s request for an encrypted session.

client_keyx

Matches against a handshake message with ClientKeyExchange as the message type, where the client transmits a key to the server to confirm receipt of a key from the server.

server_keyx

Matches against a handshake message with ServerKeyExchange as the message type, where the client transmits a key to the server to confirm receipt of a key from the server.

unknown

Matches against any handshake message type.

ssl_version

The ssl_version keyword can be used to match against version information for an encrypted session. When a rule uses the ssl_version keyword, the rules engine invokes the SSL preprocessor to check traffic for SSL version information.

For example, if you know there is a buffer overflow vulnerability in SSL version 2, you could use the ssl_version keyword with the sslv2 argument to identify traffic using that version of SSL.

Use a comma-separated list to specify multiple arguments for the SSL version. When you list multiple arguments, the system evaluates them using the OR operator. For example, if you wanted to identify any encrypted traffic that was not using SSLv2, you could add ssl_version:ssl_v3,tls1.0,tls1.1,tls1.2 to a rule. The rule would evaluate any traffic using SSL Version 3, TLS Version 1.0, TLS Version 1.1, or TLS Version 1.2.

The ssl_version keyword takes the following SSL/TLS version identifiers as arguments:

ssl_version Arguments

Argument

Purpose

sslv2

Matches against traffic encoded using Secure Sockets Layer (SSL) Version 2.

sslv3

Matches against traffic encoded using Secure Sockets Layer (SSL) Version 3.

tls1.0

Matches against traffic encoded using Transport Layer Security (TLS) Version 1.0.

tls1.1

Matches against traffic encoded using Transport Layer Security (TLS) Version 1.1.

tls1.2

Matches against traffic encoded using Transport Layer Security (TLS) Version 1.2.