Applies To:

Show Versions Show Versions

Manual Chapter: Data Protection for Inbound Web Applications
Manual Chapter
Table of Contents   |   << Previous Chapter

Overview: Protecting and optimizing inbound Web applications

You've probably noticed the growing number of Web application requests coming into your datacenter over SSL. And as a system administrator, you want to make sure the traffic is secure and fast.

You can do this with BIG-IP® Local Traffic Manager™ (LTM®). With LTM, you just need to apply a basic set of security and optimization features that we recommend for your Web traffic. The illustration here shows this configuration.

inbound SSL traffic

Data protection on the BIG-IP system for inbound Web traffic

In this document, we'll guide you through the steps to secure and optimize your inbound traffic before it reaches your Web servers.

Watch an overview of SSL data protection and how to enable system-wide state mirroring

How do I protect and optimize my inbound Web applications?

You should follow all of the tasks in this document, in the order shown.

Enable system-wide state mirroring

Before starting this task, make sure your BIG-IP® user account gives you permission to use the Traffic Management Shell (tmsh).

For application requests coming in over SSL, you should enable a system-wide variable called statemirror.secure. You have to enable this variable so that you can enable SSL session mirroring later when you create a Client SSL profile. And SSL session mirroring ensures that if failover happens within a device group, the newly-active device has all of the information it needs to handle existing SSL sessions, with almost no interruption and no extra handshaking. Even if you have a standalone BIG-IP system, you should enable this variable so that if you add this device to a device group later, you can mirror its connections to its peers.

Watch how to enable system-wide state mirroring

  1. On the BIG-IP system, log in to the Traffic Management Shell (tmsh).
  2. Within the shell, type this command: modify sys db statemirror.secure value enable

Set up OCSP stapling to send certificate status

Before you start this task, you need to make sure that there's a proxy server pool or a DNS resolver already configured on the system.

You create an OCSP Stapling profile to speed up the time it takes for the client to get the revocation status of the BIG-IP® system's device certificate during an SSL handshake.

Here's how it works: You create the OCSP profile and apply it to a Client SSL profile. This causes the BIG-IP system to ping an OCSP server for the status of the BIG-IP certificate. The BIG-IP system then staples the status to the handshake so that the client doesn't need to request it.

Note: If you plan to use multiple Client SSL profiles for different applications, you can create a separate OCSP profile for each profile.

Watch how to set up OCSP stapling

  1. On the Main tab, click Local Traffic > Profiles > SSL > OCSP Stapling .
  2. Click Create.
    The New OCSP Stapling Profile screen opens.
  3. Type a unique name for the profile.
  4. Configure all other settings, specifying either a DNS resolver or a proxy server pool.
  5. Click Finished.
  6. Repeat this task for any other Client SSL profile you plan on creating.

Look for SSLv3 support in a cipher string

Before starting this task, make sure your BIG-IP® user account gives you permission to use the Bash shell prompt.

As you probably know, SSL Version 3 is an unsecure protocol. So before you set up the system to decrypt and re-encrypt inbound connections, find out whether the ciphers you want to specify in the Client and Server SSL profiles include or exclude support for SSLv3.

Fortunately, the BIG-IP system's DEFAULT cipher string no longer supports SSLv3. That's the good news. The bad news is that when you append certain ciphers to the DEFAULT string (always recommended), those ciphers might pull in support for SSLv3 without you knowing it.

Watch how to look for SSLv3 support in a cipher string

  1. Log in to the Bash shell of the BIG-IP system.
  2. At the prompt, type the command tmm --clientciphers ‘cipher_string.
    For example, the command tmm --clientciphers ‘RSA+AES’ shows specific RSA+AES ciphers that include SSLv3 support:
                              
           ID  SUITE            BITS PROT    METHOD  CIPHER  MAC     KEYX
     0:    61  AES256-SHA256    256  TLS1.2  Native  AES     SHA256  RSA       
     1:    53  AES256-SHA       256  SSL3    Native  AES     SHA     RSA       
     2:    53  AES256-SHA       256  TLS1    Native  AES     SHA     RSA       
     3:    53  AES256-SHA       256  TLS1.1  Native  AES     SHA     RSA       
     4:    53  AES256-SHA       256  TLS1.2  Native  AES     SHA     RSA       
     5:    53  AES256-SHA       256  DTLS1   Native  AES     SHA     RSA       
     6:    60  AES128-SHA256    128  TLS1.2  Native  AES     SHA256  RSA       
     7:    47  AES128-SHA       128  SSL3    Native  AES     SHA     RSA       
     8:    47  AES128-SHA       128  TLS1    Native  AES     SHA     RSA       
     9:    47  AES128-SHA       128  TLS1.1  Native  AES     SHA     RSA       
    10:    47  AES128-SHA       128  TLS1.2  Native  AES     SHA     RSA       
    11: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA
    
    If you type the command tmm —clientciphers ‘RSA+AES:!SSLv3’, you'll see only the RSA_AES ciphers that exclude support for SSLv3.
  3. Again at the prompt, type the command tmm --serverciphers ‘cipher_string.
  4. To see which ciphers are included in the DEFAULT string, type either tmm --clientciphers 'DEFAULT' or tmm --serverciphers 'DEFAULT'.
    Important: Ciphers in the DEFAULT string vary by BIG-IP version.
