SSL Profiles Part 6: SSL Renegotiation

This is the sixth article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM.

1. SSL Overview and Handshake
2. SSL Certificates
3. Certificate Chain Implementation
4. Cipher Suites
5. SSL Options
6. SSL Renegotiation
7. Server Name Indication
8. Client Authentication
9. Server Authentication
10. All the "Little" Options

This article will discuss SSL renegotiation, some OpenSSL features, some of the attack vectors against SSL renegotiation, and then how the BIG-IP is configured to handle this feature.

What Is SSL Renegotiation?

Before we get into the details of SSL renegotiation, let me start by outlining a quick scenario.  Let's say a user visits an online shopping site that is SSL encrypted.  Initially, the user shops around anonymously, but after some time on the site, the user decides to log in and make a purchase.  The user will need to authenticate to the site before making the purchase, so the SSL connection will need to be adjusted to allow the authentication.  Ideally, all the information the user collected as an anonymous visitor will be maintained and protected after the status change to an authenticated customer.  This basic (yet frequent) scenario outlines the need for SSL renegotiation.  The figure below shows a representation of this scenario and shows that a new SSL session must be established in order to authenticate the user.  This new session completes the full handshake, but it does it using the security of the already-established SSL connection.

SSL renegotiation messages (including types of ciphers and encryption keys) are encrypted and then sent over the existing SSL connection.  This feature is nice because it can create a secure SSL session based on the fact that a secure connection is already established.  SSL renegotiation is useful in several situations where an ordinary SSL session is already established.  Here are a few examples:

1. Client authentication is required

2. A different set of encryption and decryption keys are needed

3. A different set of encryption and hashing algorithms are used

The client or the server can request renegotiation at any time.  For the client to request renegotiation, the client sends a "Client Hello" message in the already-established encrypted channel and the server responds with a "Server Hello" and then the negotiation follows the normal handshake process.  The server can initiate the renegotiation by sending the client a Hello Request message.  When the client receives the request, the client sends the "Client Hello" message and the handshake process takes place.

One quick note of clarification:  the client and server can also complete a session resumption vice a session renegotiation.  A session resumption basically resumes a previous session (using a previous session ID), and it saves the client and server the computing work of generating new encryption keys.  Renegotiation is a process by which the full handshake process takes place over an already existing SSL connection.

A Fly In The Ointment...

Life would be much easier if the bad guys weren't out there doing their thing, but I guess it would also be less interesting.  Nonetheless, some pretty smart guys were

 working with SSL renegotiation back in the old days (circa 2009) and found out that they could exploit a vulnerability in its design.  The Common Vulnerabilities and Exposures (CVE) database outlines the details behind this SSL renegotiation vulnerability in CVE-2009-3555.  You can read the details for yourself, but here's what the CVE basically says: TLS and SSLv3 do not properly associate renegotiation handshakes with an existing connection, and this allows attackers to insert data into existing sessions by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context related to a "plaintext injection" attack.  Essentially, this means that bad guys can hijack the SSL session and start using your "secure" communications on your behalf.  Houston, we have a problem.

Fortunately, the good folks at the Internet Engineering Task Force (IETF) found out about this problem, and they responded with a little magic of their own.  It's outlined in Request for Comments (RFC) 5746.  Here's what they had to say:  "Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack."  Well, take that bad guys!!

A Few Notes About OpenSSL

Now that we have a basic understanding of RFC 5746, let's spend some time on OpenSSL and how it relates to F5's BIG-IP.  After all, how can you have an article on SSL and not talk about OpenSSL?  This stuff is free (Apache style) and it's awesome!  The BIG-IP supports the popular OpenSSL toolkit, and it even has a built-in OpenSSL utility.  It's important to understand how OpenSSL handles the behavior of clients and servers regarding the feature of SSL renegotiation.  OpenSSL 0.9.8m and later always attempts to use secure renegotiation as described in RFC 5746.  On the BIG-IP side of the house, versions prior to 10.2.3 do not support this RFC.  However, beginning in version 10.2.3 and 11.x, the BIG-IP SSL profiles do support it.  So, pause for a few minutes from reading this article and upgrade your BIG-IP!