After you do this task, use the information you've learned to type cipher strings in the Client and Server SSL profiles.

Decrypt SSL connections and manage ciphers for client-side requests

Use these steps to create a Client SSL profile. Configuring this profile enables SSL offload for client-side traffic, plus other security features. With this profile, the BIG-IP® system decrypts all HTTPS requests that it receives from the client.

By the way, the client authenticates the BIG-IP system by default, but the system doesn't authenticate the client.

Note: The cipher string you type in this profile doesn't need to match the string you type in the Server SSL profile for your server-side traffic.

Watch how to create a Client SSL profile

  1. On the Main tab, click Local Traffic > Profiles > SSL > Client .
    The Client profile list screen opens.
  2. Click Create.
    The New Client SSL Profile screen opens.
  3. Type a unique name for the profile.
  4. From the Configuration list, select Advanced.
  5. On the right side of the screen, select the Custom check box.
  6. Configure only the settings described in this table. For all of the other settings, you can just use the default values.
    Setting Description
    Certificate Key Chain

    Specify one or more certificate key chains. A certificate key chain includes the names of a certificate, key, chain, passphrase, and the OCSP Stapling profile you created earlier. You'll want to add up to three different certificate key chains, one for each key type (RSA, DSA, and ECDSA).

    • The chain can contain either a series of certificates in PEM format or one or more PEM files.
    • Do not use the default self-signed certificate and the default CA bundle certificate as a certificate chain.
    • For a high availability (HA) configuration, never pick a default certificate and key name; if you do, HA won't work.
    Important: At a minimum, you must specify an RSA certificate/key pair.
    Ciphers

    Type a cipher string that contains the specific ciphers the BIG-IP system can use for client-side connections. Always append a cipher string to the DEFAULT string. A few things to keep in mind:

    • Ciphers in the DEFAULT string vary by BIG-IP version.
    • Include the ECC key type, because its shorter length speeds up encryption and decryption.
    • Include both !ADH and :HIGH in your cipher string.
    • Disable EXPORT ciphers by including !EXPORT in the cipher string.
    • Remove support for the SSLv3 protocol version if you can. This protocol version isn't secure. Just include :!SSLv3 in any cipher string you append to DEFAULT.
    • For AES, DES, and RC4 encryption types, include the DHE key exchange method to get Forward Privacy, which throws away the key after each session. And by the way, diagnostic tools like ssldump don't work when you're using Forward Privacy.
      Note: Make sure the private key isn't being shared with a monitoring system or a security device (like an intrustion detection system).
    Renegotiation Clear the check box to prevent the BIG-IP system from renegotiating mid-stream SSL connection requests. This makes the system less prone to SSL attacks. It also allows the BIG-IP system to accept HTTP/2 client traffic.
    SSL Session Mirroring Select the check box. This mirrors SSL state information to whatever device is the next-active device in a device group, preventing another full handshake between the client and the BIG-IP device. And don't forget that you need to enable global state mirroring, too, for this to work. Even if you have a standalone BIG-IP system, you should enable this variable so that if you add this device to a device group later, you can mirror SSL state to its peers.
  7. Click Finished.
  8. If you want more than one Client SSL profile, repeat this task.
    Important: As an option, you can create a separate Client SSL profile for each of your applications, where each profile specifies a different cipher string for handling an application's client-side requests. Then you can assign all of the profiles to the same virtual server.

Re-encrypt SSL connections and manage ciphers for server-side requests

Use these steps to create a Server SSL profile. Use this profile to re-encrypt all SSL client requests that it sends to a Web server.

Note: The cipher string you type in this profile doesn't need to match the string you type in the Client SSL profile for your client-side traffic.

Watch how to create a Server SSL profile

  1. On the Main tab, click Local Traffic > Profiles > SSL > Server .
    The SSL Server profile list screen opens.
  2. Click Create.
    The New Server SSL Profile screen opens.
  3. Type a unique name for the profile.
  4. From the Configuration list, select Advanced.
  5. On the right side of the screen, select the Custom check box.
  6. Configure only the settings described in this table. For all of the other settings, just use the default values. Important: If you have a high availability (HA) configuration, never select a default certificate and key name; if you do, HA won't work.
    Setting Description
    Certificate

    Select the name of an SSL certificate on the BIG-IP system.

    Key

    Select the name of an SSL key on the BIG-IP system.

    Passphrase and Confirm Passphrase

    Type a string that turns on access to SSL certificate/key pairs that are stored on the BIG-IP system with passwords.

    Chain

    Pick the chain that you want to include in the certificate key chain.

    Ciphers

    Type a cipher string that contains the specific ciphers the BIG-IP system can use for client-side connections. Always append a cipher string to the DEFAULT string. A few things to keep in mind:

    • Ciphers in the DEFAULT string vary by BIG-IP version.
    • Include the ECC key type, because its shorter length speeds up encryption and decryption.
    • Include both !ADH and :HIGH in your cipher string.
    • Disable EXPORT ciphers by including !EXPORT in the cipher string.
    • Remove support for the SSLv3 protocol version if you can. This protocol version isn't secure. Just include :!SSLv3 in any cipher string you append to DEFAULT.
    • For AES, DES, and RC4 encryption types, include the DHE key exchange method to get Forward Privacy, which throws away the key after each session. And by the way, diagnostic tools like ssldump won't work when you're using Forward Privacy.
      Note: Make sure the private key isn't being shared with a monitoring system or a security device (like an intrustion detection system).
    Renegotiation Clear the check box to prevent the BIG-IP system from renegotiating mid-stream SSL connection requests. This makes the system less prone to SSL attacks. It also allows the BIG-IP system to accept HTTP/2 client traffic.
    SSL Session Mirroring Select the check box. This mirrors SSL state information to whatever device is the next-active device in a device group, preventing another full handshake between the client and the BIG-IP device. And don't forget to enable global state mirroring, too, for this to work. Even if you have a standalone BIG-IP system, you should enable this variable so that if you add this device to a device group later, you can mirror its connections to its peers.
  7. Click Finished.

Enforce full encryption by enabling HSTS in an HTTP profile

You can create your own HTTP profile to tell the BIG-IP®system how you want it to manage HTTP traffic. When you create an HTTP profile, you should enable the industry-standard protocol HSTS (Hypertext Strict Transport Security), which makes sure that clients only communicate with servers over a fully-encrypted connection. This helps to prevent cookie hijacking and man-in-the-middle attacks.