Patching

When describing SSL implementations, systems that support secure renegotiation (per RFC 5746) are referred to as "patched" and systems that do not support secure renegotiation are referred to as "unpatched."

If a client and server are both patched, connections and renegotiation are always permitted by OpenSSL implementations.

If a server is patched but the client is unpatched, the initial connection will succeed but client renegotiation will be denied by the server with a no_renegotiation warning alert if TLS v1.0 is used or a fatal handshake_failure alert if SSL v3.0 is used.  If the patched server attempts to renegotiate with the unpatched client, a fatal handshake_failure alert is sent. This is because the server code may be unaware of the unpatched nature of the client.

Here's what happens if a client is patched but the server is unpatched.  If the option "SSL_OP_LEGACY_SERVER_CONNECT" or "SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION" is set then initial connections as well as all renegotiations between patched clients and unpatched servers will succeed. However, if neither option is set then initial connections to unpatched servers will fail.  (note:  the option "SSL_OP_LEGACY_SERVER_CONNECT" is currently set by default, but as more servers become patched, this option will not be set by default in future versions of OpenSSL).

Renegotiation Attacks

Speaking of highly broken...let's spend a little time on SSL renegotiation attacks before we dive into the BIG-IP configurations.  Here are two fairly well known attacks that are targeted at the SSL renegotiation feature.

And, guess what?  I'm starting with the..."Man in the Middle" (sung to Michael Jackson's hit song)

Man In The Middle

Since we discussed RFC 5746 earlier, why not go over the details of what it fixed?  As we've discussed, SSL allows both servers and clients to initiate a complete renegotiation of the encryption parameters used for SSL connections. However, the design of the initial handshake and the renegotiation process had a gap that could allow an attacker to send a “Client Hello” and insert content into a client’s SSL session and then intercept secure communications between the server and the client.  The following illustration shows how a bad guy could exploit the Man in the Middle vulnerability.

In this example, the client sends a "Client Hello" to start an SSL session with his bank's server.  The bad guy temporarily blocks the "Client Hello" and then creates an SSL connection of his own with the server.  After the SSL session is created between the bad guy and the bank server, the bad guy asks for a money transfer.  The bank server needs to authenticate the user, so it requests a renegotiation by sending a "Hello Request" to the bad guy...which is exactly what he wanted.  This is where the bad guy sends the client's initial "Client Hello" to the server.  The client thinks he is beginning a new SSL session, and the server thinks an SSL renegotiation has just taken place.  But, nonetheless, all parties are happy with everything...especially the bad guy!

See, now you know why you should be using a "patched" system!

Denial of Service

Last year, the IETF posted a paper that outlines a Denial of Service (DoS) attack against a server using the SSL renegotiation feature.  The DoS attack is based on the fact that an SSL handshake requires up to 10 times more processing power on the server than on the client.  Therein lies the problem...and the ability to exploit it!  When SSL renegotiation is enabled on the server, a user is allowed to send a renegotiation request any time he wants...and this request initiates a new handshake.  Since it takes much fewer resources for a client to perform a handshake than a server, the client can request multiple handshakes per second and cause a DoS on the server side SSL interface. Therefore, if a malicious user requests multiple renegotiation requests it will exhaust the server’s resources and not allow any other user to establish a connection.  This attack is different than a Distributed Denial of Service (DDoS) as it does not require a large amounts of network volume to exhaust the network connection. Instead, it exhausts the server resources from a single host requiring only a single TCP/IP socket.  A single server can perform between 150-300 handshakes per second while a single client can request up to 1,000 handshakes per second.

By the way, Openssl doesn't consider this DoS exploit an actual vulnerability (which is why they haven't done anything about it in their latest releases).  Their response is that this exploit is a way of DoS'ing a server by requesting lots of expensive crypto operations.  Any app that allows an operation like SSL renegotiation to an untrusted host is subject to resource exhaustion. They would say the correct answer is to restrict hosts if this is an issue.  Note also that if the OS firewall is not enabled, any OS is subject to a DoS through resource exhaustion, even if it's just TCP port exhaustion.

For more information on a great SSL renegotiation DoS countermeasure, see this DevCentral article.  David Holmes and Jason Rahm teamed up to talk about the DoS vulnerability, and then they wrote an iRule that elegantly defeats the attack...really cool and useful stuff!!

In addition, here's a quick video clip that talks about the same issue...F5 knocks it out of the park with this iRule stuff!

BIG-IP Configuration

Now that we've talked through this SSL renegotiation thing, let's finish up with the features of the BIG-IP and how it handles SSL renegotiation.  The following screenshot shows the different options for SSL renegotiation on the BIG-IP.  You can find this screen by navigating to Local Traffic > Profiles > SSL > Client | Server.  Notice that you can either enable or disable SSL renegotiation altogether.  By default, it is enabled.

Renegotiation controls (on a per-connection basis) how the BIG-IP responds to mid-stream SSL reconnection requests. When enabled, the system processes mid-stream SSL renegotiation requests. When disabled, the system terminates the connection, or ignores the request, depending on system configuration.

The Renegotiate Period setting specifies the number of seconds from the initial connect time that the system renegotiates an SSL session. The options are "Specify" (in seconds) and "Indefinite" with "Indefinite" being the default.  The "Indefinite" setting means that you never want the system to force an SSL renegotiation.  The system will renegotiate the session after the specified period of time...that's why the "Indefinite" setting never forces a renegotiation.  For example, setting the renegotiate period to 3600 seconds triggers session renegotiation at least once an hour.

The Renegotiate Size setting forces the BIG-IP to renegotiate an SSL session after a specified number of megabytes of application data have been transmitted over the secure channel. The values for this setting are "Indefinite" and "Specify" (in megabytes) with "Indefinite" being the default.  This setting follows the same premise as the Renegotiate Period but it uses data size to determine when it will force a renegotiation vice a period of time.

The Renegotiate Max Record Delay setting forces the BIG-IP to terminate an SSL session after receiving the specified maximum number of SSL records.  The number of records are counted while the BIG-IP system waits for the client to initiate a renegotiation.  If the BIG-IP system receives more than the maximum number of SSL records, it closes the connection. The values for this setting are "Indefinite" and "Specify" (number of records).  The default setting is "Specify" 10 records.

Secure Renegotiation is a fairly new feature in the BIG-IP (not available prior to v10.2.3).  This setting handles the RFC 5746 problem, and it allows the user to specify the method of secure renegotiation for SSL connections. The values for this setting are "Request," "Require," and "Require Strict" with "Require" being the default value for the Client-side SSL profile. The default value for the Server-side SSL profile depends on the BIG-IP version: in v10.2.3 and v10.2.4, the default value for the Server-side SSL profile is "Require" and the default value in v11.x is "Require Strict."

The "Request" value specifies that the system simply requests secure renegotiation of SSL connections.  The "Require" value specifies that the system requires secure renegotiation of SSL connections. In this mode, the system permits initial SSL handshakes from clients, but terminates renegotiations from unpatched clients.  The "Require Strict" value specifies that the system requires strict secure renegotiation of SSL connections. In this mode, the system does not accept new SSL connections from unpatched clients.  Within the context of the Server-side SSL profile, there is no behavioral difference between "Require" and "Require Strict." In either mode, initial SSL connections from the BIG-IP to unpatched servers will fail.

Conclusion

Well, I think that about does it for SSL Renegotiation.  Come back for more great SSL discussion in our next article that will feature Server Name Indication (SNI).  As always, if you have any questions (about SSL, iRules, or any other F5 technology), feel free to comment here or contact the DevCentral team directly.

See you soon!