Watch how to enable HSTS

  1. On the Main tab, click Local Traffic > Profiles > Services > HTTP .
    The HTTP profile list screen opens.
  2. Click Create.
    The New HTTP Profile screen opens.
  3. Type a unique name for the profile.
  4. In the Parent Profile list, make sure that http is selected.
  5. Select the Custom check box.
  6. In the HTTP Strict Transport Security area of the screen, select the Mode check box.
    The default maximum age is 186 days. You should use the default value or type a value of at least 180. Also, leave the Include Subdomains box selected (unless you have an application on a subdomain that can't use HSTS) such as an application that needs a self-signed certificate.
  7. Use the default values for the other settings on this screen.
  8. Click Finished.

Identify your Web servers to the BIG-IP system

Before you start this task, you need to know the IP addresses of the servers you want to include in your server pool.

Part of configuring SSL data protection is creating a Web server pool with pool members. The pool you create identifies by IP address which Web servers you want the virtual server to send client requests to, using a round robin approach.

Watch how to identify your Web servers to the BIG-IP system

  1. On the Main tab, click Local Traffic > Pools .
    The Pool List screen opens.
  2. Click Create.
    The New Pool screen opens.
  3. Type a unique name for the pool.
  4. For the Health Monitors setting, from the Available list, pick the https monitor and move the monitor to the Active list.
  5. For the New Members setting, add each server node that you want to include in the pool:
    1. Select New Node.
    2. Optionally, in the Node Name field, type a name for the node.
    3. In the Address field, type the IP address of the server.
    4. For the Service Port option, pick HTTP or HTTPS from the list.
    5. Click Add.
    6. Repeat these steps for each node.
  6. Click Finished.

Set a target BIG-IP address for inbound client requests

Before you create a virtual server, make sure that you've already created your own HTTP, Client SSL, and Server SSL profiles.

This task creates a virtual server on the BIG-IP® system. A virtual server is basically a destination IP address and port for inbound client traffic. It tells the BIG-IP system what profiles to apply and which pool of servers to send client requests to. For this virtual server, you should apply the default HTTP/2.0, cookie persistence, and OneConnect™ profiles, and also the three new profiles you created -- HTTP, Client SSL, and Server SSL.

Watch how to set a target address for inbound client requests

  1. On the Main tab, click Local Traffic > Virtual Servers .
    The Virtual Server List screen opens.
  2. Click the Create button.
    The New Virtual Server screen opens.
  3. In the Name field, type a unique name for the virtual server.
  4. Configure only the settings described in this table. For all of the other settings, you can just use the default values.
    Setting Description
    Destination Address

    Type the IP address you want to use as a destination for inbound traffic. Make sure the IP address is available and not in the loopback network.

    Service Port

    Type 443 or select HTTPS from the list.

    HTTP Profile Pick the name of the HTTP profile you created earlier.
    SSL Profile (Client) Pick the name of the Client SSL profile you created earlier and move it to the Selected box.
    SSL Profile (Server) Pick the name of the Server SSL profile you created earlier and move it to the Selected box.
    Source Address Translation

    Pick Auto Map from the list.

    Acceleration

    Pick Advanced from the list.

    OneConnect Profile Select oneconnect from the list. This enables TCP multiplexing, which means that server-side connections stay open and can be re-used by inbound requests.
    HTTP/2 Profile Select http2 from the list. This causes the BIG-IP system to transform all requests to HTTP/1.1 before sending them on to the web server. Make sure you've disabled mid-stream SSL renegotiations within the Client and Server SSL profiles, or else you won't be able use this profile.
    Default Pool In the Resources area of the screen, pick the name of the pool you created earlier.
    Default Persistence Profile Select cookie from the list.
  5. Click Finished.
After you create this virtual server, the BIG-IP system offloads SSL handshaking from the servers in your server pool. The system decrypts client requests and applies all of the profile settings. Then the system re-encrypts the requests before sending them to the Web server.

What's different after enabling SSL data protection?

Once you've finished setting up the system to protect and optimize your application data, the BIG-IP® system works in these ways.

Security and transformation

  • Supports multiple certificate key chain types for a single Client SSL profile (RSA, DSA, and ECDSA).
  • Accepts different ciphers for client-side connections than for server-side connections.
  • Transforms client-side HTTP/2.0 traffic to server-side HTTP/1.1 traffic.
  • Denies any requests for mid-stream SSL re-negotiation, to stop certain types of attacks.
  • Enforces full encryption of SSL connections.
  • Denies or allows requests by clients to use SSLv3, depending on the cipher suite you typed.

Optimization

  • Eases server workload by offloading handshaking and encryption/decryption tasks from your servers.
  • Minimizes handshaking through OCSP stapling, ECC ciphers, OneConnect™, and session mirroring.
  • Prevents interruptions and dropped connections through system-wide state mirroring and SSL session mirroring to another BIG-IP device.
  • Persists client sessions by using HTTP cookies.

Other resources

For information about SSL, HTTP, or related industry-standard technologies, see the relevant IETF RFCs (Request for Comments).

For information about F5's SSL Everywhere™ reference architecture, see these whitepapers at https://f5.com:

  • The F5 SSL Everywhere Reference Architecture
  • SSL Everywhere Recommended Practices

For more general documentation or articles about BIG-IP® SSL administration, see:

  • The document titled BIG-IP System: SSL Administration on the AskF5™ Knowledge Base at http://support.f5.com.
  • SSL-related articles at https://devcentral.f5.com.

To see the full video playlist for how to protect and optimize inbound Web applications, you can visit our DevCentral™ YouTube™ channel. Use any of these ways:

Table of Contents   |   << Previous Chapter

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)