F5 SSL Everywhere

RECOMMENDED PRACTICES 

F5 SSL Everywhere 

David Holmes 

Principal Technical Marketing Manager 

Marty Scholes 

Marketing Solutions Architect



Contents 

Introduction 3 

About the acronyms SSL vs. TLS 4 

Deployment Scenarios 4 

Deployment scenario: Inbound enterprise applications 5 

Deployment scenario: Inbound retail data center 5 

Deployment scenario: Inbound SSL pass-through 6 

Deployment scenario: Outbound SSL visibility 6 

A recommended security posture 6 

Fine-Tuning Data Protection 8 

A primer on SSL cipher strings 8 

Transformational services 13 

Client certificates 19 

SSL failover options 22 

Cipher agility 25 

Key Management 28 

Certificate expiration notification 29 

Use the certificate manager role 30 

Key protection 31 

Revocation verification 34 

Visibility and Control 42 

SSL and the OWASP Top Ten 42 

SSL outbound visibility 43 

Mitigating brute force attacks 47 

Instrumentation: The SSL statistics panel 50 

Conclusion 52 

2



Introduction 

The cryptographic protocol historically known as the Secure Sockets Layer (SSL) and now 

known as Transport Layer Security (TLS) is quickly becoming the de facto protocol for all 

important, and even casual, electronic communication today. Only a decade ago, SSL was 

reserved only for financial institutions and the login pages of the security conscious. Today 

SSL is ubiquitous. Even the world’s most popular video sites use SSL for streaming. 

Although SSL can be an everywhere, all-the-time security protocol, it is not always easy 

to deploy correctly, or without challenges, into an architecture. For example, SSL offers 

protection for data in transit, not at rest. It offers forward secrecy, but usually at the cost 

of monitoring or diagnostic utilities. SSL also faces numerous attacks, despite being 

constantly improved and monitored by the Internet Engineering Task Force (IETF). Finally, 

implementation issues such as the OpenSSL group’s Heartbleed incident remind the world 

that cryptography is difficult—even for cryptographers. 

The F5 ® SSL Everywhere reference architecture aggregates the set of common solutions 

for securing data in transit from users to applications, between enterprise services, and 

from corporate users to the Internet. The key to the reference architecture is the custombuilt 

SSL software stack that is part of every F5 BIG-IP ® Local Traffic Manager (LTM) 

deployment. 

This recommended practices document, which is based on the SSL Everywhere reference 

architecture, can guide architects and administrators through strategic deployments of SSL 

and serve later as a quick reference for specific concerns. It includes: 

• Common deployment scenarios. 

• Advanced key management recommendations. 

• Tips for fine-tuning data protection. 

• Suggestions for enhancing visibility and control. 

• Dozens of technical tips and recommended practices for maximizing security 

posture (and value). These may include example F5 TMOS ® shell (TMSH) commands 

such as: 

(tmos)# modify ltm profile http2 http2-ni enforce-tls-requirements disabled 

Basic familiarity with SSL, server administration, and BIG-IP platform administration is 

assumed. The recommended practices apply to the BIG-IP family of products, with 

version 12.0.0 of the BIG-IP platform providing the baseline for referenced features and 

configurations unless otherwise noted. 

3



About the acronyms SSL vs. TLS 

Vagueness is anathema to engineers. As a result, many engineers refer to modern web 

encryption as TLS and consider the acronym SSL obsolete. But the fact is that SSL has 

become shorthand for “a secure connection” even in casual conversation between security 

professionals and the same security engineers who dislike seeing SSL in print. So for the 

purposes of brevity and search engine optimization, this document uses the acronym SSL 

to refer to the collection of encryption protocols that encompass SSLv2, SSLv3, TLSv1, 

TLSv1.1, and TLSv1.2, except where it is important to specify a particular version. When SSL 

is used as an adjective (for example, SSL VPN), it should be understood that the subject 

encompasses the current, accepted protocols for transport layer security. 

SSLv3 is rapidly being phased out, with SSLv2 long dead. Even TLSv1.0 is discouraged 

today, and only TLSv1.1/1.2 should be used whenever possible. Perhaps, in time, the 

language will catch up to reality and TLS will be used in the same way SSL is commonly 

used today. 

Deployment Scenarios 

For many organizations today, the main use case for SSL is securing data from customers 

and employees on the Internet to data center applications through an Application Delivery 

Controller (ADC). While the data center deployment is among the most mature of encrypted 

data center technologies, it’s not without innovation (and renovation). The deployment 

scenarios that follow include advanced SSL strategies such as HTTP Strict Transport 

Security (HSTS) and Online Certificate Status Protocol (OCSP) stapling. The recommended 

practices introduce how these technologies can be leveraged in inbound data center 

deployments for outbound visibility. 

4



REFERENCE ARCHITECTURE: SSL Everywhere 

CONTENT TYPE: Product Map 

AUDIENCE: Security Architect 

CUSTOMER SCENARIO: SSL Everywhere (Inbound) 

DMZ 

Web Application Firewall 

NG-IPS 

Passive Monitor, IDS, 

Customer Experience Solutions 

Remote Users 

User 

Internet 

Network 

Firewall 

SSL Termination and Inspection 

+ Cipher Agility + SSL Transformation 

+ Intelligent Traffic Management 

+ SSL Re-Encryption 

Network 

Firewall 

Web/Application 

Servers 

BIG-IP Platform 

Customer Scenarios 

Data Protection 

Visibility and Control 

Key Management 

HSM 

SSL Crypto-Offload 

+ SSL Termination and Inspection 

+ SSL Re-Encryption 

+ SSL Transformation 

BIG-IP Local Traffic Manager 

Simplified Business Models 

GOOD BETTER BEST 

BIG-IP Platform 

Figure 1: Common deployment scenarios for SSL 

Deployment scenario: Inbound enterprise applications 

One of the primary deployment scenarios for SSL is to protect a suite of enterprise 

applications, from Microsoft Sharepoint and Exchange to a LAMP-based CGI application. 

A typical administrator for this deployment scenario is likely a network operations team 

member. In a larger organization there will be a security team, a security architect, an 

auditor, and sometimes even a separate certificate management team. Enterprise 

administrators will use an ADC to perform SSL bridging, which is the act of decrypting 

incoming connections, performing an action (such as a load-balancing pick or persistence), 

and then re-encrypting the connection to a server within the enterprise. Flexibility, 

extensibility, security, and visibility take precedence over availability for many of these 

administrators. 

Deployment scenario: Inbound retail data center 

One of the most demanding scenarios for an ADC is the retail website. Even more 

demanding can be deployment for a hosting company dealing with multiple retail sites. 

5



A hosting company that sports many very popular websites can have millions of connections 

flowing through the ADC at any minute, and hundreds to thousands of new SSL connections 

per second. For these customers, availability and compatibility are the most important 

characteristics of their deployments. They are also concerned with compliance to standards 

such as the Payment Card Industry Data Security Standard (PCI DSS). For retail customers, 

the ADC is often performing SSL termination, meaning that it is decrypting incoming 

connections and transitioning (proxying) the payloads to servers further into the data center. 

Deployment scenario: Inbound SSL pass-through 

The majority of F5 customers use BIG-IP devices for application delivery services that 

include SSL. A significant number of customers use the BIG-IP platform for L4 load 

balancing and traffic steering. These customers include service providers running tens of 

millions of connections through single tiers of F5 ADC devices. These devices will be aware 

of SSL connections but won’t be actually terminating or even inspecting those connections. 

They can still provide a measure of control over the SSL flows. The term for this kind of flow 

control is called SSL pass-through—the SSL traffic is passing through the ADC instead of 

being terminated or bridged at the ADC. 

Deployment scenario: Outbound SSL visibility 

One of the most significant new applications of SSL decryption is used in a scenario that 

has various names, such as SSL “air gap” or SSL interception. The problem it solves is 

simple in concept: Users inside a corporate headquarters are one of the most high-profile 

risks when they react to unsolicited email or browse the Internet. A targeted “spear phishing” 

campaign can snare a user into clicking a link that will pull malware from the Internet 

through an SSL connection. There are security solutions that scan for malware, but many of 

them are unable to scale to automatically and transparently decrypt SSL connections. The 

outbound SSL visibility scenario supports these security solutions. F5 devices sandwich 

these security solution devices to provide decryption and re-encryption services. 

A recommended security posture 

The definitive resource for evaluating a web site’s SSL security posture (and comparing it 

to others) is the Qualys SSL Labs report. An administrator can connect to the test site and 

enter his web address, and the report will provide an elementary alphabetical grade. While 

some think that a single letter is oversimplifying many complicated ideas, the SSL Labs 

scanner grade is, at least, an objective, and there is no denying that SSL Labs is the most 

visible project grading SSL deployments and rating SSL security postures today. 

6



To check a web address against the SSL Labs report, visit this address and enter the site’s 

URL. 

Figure 2: A simple SSL Labs security posture report 

Achieving an A+ grade is a non-trivial task; however, it can be done in an afternoon (even in 

less than an hour) when starting from the right point. Currently, to achieve an A+ rating with 

SSL labs, a user must follow these recommendations; otherwise the site would receive the 

following grade in brackets. 

• Disable SSLv3 [B] & RC4 [B/C] 

• Replace any SHA1 Certs [A] and sub-2k Certs [C] 

• Enable TLS_FALLBACK_SCSV [A] 

• Enable HTTP Strict Transport [A] 

• Enable and Prefer Perfect Forward Secrecy Compatible Ciphers [A-] 

Do not use DHE ciphers (only ECDHE). DHE ciphers will cap the grade at [B] on 

BIG-IP. 

• Enable TLS1.2 [C] 

• Enable Secure Renegotiation [A-] 

The DEFAULT cipher string included in BIG-IP version 12.0 will yield a B grade but offers full 

hardware acceleration. To get that coveted A+ grade, an administrator would need to have 

7



a fairly restrictive cipher list. For example “!SSLv3:!DHE:ECDHE:RSA+HIGH” will get an 

A grade on SSL labs but would require every user to have a very recent browser. 

Note that the rating requirements change over time; see the Qualys SSL Labs Rating 

Guide for the latest. 

Fine-Tuning Data Protection 

The primary goal of SSL is to secure data in transit. A BIG-IP device that is performing SSL 

termination or SSL bridging has dozens of settings, many of them very powerful, that can 

be fine-tuned for a specific security environment. 

A primer on SSL cipher strings 

The configuration knob that controls the negotiation of key-exchange, encryption, and 

authentication protocols is the cipher string setting of the F5 clientssl and serverssl profiles. 

Creating a cipher string that projects only strong cryptographic ciphers while maintaining 

broad compatibility among browsers can be a black art. Consider this actual, 

recommended cipher string for advanced BIG-IP administrators: 

ECDHE+AES-GCM:ECDHE+AES:ECDHE+3DES:DHE+AES-GCM:DHE+AES:DHE+3DES:RSA+AES- 

GCM:RSA+AES:RSA+3DES:-MD5:-SSLv3:-RC4 

The BIG-IP device cipher string system is based on the one used by the open source 

project OpenSSL, though it does not follow it exactly. Find the full reference for OpenSSL 

cipher strings, and a few extra tips, here. 

An administrator can use the tmm command from the TMOS bash shell to see which 

ciphers are included in any given cipher string for any BIG-IP version: 

config # tmm --clientciphers ‘DEFAULT’ 

The tmm command should only be run on standby devices, because running the command 

incorrectly can interfere with application delivery. The cipher string is usually enclosed 

in single quotes otherwise any ‘!’ characters in the cipher string confuse the shell. By 

convention, UPPERCASE is always used for cipher strings. 

Also note that this command is one of the few in this document that is not a native TMOS 

shell command. An administrator must have access to the bash shell to run it, and can get 

to the bash shell by running this command from the TMOS shell: 

8



(tmos)# run util bash 

The ciphers represented by the cipher string are shown in the order in which they will be 

preferred by the BIG-IP device. In the DEFAULT example above, the first three preferred 

ciphers are: 

1 DHE-RSA-AES256-GCM-SHA384 

2 DHE-RSA-AES128-GCM-SHA256 

3 DHE-RSA-AES256-SHA256 

Unlike many server systems, when negotiating the SSL cipher with the client, the BIG-IP 

system will choose the preferred cipher according to the cipher string designated by the 

BIG-IP administrator rather than choosing the one preferred by the browser. Browser 

vendors consider this rude, but BIG-IP administrators prefer the control. 

Building a cipher string 

There are four components of a cipher: key exchange, authentication, encryption, and hash. 

A cipher may describe any subset or combination of these components. 

• Common key exchange ciphers: RSA, DHE, ECDHE, ECDHE_ECDSA, ECDH_ 

ECDSA, DHE and DHE_DSS. 

• Common authentication ciphers: RSA 

• Common encryption ciphers: AES, RC4, DES, 3DES 

• Common message hash ciphers: SHA, SHA256, MD5 

The hyphen character “-“ combines the elements into a single specific cipher. For example, 

the cipher string “DHE-RSA-AES256-SHA” specifies exactly one cipher. 

Operators 

Besides the hyphen, four other character operators are used to build cipher strings. 

• Colon (:) 

The colon character “:” is the delimiter between two cipher string phrases. When 

used as part of a list, it is simply the additive operator. For example the cipher string 

“RSA:AES” means “all RSA-based ciphers plus all AES-based ciphers” and would 

include over 100 ciphers! 

• Plus (+) 

9



The plus sign operator “+” has two uses. When used between two cipher names, 

the + operator doesn’t mean add, it means “the intersection of.” The cipher string 

“RSA+AES” means specifically just 11 ciphers that have RSA as the key exchange 

and AES as the encryption cipher. 

• Leading plus (:+) 

When used in front of a cipher name (that is, after a colon), the plus sign means 

“move these ciphers to the end of the list.” For example, RSA:RC4 and RSA:+RC4 

will provide the same list of ciphers, but the latter will order RC4-based ciphers at 

the end of the list as least preferred. 

• Minus (-) 

The minus operator “-“ deletes the ciphers from the list of supported ciphers while 

making sure that some or all of the ciphers can be added again with later options. 

The “!” operator is used more commonly than the minus. For example, “RSA:- 

SHA:DHE+SHA” means “all RSA-based ciphers except those that use SHA” plus “all 

DHE-based ciphers that include SHA”. Do not confuse the minus with the hyphen 

character “-“. 

• Not (!) 

The not operator “!” permanently deletes ciphers from the list of supported ciphers. 

The ciphers deleted can never reappear in the list even if they are explicitly stated. 

For example, “RSA:!MD5:MD5” is effectively the same as “RSA”. 

• At (@) 

The at operator “@” specifies that the following word will designate whether the 

cipher string is to order the list by cryptographic strength (@STRENGTH) or 

cryptographic performance (@SPEED). 

• No symbol 

If none of the above symbols appears in the string, the string is interpreted as a list 

of ciphers to be appended to the current preference list. If the list includes any 

ciphers already present, they will be ignored. 

Special keywords 

The cipher string format includes a series of special keywords that can be used to group 

ciphers together: 

• DEFAULT 

10



This is the ordered list of preferred ciphers as determined by the F5 security 

engineering team. It is different from the OpenSSL DEFAULT keyword. F5 optimizes 

DEFAULT to be a reasonable compromise between high security and high 

performance. 

The F5 engineering team agonizes over the list of ciphers that make up DEFAULT in 

each release. The main drawback to using DEFAULT is that when it changes (as new 

ciphers are developed or old ones fall out of favor), administrators that use DEFAULT 

may be surprised when they upgrade versions. 

In version 12.0 of the BIG-IP system, the following unsafe ciphers are excluded from 

DEFAULT and are unlikely to come back: EXPORT, SSL3, and NULL. 

Solution 13156 lists the ciphers included with the DEFAULT keyword for different 

versions of the BIG-IP system. 

• NATIVE 

The NATIVE keyword specifies the set of ciphers that are specially accelerated either 

in hardware or software in the F5 SSL software stack. The performance and support 

of NATIVE ciphers are much higher than non-NATIVE ciphers. The NATIVE cipher list 

includes ciphers that have since been shown to be inappropriately weak for modern 

use (such as RC4, MD5, and DES), so it should not be used without modification. 

• COMPAT 

The COMPAT cipher invokes a special mode for a handful of ciphers where the 

implementation is borrowed directly from the open source OpenSSL project to 

support legacy systems that could not be upgraded. Today, COMPAT should only 

be used very rarely, under specific guidance, when there is no other alternative. 

• ALL 

The ALL string includes all ciphers except the eNULL ciphers, which need to be 

explicitly enabled. The ALL ciphers are reasonably ordered by default. Use of ALL 

is highly discouraged for production systems, as it will allow many unsafe ciphers. 

• HIGH, MEDIUM, and LOW 

These keywords are largely maintained only for the purposes of compatibility. The 

HIGH string includes ciphers with 128-bit keys or larger, but in reality, HIGH is less 

secure than DEFAULT. Note that HIGH includes anonymous Diffie-Helman ciphers, 

which should not be used by production systems. 

11



The MEDIUM string includes medium-strength encryption ciphers, and the LOW 

string includes ciphers that use 64- or 56-bit encryption algorithms but excludes 

ciphers in the EXPORT string. 

• EXPORT 

The EXPORT keyword includes export encryption algorithms, including 40- and 

56-bit algorithms. These ciphers were defined to comply with U.S. export rules that 

have since been lifted. The EXPORT keyword is most useful when preceded by the 

Not (!) operator. 

Cipher string examples 

Several examples of cipher strings an administrator could use for a clientssl profile: 

ECDHE+AES-GCM:ECDHE+AES:ECDHE+3DES:DHE+AES-GCM:DHE+AES:DHE+3DES:RSA+AES- 

GCM:RSA+AES:RSA+3DES:-MD5:-SSLv3:-RC4 

This cipher string prioritizes elliptic-curve ciphers (EC). EC ciphers are thought to be easier 

on mobile devices. The Ephemeral Diffie-Helman (DHE) cipher invokes forward secrecy. By 

specifying DHE+AES, some SSLv3 ciphers get brought back in. The final “-SSLv3:-RC4” 

removes them. 

‘ECDHE:HIGH:+DHE:!ADH’ 

This string commands: Prefer elliptic curve key exchanges (ECDHE). Allow ciphers with key 

sizes of 128-bits or larger (HIGH). Put ephemeral Diffie-Helman ciphers (DHE) at the end of 

the list. Disallow any anonymous Diffie-Helman ciphers (!ADH). 

‘HIGH:!ADH:!SSLv3:!TLSv1@SPEED’ 

This string says: Allow ciphers with key sizes of 128-bits or larger (HIGH). Disallow any 

anonymous Diffie-Helman ciphers (!ADH). Effectively allow only TLSv1.2 and TLSv1.1 

(!SSLv3 and !TLSv1). Order the remaining ciphers by speed. 

F5 recommended practices for building cipher strings: 

• Disable anonymous ciphers such as ADH using the !ADH phrase. 

• Disable export ciphers using the !EXPORT phrase. 

• Use the keyword HIGH, but be sure to disable anonymous ciphers. 

• Disable SSLv3 when possible. This is an unsecure protocol version. 

12



Transformational services 

BIG-IP devices serve as a full proxy for TCP, HTTP, and SSL, which means they create one 

connection to the client (browser) and a separate connection to the server. 

The transformational nature of an SSL proxy allows a site to provide SSL features that are 

decoupled from the capabilities of the application servers. An architect can therefore use 

the ADC to transform the interface to the web servers into any protocol the ADC supports, 

regardless of the back-end transport options. 

For example, an administrator can define that every application has 2K RSA keys on the 

ADC even if the application servers support only 1K RSA keys. Or the architect can support 

HTTP/2.0 for every application on the ADC even when none of the back-end servers 

support it. In other words, transformational services provide the ability to maintain 

compliance with an Internet-facing SSL policy without the need to enforce that policy on 

individual servers. 

This full-proxy capability allows BIG-IP devices to transform any combination of the client 

and server connections below. 

Client Connection 

2K RSA 

Elliptic Curve 

Forward Secrecy (ECDHE, DHE) 

Client Certificate Authentication 

Server Connection 

HTTP/1.1 

1K RSA 

Multiplexed TCP 

2K RSA 

SPDY 

HTTP/2.0 

Forward secrecy 

The Edward Snowden U.S. National Security Agency (NSA) disclosures revealed that nation 

states might be collecting data for later use via broad-spectrum mass surveillance. The 

data includes encrypted data that the NSA could not decrypt, presumably collected in the 

hope that future technology could produce the private key used to encrypt the data. One 

lesson from these events is that data encrypted in motion can be archived for later analysis 

and that once a private key has been compromised, all traffic encrypted with that private 

key becomes visible. Put another way, all traffic encrypted with a private key is subject to 

potential future decryption. 

13



To counter this vulnerability, forward secrecy was proposed. Forward secrecy extends the 

key exchange protocol to generate a second, ephemeral key before generating the session 

key. In previous SSL key exchanges, the RSA keys are used to generate a session key, 

which in turn is used to encrypt the traffic. With forward secrecy, the RSA keys are used 

to facilitate generating a Diffie-Helman ephemeral key pair, which is used to generate the 

session key. This approach ensures that compromising the RSA private key will only provide 

access to encrypted traffic. Each individual SSL session is protected by the Diffie-Helman 

key pair generated on a per-session basis. Forward secrecy ensures that compromising a 

private key will not expose all traffic encrypted with that private key. 

BIG-IP version 12 prefers forward secrecy ciphers in the DEFAULT cipher. The 

tmm – clientciphers command shows the specific forward secrecy ciphers: 

[davidh@murky:Active:Standalone] ~ # tmm --clientciphers DHE:ECDHE 

ID SUITE 

BITS PROT 

0: 159 DHE-RSA-AES256-GCM-SHA384 256 TLS1.2 

2: 57 DHE-RSA-AES256-SHA 256 TLS1 

3: 57 DHE-RSA-AES256-SHA 256 TLS1.1 

... 

23: 49192 ECDHE-RSA-AES256-SHA384 256 TLS1.2 

24: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 

25: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.1 

Applications that use the DEFAULT cipher need not make any changes to take advantage 

of forward secrecy. There is one scenario where forward secrecy can create problems: 

key sharing, such as may be used by monitoring or other security systems. Shared-key 

monitoring will fail when forward secrecy is enabled, so in such cases, forward secrecy is 

not appropriate. 

In cases where the SSL keys are being shared with other security services such as IDS/IPS, 

the options are either to eschew forward secrecy, risking future exposure of the traffic, or to 

terminate the SSL with the BIG-IP device. Terminating the SSL enables the use of forward 

secrecy while also allowing monitoring by other devices. 

F5 recommended practices for forward secrecy: 

• Before enabling forward secrecy, ensure that the SSL private key is not being shared 

with any monitoring systems or with other security devices. 

• Understand that diagnostic tools such as ssldump will fail to work when forward 

secrecy is enabled. 

14



Multiplexing TCP and SSL 

The F5 OneConnect feature of the BIG-IP system can increase network throughput by 

efficiently managing connections created between the BIG-IP system and back-end pool 

members. OneConnect works with HTTP keep-alives, enabling the BIG-IP system to 

minimize the number of server-side TCP connections by making existing connections 

available for reuse by other clients. 

For example, when a client makes a new connection to a BIG-IP virtual server configured 

with a OneConnect profile, the BIG-IP system parses the HTTP request, selects a server 

using the load-balancing method defined in the pool, and creates a connection to that 

server. When the client’s initial HTTP request is complete, the BIG-IP system temporarily 

holds the connection open and makes the idle TCP connection to the pool member 

available for reuse. 

F5 recommended practices for multiplexing TCP and SSL: 

• Do not configure OneConnect for a virtual server doing SSL pass-through. 

• See the F5 DevCentral article “Persisting SSL Connections” for more information. 

HTTP Strict Transport Security 

Many websites operate over HTTPS but offer the ability to downgrade to unencrypted 

HTTP when necessary. Other sites operate primarily on HTTPS but download some 

content—such as video or images—over unencrypted HTTP. A site that allows unencrypted 

traffic creates an attack surface for cookie hijacking or man-in-the-middle attacks. RFC 

6797 provides HTTP Strict Transport Security (HSTS), a standard for directing web clients 

to connect only using secure and trusted connections. 

HSTS inserts a header into HTTPS traffic that directs the client only to use trusted and 

encrypted connections to retrieve objects. This restriction includes refusing to display 

pages with self-signed certificates. Clients will continue to enforce the restriction for the 

period of time specified in the header. All major browsers now support HSTS, making its 

use a good way to ensure that all traffic stays encrypted. With the BIG-IP system, the 

administrator can ensure that all pages for a domain have the HSTS header. 

Enabling HSTS is one of the easiest and most powerful ways to improve an application’s 

security posture. BIG-IP devices have three parameters for setting HSTS located within the 

HTTP profile. 

15



Figure 3: Enabling HSTS in the HTTP profile 

Select the Mode check box to enable HSTS. Use the Maximum Age field to specify for how 

many seconds the client should enforce HSTS after last seeing the header. The default 

value specifies that HSTS should be enforced for 186 days after the header was last seen, 

which is consistent with SSL Labs’ recommendation that the maximum age be at least 180 

days. Select the Include Subdomains check box to indicate that subdomains should also 

enforce HSTS. Most administrators will want to select this option, forcing all subdomains 

to use HSTS. If there is an application on a subdomain that cannot use HSTS, such as an 

application that requires a self-signed certificate, then the administrator should clear this 

check box. 

HSTS provides a layer of protection for users against several common attack vectors, 

including cookie hijacking, man-in-the-middle, and downgrade attacks, that depend on 

unencrypted traffic. By selecting a single check box, administrators can ensure that all 

traffic will require encryption after only one encrypted connection. 

F5 product users running a version of TMOS prior to 12.0 can use a simple F5 iRules ® script 

to turn on HSTS. For versions 11.6.0 and earlier, see Jason Rahm’s DevCentral article called 

“Implementing HTTP Strict Transport Security.” 

when HTTP_RESPONSE { 

HTTP::header insert Strict-Transport-Security “max-age=31536000 ; 

includeSubDomains” 

} 

The includeSubdomains keyword instructs the browser to use encryption for object 

requests within the subdomains of the site. For example, if the site is example.com, the 

includeSubdomains keyword will instruct the browser to use HSTS for chat.example.com 

as well. An administrator must ensure that all subdomains are compatible with SSL before 

enabling includeSubdomains. 

F5 recommended practices for HSTS: 

• Enable HSTS for applications. 

16



• Use the includeSubdomains keyword, but only after ensuring all subdomains will 

continue to function. 

• Enable a 302 redirect on the virtual server at port 80. Solution 14996 describes how 

to configure redirects from HTTP to HTTPS. 

HTTP/2 

HTTP/2 is poised to replace HTTP/1.1 by reducing latency in typical web traffic. HTTP/2 

reduces latency by compressing the headers, multiplexing client requests, and enabling 

servers to push data to the client before the client requests it. Since the major browsers 

now support HTTP/2 at the client level, a web application can provide a more pleasant user 

experience by implementing HTTP/2. The BIG-IP platform provides the ability to produce an 

Internet-facing HTTP/2 presence without the need for any changes to the back-end web 

servers. 

Since the dominant version of HTTP in use today is 1.1, most administrators would prefer 

to support HTTP/1.1 while making HTTP/2 available. BIG-IP devices support this scenario. 

Keeping all of the traffic on a single virtual server simplifies deployment and maintenance. 

The default behavior of the BIG-IP system is to support all versions, including HTTP/0.9 

through HTTP/2, when an HTTP/2 profile is included. The HTTP/2 profiles can be added 

to a virtual server from the Acceleration section of the virtual server configuration. 

The BIG-IP platform permits SSL settings on the server side as well as the client side. 

These settings are independent, enabling the administrator to provide an HTTP/2 presence 

without making any changes to the web server infrastructure. All internally developed and 

externally licensed software can be exposed to the Internet as HTTP/2, regardless of the 

capabilities of the internal servers. In addition, the internal traffic can be encrypted between 

the BIG-IP device and the internal servers. Encrypting all traffic increases the level of 

security both in terms of encryption and by eliminating a possible man-in-the-middle attack 

by a rogue system on the corporate LAN. The level of encryption exposed to external web 

clients is independent of the level of encryption used by internal servers so the latest 

algorithms can be used to face the Internet with older algorithms being used internally, 

where SSL traffic is less exposed. 

In response to several attacks based on SSL renegotiation, the HTTP/2 specification 

requires that SSL renegotiation be disabled, but the default clientssl profile allows 

renegotiation. The implication is that the default HTTP/2 settings and the default clientssl 

settings are incompatible. The administrator must decide whether to disable renegotiations 

(in support of HTTP/2 compatibility) or to allow renegotiations. In order to use HTTP/2, the 

administrator must change the default settings of either the clientssl profile or the HTTP/2 

profile. 

17



First, the administrator must determine whether or not renegotiations are needed. Actual 

SSL renegotiations are uncommon. One of the few use cases for renegotiation is for 

dynamically changing client authentication requirements based on content and then 

requesting a certificate from the client. Unless an administrator’s site uses this technique, 

it should be safe to leave renegotiation disabled. 

For cases where the administrator wants to remain compliant with HTTP/2 requirements 

and does not need renegotiation, disable renegotiation at the clientssl profile associated 

with the virtual server. 

Figure 4: Disabling renegotiation in a clientssl profile 

F5 recommended practices for HTTP/2: 

• Leave the default setting, which disallows SSL renegotiation with HTTP/2. This 

restriction can be relaxed with the following TMSH command if needed. 

(tmos)# modify ltm profile http2 http2-ni enforce-tls-requirements disabled 

• Attach an HTTP/2 profile to every externally facing virtual server. There is no 

downside. 

• HTTP/2 is not yet supported for BIG-IP server-side connections. If an application 

requires HTTP/2 from the client all the way to the server, use the BIG-IP device for 

layer 4 load-balancing to a pool of HTTP/2 servers. 

Persistence and SSL 

Connection persistence is a technique to consistently pair the same client to the same 

server over time. For example, suppose that a server farm has 300 servers for an 

application. A user, Marty, comes in and is directed by the ADC to server 287 because it 

has the lowest load. Server 287 establishes an HTTP session with Marty and loads his 

profile information from the middle-tier database systems into its memory. 

As Marty uses the website, his browser opens new connections to the ADC. The ADC 

recognizes Marty and sends these new connections to, say, server 287, which already has 

Marty’s profile information loaded. This works because Marty’s connections information 

18



has persisted on the ADC. Computer scientists call the property of matching requestors 

to data “locality of reference.” F5 holds the original patent for ADC persistence via HTTP 

cookies. 

There are many ways to accomplish persistence. Some early, crude models include 

persisting by client source address or layer 4 tuples. 

An administrator may notice that there is a persistence method that relies on SSL session 

ID. In actuality, this persistence method is rarely used for the following reasons: 

• It is not uncommon for a client and server to have multiple open sessions. 

• Sessions are ephemeral and can be invalidated at any time. 

• Many implementations of computation session identifiers are not deterministic, 

meaning that if Marty’s browser switched sessions mid-session (as it were), a 

persistence method based on SSL session ID could send his new session to the 

wrong server. 

The only time SSL session ID should be used as a persistence method is for the SSL 

pass-through case, where the BIG-IP device is not decrypting SSL and is simply passing 

it through to servers that will decrypt the SSL later. 

F5 recommended practices for SSL persistence: 

• Use normal cookie-based persistence when SSL traffic is terminated or bridged 

on the BIG-IP device in full-proxy mode and the underlying protocol is HTTP. 

• For clientssl profiles where the underlying protocol is not HTTP, use layer 4 

persistence. 

• For SSL pass-through configurations, use SSL session ID persistence. 

Client certificates 

The vast majority of SSL sessions across the Internet use only one-way SSL authentication— 

the client authenticates the server by examining the server’s certificate data, public key, and 

associated signatures. If the server wants to identify the user, it typically asks for a 

username and password after the SSL session is established. 

But there are some applications that use SSL client certificate authentication as well as 

SSL server authentication. This is called mutual authentication, but since the server 

authentication is nearly always done anyway, people simply think of it as “client 

authentication with client certificates.” 

19



How all the clients got their certificates is a management problem all in itself. Typically all 

the clients are members of a well-funded organization (like a branch of the military) or Wall 

Street traders, for instance. And often the certificates reside on smart cards or other 

devices where they are accessed over public key cryptography standard (PKCS) protocol 

#11. 

Part 8 of the DevCentral series on SSL profiles provides a detailed breakdown of exactly 

how client certificate authentication works within the TLS handshake. 

Historically, the most common intersection of client certificate authentication and the F5 

platform occurs in SSL termination and SSL bridging modes: the BIG-IP device is acting 

as the SSL server to a client on the Internet and authenticating that client’s certificate. The 

back-end servers, which trust the BIG-IP system, need to get information about the client 

certificate. There are three ways to forward that client certificate information to the servers: 

• X509 extraction 

The oldest trick (and still one of the easiest) is to extract and insert fields from the 

client certificate’s X509 directory information into the underlying HTTP stream as 

headers. A typical iRules script might include gathering the issuer of the client 

certificate and then inserting it into the HTTP request to the server as “F5_CLIENT_ 

ISSUER=[X509::issuer [SSL::cert 0]]”. See this DevCentral post for a more complete 

example. 

• X509 whole certificate extraction 

A similar method is to extract and insert the entire certificate itself into the HTTP 

stream as a multi-line PEM-encoded header. Obviously, the server-side code will 

have to reassemble the certificate. The server can do the reassembly using a code 

library or by executing the openssl x509 command. The iRules script to do this on 

the BIG-IP device would look as simple as: 

when HTTP_REQUEST { 

if { [SSL::cert count] > 0 } { 

HTTP::header insert “F5CC” [X509::whole [SSL::cert 0]] 

} 

} 

• ProxySSL mode 

There is a way to forward client certificates directly to the back-end server with a 

special F5 SSL setting called proxySSL mode. With proxySSL, the BIG-IP device 

must use the same certificate and key as the back-end server. Clients can then 

connect all the way through to the server and authenticate with their certificates. 

20



The BIG-IP device can provide passive monitoring of the session. ProxySSL should 

only be used when there is a requirement for client certificate authentication directly 

to the back-end servers. See SSL and the OWASP Top Ten later in this document 

for more information about proxySSL. 

F5 recommended practices for client certificates: 

• The SSL profile has a three-way setting for client certificate authentication: none, 

request, and require. When require is used and the client authentication fails for 

some reason (such as an expired certificate or OCSP failure), the user gets an ugly 

browser message. Some administrators use the request setting instead, which 

allows them to receive the certificate but passes the connection through even if 

authentication fails. When using the request setting, also use an iRules script that 

checks the certificate verification result and presents a more aesthetic error 

message or an HTTP 302 redirect. 

• Configure at least one revocation method—whichever one is best supported by the 

certificate authority—for client certificates. Certification revocation lists (CRLs) can be 

supported directly in the SSL profile. The other methods (OCSP and CRL distribution 

point or CRLDP) must be done via iRules. See the revocation section of this 

document for more information. 

• The TLS protocol includes a way to force a new handshake but without breaking the 

TCP connection. This is called a renegotiation and can be used to transition a client 

from one authenticated state (none) to another (client certificate authentication). 

However, the IETF frequently threatens to remove renegotiation, so consider it 

abandoned, and use it accordingly. 

• SSL forward proxy is a special mode that intercepts outbound SSL requests from 

a client on the inside of the BIG-IP platform boundary (inside the data center). This 

mode is used with the SSL outbound visibility deployment scenario. The BIG-IP 

device may try to intercept connections that are using client certificate authentication, 

but it will very likely not know what to do with the resulting connection. Whitelist any 

allowed, known hosts into a bypass list so that the BIG-IP device will not interfere. 

• There is a setting called “retain certificate” in clientssl profiles. This setting will 

improve the user experience by caching the client certificate across multiple 

connections (thereby avoiding extra popups in the browser). Enable this setting 

unless using a rare high-bandwidth, low-memory configuration where the extra few 

kilobytes associated with each connection could impact overall system performance. 

21



SSL failover options 

Full SSL handshakes are computationally expensive. This is one reason enterprises 

continue to rely on ADCs stuffed with cryptographic acceleration hardware for SSL 

decryption. 

Sites that have significant amounts of SSL traffic need to be aware of this particular 

problem: What happens if the primary ADC stops receiving traffic and the secondary has 

to pick up all those active connections? 

Administrators may say they’d like the secondary device to resume each session exactly 

where the primary left off. In practicality, a seamless “SSL failover” like this is a very difficult 

problem to solve. In fact, the industry hasn’t yet standardized a solution. F5 customers have 

three options to choose from for SSL failover. Two have very similar names: SSL session 

mirroring and SSL connection mirroring. The third, SSL session tickets, is relatively new. 

SSL session mirroring 

Recall that an SSL session is the set of state information that describes an individual SSL 

connection between a client and a server. This state information can be mirrored between 

BIG-IP devices in a traffic group. When session information is mirrored, a client can connect 

to any device in the group and resume the SSL session, avoiding the expensive and 

higher-latency full SSL handshake. 

Figure 5: SSL session mirroring enables resumption of an SSL session on any device in the group 

SSL session mirroring is relatively straightforward and controlled by two knobs. The first 

control is to toggle a system variable named statemirror.secure. Through the command 

line interface, an administrator can issue the following command: 

(tmos)# modify sys db statemirror.secure value enable 

22



This must be done prior to creating SSL profiles that include the new SSL session mirroring 

attribute, and on all units in the cluster. It will cause the mirroring channel to drop and 

reestablish. 

The second control is to enable the SSL mirroring attribute in the clientssl profile associated 

with the application’s virtual server. 

Figure 6: Enabling the SSL session mirroring attribute in the clientssl profile 

The attribute can also be set with this command: 

(tmos)# modify ltm profile client-ssl test1 session-mirroring enabled 

Both the check box and the TMSH command will warn if the statemirror.secure variable 

discussed above has not been set. 

SSL connection mirroring 

The second and more sophisticated approach to mirroring is SSL connection mirroring—a 

method administrators often think they want. Connection mirroring takes session mirroring 

one step further: Connections to a virtual server that has connection mirroring enabled can, 

in theory, be continued without interruption or restarted by any device in the device group. 

In reality, ADC administrators have found that connection mirroring (SSL or otherwise) is 

largely unnecessary due to the stateless and temporal nature of HTTP. The performance 

cost and additional latency added by full connection mirroring is rarely worth the benefit of 

fully mirrored connections for HTTP. This means that the number of valid applications for 

connection mirroring is a very small number indeed, and most F5 customers use it only for 

specific applications, such as long-term VPN tunnels. 

SSL connection mirroring has the following restrictions: 

• SSL connection mirroring is not compatible with the HTTP profile. 

• Server side SSL connection mirroring is not supported. 

• DTLS connection mirroring is not supported. 

23



• SSL connection mirroring is incompatible COMPAT ciphers. 

• Multiple failover is not supported. 

• Failback is not supported. 

• iRules should not be applied to a virtual server using SSL connection mirroring. 

• The database variable statemirror.secure must be enabled. 

F5 recommended practices for SSL connection mirroring 

• Only enable SSL connection mirroring for long-lived, non-HTTP sessions. 

• Under high connection rates, viewing tmctl ha_stat may show “overflows” 

incrementing. To mitigate this problem, change the database variable 

statemirror.queuelen to 256M. 

• If connections are occasionally lost on reset, enable the database variable 

statemirror.verify, which will take an extra step to verify the successful mirroring 

of each packet during normal transactions. 

SSL session tickets 

The final option for mirroring is the use of a feature that’s relatively new to the world of SSL: 

called session tickets, it is defined by RFC 5077. SSL session tickets work like TCP syncookies. 

The server (the BIG-IP device in the cases of SSL bridging or SSL termination) 

can take the state information associated with the client connection, encrypt it, give it to 

the client (as a ticket), and then forget it. 

When returning with a new connection, the client can present the encrypted session ticket 

to the BIG-IP device, which will decrypt it and—voila!—the BIG-IP device has the needed 

session information and can resume that session without remembering everything. 

SSL session tickets make the session stateless for the ADC. This has three benefits: 

• The session can be resumed by a different BIG-IP device. 

• Sessions take less memory per connection. 

• The BIG-IP devices become more resilient against session-based denial-of-service 

(DoS) attacks. 

Not all browsers and clients support TLS session tickets yet. Currently, a virtual server, if it 

wants broad reach, must implement both session caching and SSL session tickets. For 

administrators, having to manage both negates some of the benefit of SSL session tickets. 

24



The good news is that browsers and other TLS clients are upgrading quickly and becoming 

compatible with session tickets. 

F5 recommended practices for all SSL mirroring: 

• Use both SSL session mirroring and SSL session tickets for inbound data center 

and enterprise applications. 

• A smaller number of organizations may want to use SSL connection mirroring, but 

only for applications with exclusively low-bandwidth, long-lived, non-HTTP 

connections. 

• Applications that are under extreme memory strain due to circumstances such as 

SSL connection floods should use session tickets exclusively. 

Cipher agility 

Handshake ciphers: RSA vs. DSA vs. ECC 

Since the beginning of the SSL protocol, RSA has been the main choice for key exchange. 

Over time, as brute force attacks became more feasible, RSA key lengths had to become 

longer. Today the RSA keys are so large that the key exchange is a very computationally 

expensive operation. Elliptic curve cryptography (ECC), a newer variant of asymmetric 

cryptography, promises to provide equivalent security with much shorter keys and a 

correspondingly lower demand for computing resources for key exchange. 

Figure 7: The relative key lengths of RSA (factoring modulus) and ECC 

Source: www.keylength.com 

25



The digital signature algorithm (DSA) standard was proposed by the National Institute of 

Standards in 1991 and has become a U.S. government standard. A site that interacts with 

federal agencies may have a need for DSA. DSA key length is the same as for RSA. 

RSA is ubiquitous, DSA is used by sites interacting with federal agencies, and ECC is poised 

to become the standard in the future. Which type of certificate should a site support? 

The BIG-IP platform can support all three simultaneously on a single virtual server. Every 

BIG-IP virtual server must have at least an RSA certificate, but can also have a DSA 

certificate and an ECC certificate (called ECSDA). 

F5 recommended practices for handshake cipher selection: 

• Configure new virtual servers for both RSA and ECC handshakes. Administrators will 

likely know if they already have a DSA requirement. 

• To support multiple certificates: 

1. First, upload the certificates to the BIG-IP device. In the client SSL profile, select 

the new files from the Certificate, Key, and Chain drop-down lists as appropriate. 

Figure 8a: Adding an ECDSA key to the client SSL profile 

2. Next, click Add to add the certificate and key to the Certificate Key Chain. 

Figure 8b: Adding the certificate and key to the key chain 

26



3. Under Ciphers, place a colon after DEFAULT and then list which ECC ciphers to 

support. 

Figure 8c: Indicating support for ECDHE-RSA-AES128-GCM-SHA256 

4. Use the following cipher string names to enable the following groups of ciphers: 

ECDHE, ECDHE_ECDSA, ECDH_ECDSA, DHE and DHE_DSS 

5. Save the configuration by clicking Update. 

At this point the BIG-IP device will provide both RSA and ECDSA certificates to any 

connecting client. 

Disabling SSLv3 

SSLv3 is no longer secure, as demonstrated by the POODLE attack in 2014. Google has 

removed fallback support in Chrome, and RFC 7568 deprecates its use. SSLv3 should no 

longer be used by client software. Applications that comply with the PCI DSS specification 

must discontinue use of SSLv3 and TLSv1 when PCI 3.0 takes effect in mid-2016. New 

PCI DSS deployments must already be disabling SSLv3 and TLSv1. 

In version 12.0 of the BIG-IP system, F5 has removed the SSLv3 protocol from the DEFAULT 

cipher string. That is, any virtual server using a clientssl profile with the cipher string 

DEFAULT will not accept client connections with SSLv3. Some administrators use a custom 

cipher string for each clientssl profile, preserving the cipher list from version to version. For 

example, an administrator running version 11.6 might have defined a cipher string like this: 

‘TLSv1_2+AES256:SHA256:TLSv1_1:TLSv1:-RC4:SSLv3+RC4:!DES:!EXPORT’ 

Obviously, the way to remove SSLv3 from this cipher string would be to delete the 

‘:SSLv3+RC4’ phrase. Before removing SSLv3, the administrator may want to know if the 

site is processing a significant amount of SSLv3 traffic. An administrator can determine the 

percentage of version 3 SSL connections by querying the clientssl profile statistics on the 

device. The statistics aren’t attached to the application’s virtual server; they are collated at 

the associated clientssl profile. 

27



Suppose that an administrator has a created a clientssl profile named ssl-exchange-2. 

Query the protocol counters via the following TMSH command: 

(tmos)# show ltm profile client-ssl ssl-exchange-2 

F5 recommended practices for SSLv3 

• Prepare to disable SSLv3 and TLSv1. 

• Use this nmap script to locate any servers on the network that are still negotiating 

SSLv3. 

More information on tracking SSLv3 use on F5 devices can be found on DevCentral. 

Figure 9: Support for SSLv3 after the POODLE attack (blue = Internet, red = F5 devices) 

Key Management 

G.K Chesterson once opined, “An adventure is only an inconvenience rightly considered. 

An inconvenience is only an adventure wrongly considered.” So it is with the oft-maligned 

art of certificate management. Some may consider it an inconvenience, but…. 

Who are we kidding? There is no way to make key management sexy. With some patience, 

however, a veteran system administrator can take some of the adventure out of a task that 

is fraught with operational and security pitfalls. 

28



Certificate expiration notification 

Certificate expiration notification may seem like an arcane tidbit not worthy of the first 

position in a certificate management discussion. Over a decade, however, the solution to 

certificate expiration has been requested from F5 far more often than any other vexing little 

problem. 

This issue comes out of this scenario: BIG-IP LTM is delivering hundreds of websites and 

applications for an enterprise. Some subset of those, still in the hundreds, is SSL-enabled. 

Each of these has its own certificate, and each certificate has its own expiration date. On 

any given week, one or more certificates may expire, which will cause the associated 

website or application to become unavailable. 

So how does an administrator stay on top of this whack-a-mole game of expiring 

certificates? 

There are a couple of recommended ways to monitor expiring certificates on the BIG-IP 

platform. However, most administrators of medium to large organizations prefer an external 

certificate management system because the organization has keys and certificates in many 

locations, not only on the BIG-IP system. In particular, F5 customers have had success with 

two external solutions: Venafi and Symantec. 

The following tmsh sys crypto check-cert command was designed specifically to check 

for expiring certificates. 

(tmos)# run sys crypto check-cert 

CN=www.sconats.com,OU=Domain Validated,OU=Thawte SSL123 certificate, in file / 

Common/sconats_rsa.crt expired on Mar 12 23:59:59 2015 GMT 

CN=192.168.2.55,OU=Marketing,O=F5 Networks,L=Loveland,ST=Colorado,C=US in file / 

Common/3bd_rsa_1k.crt expired on Apr 30 23:57:36 2015 GMT 

The check-cert command will scan through all of the known certificate objects on the 

system. By default, check-cert will log expired or expiring certificate subject names to the 

/var/log/ltm file and print them to standard output. Users with the administrator, system 

manager, or certificate administrator role can run the check-cert command. 

F5 recommended practices for certificate expiration notice: 

• To manage certificates across an enterprise, explore external certificate management 

systems from Venafi and Symantec. 

• Audit not just for expiring certificates, but also certificates with weak signatures (MD5 

or SHA1) and weak keys (1024-bit). 

29



• Use the check-cert command to monitor for expiration. For a full description of 

check-cert, run the ‘help’ command: 

(tmos)# help sys crypto check-cert 

• The check-cert command is automatically run once a week on the BIG-IP system. 

When check-cert finds expiring or expired certificates, it will write the messages to 

/var/log/ltm. The administrator can then create a custom SNMP trap to have the 

BIG-IP system email any results. Solution 3667 has instructions on creating custom 

SNMP traps. 

• Read more information about certificate expiration monitoring in Solution 14318: 

Monitoring SSL Certificate Expiration on the BIG-IP System. 

The certificate manager role 

Large enterprise organizations with 10,000 or more employees usually have dedicated 

security teams, and often they will have a person or persons whose primary job is 

certificate management. Typically these individuals are not on the network operations team, 

are not necessarily privy to the details of network architecture, and are not empowered to 

change the configuration on network-critical devices such as load balancers or ADCs. 

It is for these individuals that the certificate manager role was developed. These users can 

be assigned to the certificate manager role when they authenticate to the BIG-IP system. 

The role has management access only to objects related to certificates and key 

management systems. 

Figure 10: Assigning the certificate manager role 

A user with certificate manager role can: 

• Generate and import SSL keys and certificates. 

30



• Delete SSL keys and certificates. 

• Manage on-board hardware security module (HSM) subsystems. 

• Configure expiration notifications for certificates. 

• Manage device certificates. 

• Manage the F5 Secure Vault key protection feature. 

The certificate manager cannot make network changes or modify any aspect of 

applications managed by the BIG-IP platform. 

Key protection 

SSL keys are among an IT organization’s most prized assets. An attacker who gained 

possession of a target’s SSL key could impersonate the target’s applications and create 

the ultimate phishing portal. 

Because of this, organizations treat their SSL private keys very, very seriously. Many 

security architectures are designed to keep SSL private keys deep inside the data center, 

away from the perimeter, to minimize possible threat exposure. 

BIG-IP devices handle a large portion of data center SSL traffic and often retain dozens of 

high-value SSL keys. Certificate managers and administrators need ways to deploy SSL 

keys onto the BIG-IP devices while minimizing their exposure. 

BIG-IP devices use three methods to minimize exposure of plaintext SSL keys. Two of 

these involve the FIPS 140-2 standard. 

FIPS 140-2 standard 

FIPS 140-2 is a United States federal standard defining requirements for advanced key 

protection in software and hardware systems. FIPS 140-2 consists of four security levels: 

Level Security Description 

1 Basic At least one of the approved algorithm; rare 

2 Tamper-evident Typically a software implementation and a sticker 

3 Tamper-resistant Physical key protection and user authentication 

4 Tamper-resistant II Very sensitive physical protection 

Some organizations with an interest in FIPS 140-2 will find that the second level meets their 

requirements. Other organizations with more sensitive data may require the physical key 

31



protection provided by level 3 devices, which are called hardware security modules (HSMs). 

Often level 3 devices are operated in level 2 mode to absolve the HSM user (often called 

the security officer) from having to log in to the device after every reboot. 

Integrated FIPS 140-2 HSM 

The HSM is a clever piece of technology. Integrated HSM devices are hardware boards 

designed for insertion into an appliance. SSL keys are generated within, or imported to, the 

HSM. Ever after, the keys cannot be exported from the HSM. The controlling software (for 

instance, the BIG-IP system) uses the HSM as an SSL accelerator, offloading to it 

decryption requests. 

Each HSM component has a rigorous design, testing, and certification schedule. As a 

result, the performance of all HSM units is typically not equal to that of non-HSM SSL 

accelerators. 

Specific F5 hardware platforms have the HSM integrated directly onboard the system; find 

more information in the BIG-IP Platform FIPS Administration Guide. Organizations interested 

in the integrated HSM option must procure one of these specific platforms; the HSM option 

cannot be added to an existing non-HSM appliance. 

Platform 

SSL TPS 

10200v 9000 

7200v 9000 

5250v 5000 

Platforms based on the F5 VIPRION ® ADC do not have an HSM option. The F5 Virtual 

Clustered Multiprocessing technology (vCMP) is not compatible with integrated FIPS 

HSMs. 

Network HSM key protection 

The FIPS 140-2 level 3 HSMs have evolved to become standalone devices called network 

HSM or netHSM devices. These devices reside on a network and service requests from 

other appliances on or across the network. Many organizations are moving to architectures 

that consolidate key management into a single cluster of network HSM devices. 

F5 supports integration with, and provides integration guides for, two brands of network 

HSM devices: Thales and Safenet. 

32



F5 recommended practices for FIPS 140-2: 

• In high-security environments, use FIPS 140-2 options that include either an onboard 

HSM or a network-based HSM solution such as those from Thales and SafeNet. 

• Plan for HSM failure contingencies. With integrated HSM devices, the situation can 

be recovered with the security officer password. Take care to keep and secure this 

password. 

• Create a contingency plan for the failure of both HSMs in a two-device cluster. 

Typically this plan will call for additional HSM units to function as backups. 

• Generate SSL private keys within the HSM for maximum security. However, some 

administrators choose to generate the keys on a separate device. That key 

generation device should have a hardware random number generator and should 

be in a safe location in the network. 

• The FIPS 140-2 specification requires the use of specific ciphers. Use following 

cipher string to ensure that these ciphers get preference: 

NATIVE:ECDHE+AES:ECDHE+3DES:ECDHE+RSA:!SSLv3:!TLSv1:!EXPORT:!DH:!ADH:!LOW:!MD5:!RC4: 

RSA+AES:RSA+3DES:@STRENGTH 

• Monitor the number of transactions per second (TPS) of a BIG-IP device using 

SNMP. There is no direct SNMP OID to monitor FIPS 140-2 TPS, but we can 

calculate the FIPS TPS using several OID. In addition, if all clientssl profile on the 

BIG-IP system are using keys of the security type FIPS, then the following OID can 

be used, since it represents the TPS for the entire system: F5-BIGIP-SYSTEM-MIB::sy 

sClientsslStatTotNativeConns 

• Query the TPS for any individual clientssl profile via an OID named for the profile 

itself: 

F5-BIGIP-LOCAL-MIB::ltmClientSslStatTotNativeConns.”/Common/yourprofile1” 

Software key protection 

All non-FIPS F5 appliances can protect passphrase-encrypted keys by storing only the 

encrypted key on disk. The key that protects the encrypted passphrases is stored in a 

chip within the BIG-IP device. 

On the disk, a passphrase-encrypted key will have a header that includes the encryption 

method: 

33



-----BEGIN RSA PRIVATE KEY----- 

Proc-Type: 4,ENCRYPTED 

DEK-Info: AES-128-CBC,3D566DD5B6DCAD115F9969835F53D942 

0FbIpHrdPj2ypaVqViLunmNGAn8bOayuoEPALDYOzwzqUSNXUAwwlPgmoqsWAmwL 

6Fxhgy7m0w70Whhfm8z6dvT063qWBcBgsT4e5yz8L6sfx/zR2pBcYOjTGJ+YzKGs 

UMFXfe/GG9RmDSPNHCsTuSbhJlOC7HrPTHvL/YVTvOa8K7Kqp5aRLE3N4nk5Tobg 

… 

The passphrases used to decrypt the individual keys are themselves encrypted by an F5 

feature called Secure Vault. The Secure Vault stores its own key in a hardware chip in the 

physical appliance. 

Secure Vault should not be thought of as “software FIPS.” It is designed merely to ensure 

that the SSL keys are not stored in plaintext in the configuration. This is especially important 

considering that many administrators will periodically store device configuration archives on 

backup systems in lower-security zones (such as in the cloud). 

F5 recommended practices for software key protection: 

• If FIPS 140-2 is not being used, certificate managers should use passphraseencrypted 

SSL keys protected by the Secure Vault feature. Passphrase-encrypted 

SSL keys can be imported to the BIG-IP system directly when included in PKCS 12 

file archives. More information can be found by viewing the help for the sys crypto 

pkcs12 command: 

(tmos)# help sys crypto pkcs12 

• Set a specific passphrase to unlock the master key when using the Secure Vault 

feature. A specific passphrase enables the manager to later recover all the keys from 

a backup file, even if the original hardware key is unavailable. More information about 

setting a specific passphrase for Secure Vault can found by viewing the help for the 

sys crypto master-key command. 

(tmos)# help sys crypto master-key 

Revocation verification 

The Achilles heel of the public key infrastructure (PKI) has always been defining the process 

for handling compromised private keys. The trust system of PKI resides in the chains of 

signed public keys. However, when one of the associated private keys is compromised, 

there is no easy way to inform the participants of the PKI system. Neither is there an easy 

way to revoke a certificate and then distribute the revocation information to all who need it. 

34



The PKI community has, over time, developed five mechanisms for distributing revocation 

information: 

1. Do nothing. 

2. CRL files. 

3. CRL distribution points. 

4. OCSP servers. 

5. OCSP stapling. 

Use Case 

Consumer website 

Large member website 

Large enterprise 

Federal 

SMB 

Revocation Mechanism 

OCSP stapling or do nothing 

OCSP stapling 

CRL distribution points 

OCSP servers 

CRL files 

Each certificate has a serial number designated by the issuing certificate authority (CA). 

When a CA is informed that a customer’s private key has been stolen or otherwise 

compromised, the CA adds the associated certificate’s serial number to a giant signed list 

of compromised certificate serial numbers. The list of all bad (untrustworthy) certificates 

is signed by the CA itself and periodically published. The BIG-IP platform supports the 

certificate revocation list distribution methods described below. 

When to use certificate revocation 

Certificate revocation is a necessary part of PKI, but that doesn’t mean an F5 administrator 

needs to configure it. For an F5 administrator, certificate revocation matters most when 

verifying a client or server certificate. 

In a typical HTTPS session, the client verifies the server’s certificate but not vice versa. 

Because the BIG-IP device is usually acting as the HTTPS server, there is usually no need 

to configure certificate revocation on it. 

The only times certificate verification needs to be configured on a BIG-IP device are: 

• When the BIG-IP device is acting as an SSL client over an untrusted network. The 

paranoid security administrator will, of course, assert that all networks should be 

35



considered untrusted, but many organizations do maintain different levels of network 

trust. 

• When the BIG-IP device is acting as an SSL server but is also authenticating clients 

via SSL certificate authentication. 

• When the BIG-IP device is acting as an HTTPS server and wants to provide its 

revocation status to connecting clients via OCSP stapling. 

F5 recommends practices for each revocation method use case shown in Figure 13. 

Method 1: Certificate revocation lists 

The oldest mechanism for the distribution of compromised certificate serial numbers is 

simply a serial file called a certificate revocation list (CRL, sometimes pronounced “krill”). 

The file is signed by the associated CA and made available on an FTP or web server. 

Interested parties can download the file and make it available offline to their web server 

or ADC. 

Using straight-up CRL files is the most architecturally straightforward revocation distribution 

method, but it is also most error prone. Common errors include: 

• Difficulty retrieving the CRL file (for example, due to network errors). 

• Growth in CRL file size, consuming resources. 

• Corrupt CRL files, which happens more often than you might think. 

• Bad or unverifiable CA signatures on CRL files, which are also disturbingly frequent. 

In addition, BIG-IP devices have limitations on the maximum size of CRL files. The following 

table shows the maximum size supported by each version of the BIG-IP system. 

BIG-IP System Version 

Max CRL File Size 

12.0 64 MB 

11.4.0 – 11.6.0 64 MB 

11.0.0 – 11.3.0 32 MB 

10.0.0 – 10.2.4 4 MB 

For all of these reasons, straight-up CRL files are not a popular distribution mechanism. 

But there can be times when CRL files make sense. 

36



F5 recommended practices for CRL file use: 

• Use only for private certificate authorities such as an internal IT CA or test CA. 

• Use only for small sets (less than 100,000) of revoked certificates. 

• Automate the process of retrieving the CRL file from the certificate authority. 

• Ensure that the CRL file is properly verified, not 0 length, includes a proper signature, 

and hasn’t expired. 

• Convert the file, if necessary, to the required PEM format. 

• Finally, copy the validated and converted CRL file to the BIG-IP device and instruct 

the device how to use it. 

Historically, administrators that rely on CRL files have found it better to develop an 

automated process on an external device (not the BIG-IP device itself) for CRL file updates. 

The reason for the external device is that many BIG-IP devices are never assigned a DNS 

server (so they can never be susceptible to frequent DNS failures). It is not uncommon for 

a CA to change the IP addresses of their CRL servers, which becomes problematic for the 

BIG-IP device because it cannot resolve the CRL server name. 

Certificate administrators who want the BIG-IP device to download and verify the CRL file 

can use a single command: 

(tmos)# modify sys file ssl-crl gdcrl source-path http://godaddy.com/repository/ 

gd.crl 

Use the F5 iCall ® technology subsystem to schedule the update periodically. (Special 

thanks are due to Matthieu Dierick for the iCall script.) 

create sys icall script CRL 

sys icall script CRL { 

app-service none 

definition { 

tmsh::modify sys file ssl-crl gdcrl source-path \ 

https://godaddy.com/repository/gd.crl 

puts “loading CRL” 

} 

description none 

events none 

} 

create sys icall handler periodic START first-occurrence 2013-12-06:16:15:00 

interval 30 script CRL 

37



While the iCall feature is an excellent solution when run on a BIG-IP device, many 

administrators use a dedicated device (such as a standard Linux server) with a bash script 

to update many CRLs at once. The DevCentral Codeshare includes an example of such a 

script. 

Method 2: OCSP 

The PKI community developed a protocol that would provide the same information given by 

a CRL file but in a simple request-response fashion. The OCSP is designed so that a client 

can request the status of any particular certificate via its serial number and get a response 

from an agent of the CA. Typically these agents are separate servers (called OCSP servers 

or OCSP responders). 

A modern CA will publish the URL to its associated OCSP server within its own CA 

certificate. For example, Digicert lists its OCSP server as ocsp.digicert.com. 

Figure 11: An example of OCSP information for a CA 

38



While OCSP was originally seen as a giant step forward from dealing with clunky CRL files, 

administrators have since realized that OCSP is imperfect for different reasons: 

• Querying a separate OCSP server for each connection increases latency and leads 

to a degraded browsing experience. 

• OCSP servers are not typically provisioned for high availability situations. This is 

noticeable in that the servers are not reachable 100 percent of the time. Therefore 

browsers have learned to “fail open” with OCSP—meaning that if they cannot 

successfully connect to an OCSP server, they will proceed with the connection 

anyway. 

• Attackers have found interesting, trivial ways to defeat OCSP. A simple DoS attack 

against the OCSP server will work. So will sending the number 3 during a man-inthe-middle 

attack. 

For these reasons (and particularly the first), modern browsers are starting to ignore OCSP 

servers and aggregating the various CA CRL databases. 

With all that said, there are still valid use cases for OCSP. For example, military networks 

have trusted subnets and requirements to use OCSP servers. In these cases, where 

attackers theoretically cannot perform a simple DoS of the OCSP nor man-in-the-middle 

its traffic. For these cases, F5 has the following recommendations for configuring OCSP. 

F5 recommended practices for OCSP servers: 

• Instead of using a single OCSP server, use an OCSP responder pool to maximize 

availability. 

• Use an OCSP monitor to monitor the health of your OCSP servers. 

• Consider OCSP with a CRL fallback for those times when OCSP servers are down. 

(Note that this achieves maximum operational complexity.) 

Method 3A: OCSP stapling for clients 

A much faster and more interesting mechanism derived from OCSP is called stapling. When 

a PKI client sends an OCSP request about a particular certificate, what the client is looking 

for is a response that says, “The certificate is good” or “The certificate is revoked.” This 

response must be signed by the OCSP server. Because the OCSP server asymmetrically 

signs the message, it doesn’t really matter which device delivers the signed message! 

Therefore the message can simply be blended into the SSL handshake by the ADC. 

39



Figure 12: OCSP stapling, in which the client doesn’t have to communicate with the OCSP responder 

RFC 4366 defines a TLS extension whereby the TLS server itself can fetch that signed 

message and then present it along with its certificate to the client. In this fashion, the client 

receives the certificate and the status message saying that the certificate is valid without 

having to connect to a separate server. The OCSP status message includes a recent time 

stamp so the client has some assurance that the status is fresh. The status response from 

the OCSP server is cached by the server and then “stapled” into each connection from the 

client. For the HTTPS client, the HTTPS server, and the OCSP responder, OCSP stapling is 

the best of all worlds. 

OCSP stapling is different from the other verification methods because the act of stapling 

assists the party trying to verify the certificate used by the BIG-IP device. Consider it a 

courtesy to clients connecting to the application or service. 

F5 recommended practices for OCSP stapling for clients: 

• Enable OCSP stapling on the BIG-IP device by defining the appropriate objects in 

the SSL profile configuration. 

• Use the SSL Labs tool to test that OCSP stapling is working. 

• Build a script that uses the openssl s_client –status command to check the status, 

then add the script to an automated process to ensure it works over time. 

40



• OCSP stapling implementations may vary depending on the registrar, and 

organizations often use more than one registrar. Validate your OCSP stapling 

configuration for each registrar you use. 

Method 3B: OCSP stapling for servers 

An administrator can be forgiven for assuming that the BIG-IP device will simply check for 

OCSP stapling when using server-side SSL profiles. It does not. There’s actually a reason 

for that: Traditionally, IT administrators use only IP addresses for server pool members to 

avoid outages on DNS errors. This means that, strictly speaking, the BIG-IP device cannot 

perform real server certificate verification because it cannot match the IP address to the 

certificate’s DNS name. Typically those administrators will trade the security of a verified 

serverssl connection in favor of high availability by implicitly trusting that portion of the 

network. While that might not be the most secure strategy, it is a common one. 

Even where strict certificate verification is unavailable, it is still possible to check for OCSP 

revocation via stapling. Using what is called an external monitor, an administrator can check 

the revocation status of SSL server pool members and then mark them down if they get 

revoked. For organizations that use only IP addresses at their ADC, this may be the 

preferred approach. 

F5 recommended practices for OCSP stapling for servers: 

• Use a BIG-IP device “external monitor” to examine OCSP responses stapled into 

serverssl connections. External monitors are defined in the Local Traffic section of 

the configuration. 

• This DevCentral Codeshare script is an example of an external monitor that can be 

used to mark a node down when its certificate status is revoked. 

• Note that it is better to look for the specific revoked status, and, if absent, mark 

the node as up. This is because there are many reasons a node may be unable to 

respond, commonly including being down for maintenance. The TCP monitor can 

mark that node as down. 

Method 4: CRL distribution points 

The fourth and final method of checking for certificate revocation is CRLDP, a way of using 

existing corporate directories as revocation checkpoints. The technology is fairly mature, 

especially when used in an Active Directory environment. CRLDP is typically used for client 

certificate authentication in enterprise environments with BIG-IP ® Access Policy Manager ® . 

41



CRLDP can also be sometimes be found in the inbound retail deployment scenario. For 

example, the certificate authorities GoDaddy and Entrust issue certificates with CRLDP 

information embedded in their X509 data. 

F5 recommended practices for CRLDP: 

• Verify that your BIG-IP device is configured to use DNS and not simply IP addresses. 

• A BIG-IP device using CRLDP must, of course, have a route to the CRLDP servers. 

If the CRLDP servers are on the Internet, the BIG-IP device must have an outbound 

Internet route. 

• Check the size of the CRLs to confirm that they are not too large for the BIG-IP 

system. (See the table on p. 36.) 

Visibility and Control 

Security management depends partly on visibility into traffic—or the ability to provide that 

visibility to security devices such as web application firewalls (WAFs)— so that it may be 

screened for known threats. Of course, SSL by definition obscures data. So how does an 

administrator gain the visibility to make the best use of his or her security investments? 

Several approaches maintain security while effectively revealing malicious traffic. 

SSL and the OWASP Top Ten 

The Open Web Application Security Project (OWASP) categorizes and rates classes of 

application vulnerabilities every year into its OWASP Top 10 list. One of the highest priority 

classes of vulnerabilities is “insufficient transport security,” by which the OWASP group 

means not enough SSL. 

One use case for providing transport security to an application is via SSL termination and 

then sending the decrypted traffic through a WAF. a device specifically engineered to foil 

application attacks such as those found in the OWASP Top Ten. One effect of SSL bridging 

mode, where the ADC decrypts incoming traffic and then re-encrypts the traffic before it 

leaves the ADC, is that the ADC becomes the singular place where an application firewall 

can be deployed. 

While SSL termination and bridging are the primary technologies used to provide visibility 

into SSL for application security solutions like a WAF, there is a third way. The BIG-IP device 

can be configured to eavesdrop on an encrypted session between an incoming connection 

and a back-end server. This functionality is referred to as proxySSL. One of the only 

cases where proxySSL is preferred is when a back-end server requires client certificate 

42



authentication, since client certificate authentication to the back-end server is incompatible 

with SSL termination and bridging at the BIG-IP device. 

With proxySSL, the BIG-IP device shares the same key and certificate as the back-end 

server, and the browser completes the handshake (including client certificate authentication) 

with the back-end server. The BIG-IP device can then decrypt the session key (because it 

shares the same key and certificate as the server). The ADC uses the session key to decrypt 

the rest of the session and forwards the decrypted payloads to a security device like a WAF. 

The security device can then inspect and report on the content. 

The use of proxySSL should be restricted to this specific case. Because proxySSL requires 

a shared-key environment, it is ultimately incompatible with the likely security roadmap of 

the TLS protocol: Forward secrecy was designed to foil systems exactly like this and is 

already preferred by over 60 percent of Internet web sites. 

F5 recommended practices for application security visibility: 

• Use SSL termination or SSL bridging to provide inbound visibility to an application 

security device like a WAF. 

• If proxySSL is required to maintain client certificate authentication to the back-end 

web server, configure the server to use only RSA-based ciphers. Avoid forward 

secrecy because it breaks shared-key systems like proxySSL. 

• When proxySSL is used with a WAF, the WAF can find malicious traffic and then 

signal the ADC to block those connections. The only way to block at this point is to 

send a reset (RST) packet to the client to kill its connection. 

• Ensure that local logging is not used for production systems. High-speed logging to 

remote logging servers or SIEMs is preferred. 

SSL outbound visibility 

The outbound SSL deployment scenario for the ADC is a relatively new, but rapidly growing, 

phenomenon. This deployment scenario has been driven by enterprises with a need to 

monitor and sanitize their outbound web traffic in attempts to mitigate advanced persistent 

threats (APTs). A typical APT will start with a spear phishing campaign to introduce malware 

tailored specifically to invade a single organization. Some of the most damaging penetrations 

of the last five years have been as a result of APT activity, including the infamous 2011 breach 

of the world’s premiere security brand, RSA. (Search for Anatomy of an Attack on the RSA 

blog). 

43



These spear phishing campaigns begin with a series of emails injecting infected PDF, Word, 

or Excel files or simply enticing links that result in a malware download. The initial malware 

drop may be very quiet, performing only a few simple tasks such as keystroke logging or 

email address book collection. 

The attackers can then build on their received intelligence to patiently infiltrate further into 

the target over months or even years. 

Figure 13: The APT life-cycle 

Source: Creative commons license, Dell SecureWorks 

Detecting the subtle activity of spear phishing and malware activity is among the top 

priorities of security administrators today. High-profile technologies such as sandboxing 

and next-generation firewalls (NGFW), which have been developed to assist administrators 

in detecting these threats, are being rapidly adopted. Administrators deploy the security 

devices in a chain so they can complement each other (known as defense-in-depth). 

The next problem to solve is the fact that these new technologies are often blind to 

encrypted traffic. Malware and spear phishing authors know this and are very quickly 

moving to encrypt all communication between their malware and the outside world. 

Security analysts estimate that by 2017, 100 percent of new malware will use SSL to hide 

its tracks. 

44



A deployment scenario sometimes called an SSL air gap or SSL intercept is emerging to 

address the APT problem and assist the chain of outbound visibility devices (such as 

sandboxes). The SSL air gap solution typically consists of an ADC on either side of the 

visibility chain. The ADC closest to the users decrypts their outbound traffic and sends the 

decrypted plaintext through the chain. The chain, which can now see the content, applies 

policy and controls to the plaintext, detecting and sanitizing spear phishing and malware. At 

the other end of the chain, another ADC re-encrypts the traffic as it leaves the data center. 

In some cases, instead of going through a second ADC, the traffic can be looped back to 

be re-encrypted by the first ADC. 

Internal 

Clients 

Encrypted 

LTM 

AFM 

Unencrypted 

Inspection Air Gap 

Unencrypted 

LTM 

Encrypted 

SSL/TLS 

Internal 

BIG-IP LTM 

(ingress) 

Security Device(s) 

External 

BIG-IP LTM 

(egress) 

SSL/TLS 

Internet/Public 

Protected sites 

Figure 14: The SSL air gap use case 

The F5 solution for SSL outbound visibility is an F5 iApps ® template for the SSL air gap. 

The template, with its detailed deployment guide, helps an administrator set up the 

necessary configuration items to decrypt and then re-encrypt the outbound traffic. 

This air gap iApp template will work with BIG-IP versions 11.4.0 through 12.0 and above, 

and customers are already using the F5 air gap iApps template with several partner 

technologies. A partial list of those partner solutions includes: 

• The F5 and SourceFire Reference Architecture. 

• The F5 and FireEye Recommended Practices and Deployment Guide. 

• The F5 and WebSense Deployment Guide. 

However, there are some nuances that warrant additional discussion. One of these topics 

is the issue of what traffic not to inspect, and the other is provisioning hardware resources 

within the vCMP subsystem. 

Which sites should bypass SSL inspection 

There are times when an administrator will not want to inspect traffic between a corporate 

user and a web site for liability reasons. Chief among these is when a corporate user 

visits his or her online banking site. If the enterprise administrator snoops on the user’s 

connection and somehow money is incorrectly depleted from the user’s account, the 

45



administrator could be seen as complicit or liable. Therefore, to reduce this complication, 

administrators have learned to whitelist the financial websites. Financial firms have 

experienced security teams and entire fraud departments, so their websites are vastly 

cleaner than a typical website. 

There are a couple of ways to implement such a whitelist for SSL bypass. 

• Using F5 URL categorization 

Several organizations maintain databases categorizing millions (or even billions) of URLs 

and provide this information as a product or service. F5 provides access to a URL 

categorization database through the F5 Secure Web Gateway Services. Secure Web 

Gateway Services users can simply leverage the URL categorization database to instruct 

the air gap iApp template not to inspect at financial websites. 

• Manually maintaining a whitelist bypass data group 

This is the more labor-intensive way to maintain a bypass list. When configuring the iApp 

template, enter the name of a data group that contains the list of IP addresses to bypass. 

As more addresses that should not be inspected are found over time, they can be manually 

added to this list. For smaller, low-touch deployments, this may be a workable option. 

F5 recommended practices for SSL air gap egress inspection: 

• Use the F5 URL categorization service to automatically populate the bypass list. 

• Use transparent mode instead of explicit mode for the SSL air gap inspection. 

Explicit proxy mode works better for legitimate clients but ignores malware, making 

the transparent mode a requirement. 

• The F5 air gap iApp template offers a choice for dealing with Internet sites with 

expired certificates: drop or ignore. There are more expired certificates on the 

Internet than you might suspect, so F5 recommends dropping them, even though 

this may increase the number of inaccessible websites. When “ignore” is specified, 

expired certificates on the Internet may temporarily become valid when the air gap 

rewrites the certificate. 

Provisioning SSL hardware resources to vCMP 

Another intricacy of the air gap solution is resource provisioning. F5 vCMP is a unique 

virtualization-in-a-box platform delivered on higher-end appliances. All VIPRION chassis 

systems can be configured with vCMP. In the vCMP system, one of the host processors 

runs a special version of TMOS that contains an F5 hypervisor. The vCMP hypervisor 

allows multiple virtual guest operating systems (which must be individual versions of TMOS). 

46



In this way, a VIPRION system may be shared among different IT units such as networking, 

security, and DNS. 

Beginning with BIG-IP version 12.0, an administrator can now control if and how SSL 

resources are dedicated within the various guests inside the hypervisor. The following 

options are supported: 

• Dedicated: The guest will be assigned dedicated SSL cores. 

• Shared (default): Guests share from a pool of SSL cores. 

• None: The guest will have no access to SSL hardware (for example, BIG-IP DNS). 

Figure 15: SSL resource dedication options in BIG-IP version 12.0 on the VIPRION chassis. 

This functionality is available on the 5000, 7000, 10000, and 12000 platforms, as well as 

the B2250 blade. 

Mitigating brute force attacks 

The complex nature of SSL continues to allow it to be an attack vector for distributed 

denial-of-service (DDoS) attacks. In addition to complexity, SSL by design blinds network 

equipment to network traffic. The combination of complexity and blindness of SSL makes 

47



it a target for DDoS attacks. As the volume of legitimate SSL traffic continues to increase, 

malevolent DDoS traffic becomes more onerous to discern. As a result, good DDoS 

defense measures have emerged as climacteric for sites, and F5 recommendations 

address how to best mitigate specific classes of DDoS attacks. 

SSL renegotiation attacks 

SSL renegotiation is a feature that allows a client to restart an SSL connection. Since the 

legitimate uses for SSL renegotiation are few and there are several attacks based on SSL 

renegotiation, newer protocols such as HTTP/2 require disabling SSL renegotiation. 

A single client can perform a DoS attack on a server. The premise of the attack is simple: 

An SSL/TLS handshake requires at least 10 times more processing power on the server 

than on the client. If a client machine and server machine were equal in RSA processing 

power, the client could overwhelm the server by sending ten times as many SSL handshake 

requests as the server could service. This vulnerability exists for all SSL negotiations; the 

only mitigation is the ratio between the two participants, which is why SSL acceleration is 

so critical. 

F5 recommended practices to mitigate SSL renegotiation attacks: 

• If renegotiation is not needed for an application, disable SSL renegotiation in the 

clientssl profile associated with the virtual server. 

• If renegotiation is needed, use the many renegotiation options associated with the 

profile, including secure renegotiation, maximum renegotiation counts, and intervals. 

See the SSL Administration guide for the full list of renegotiation options. 

No-crypto brute force attacks 

There is a new class of SSL attacks tools that could be called no-crypto attack tools. These 

new attack tools boost the computational asymmetry between the client and the server by 

orders of magnitude through a pronounced reduction in client workload. Basically, the new 

attack clients do not perform any crypto at all—they just send pre-canned packets that look 

like an SSL handshake but are not. 

In his excellent analysis of handshake attacks, Vincent Bernat writes about these efficient 

attack tools: 

“With such a tool and a 2048 bit RSA certificate, a server is using 100 times more 

processing power than the client. Unfortunately, this means that most solutions, 

except rate limiting, exposed [in his analysis] may just be ineffective.” 

48



So far, these attacks have not been seen in the wild, but discussed in the academic and 

IETF community. 

F5 recommended practices for mitigating no-crypto brute force attacks: 

• The ssl_hx_rlimit iRules script limits the number of connections from a single IP. 

Note that this iRules script could inadvertently block legitimate users originating from 

a so-called mega-proxy. 

• The sslsqueeze_rx iRules script will match and block the exact sslsqueeze 

signature. If an attacker ever changes the payload of the sslsqueeze tool, this iRules 

script will need to be modified to match the new payload. 

• Find more information in the DevCentral article called Mitigating No-Crypto Brute 

Force SSL Handshake Attacks. 

SSL floods 

Unlike the no-crypto attacks, DDoS attacks as a flood of open SSL connections have been 

seen in the wild. These attacks can be a challenge to mitigate for the SSL pass-through 

deployment scenario because many devices on the network are blind to the attack. 

The high-capacity SSL connection tables are largely resistant to SSL floods. A typical SSL 

flood may involve only a few thousand to tens of thousands of empty SSL connections. 

However, even the smallest F5 platform can absorb 500,000 SSL connections or more. 

F5 recommended practices for mitigating SSL floods: 

• Using SSL session tickets can enable legitimate clients to benefit from the session 

cache during an SSL connection flood. See the previous section on SSL failover 

options. 

• In the unlikely event that the BIG-IP device’s connection table does become full, 

connections will be reaped according to the adaptive reaping low-water and highwater 

settings. These can be adjusted downward from the default values of 85 and 

95 to more quickly begin mitigating a “spiky” DDoS, thus reducing the initial attack 

window. Solution 15740 provides more detail on the workings of the adaptive reaper. 

(tmos)# modify ltm global-settings connection adaptive-reaper-lowater 75 

• If the connection flood consists primarily of empty connections, instruct the BIG-IP 

device to be more aggressive about reaping connections by modifying the TCP 

profile associated with the virtual server. During a heavy attack, use smaller and 

smaller values. 

49



(tmos)# create ltm profile tcp tcp_ddos { reset-on-timeout disabled idle-timeout 

15 } 

• The hardware-syn-cookie and zero-window-timeout values of the TCP profile may 

also be adjusted. 

Instrumentation: The SSL statistics panel 

The BIG-IP platform’s SSL statistics panel is a powerful tool that collates useful counters 

for protocol handshake types, key exchange types, and connection failures. To view it, 

click Statistics on the left pane, select Module Statistics, and then click Local Traffic. Under 

Statistics Type, select Profiles Summary and then Client SSL. 

Figure 16: The SSL statistics panel 

In the BIG-IP system version 12.0, the information collected and displayed for SSL includes 

all the fields from the following table: 

50



Statistic Category 

Certificates / Handshakes 

SSL Protocols 

Associated Counters 

Valid vs. invalid vs. no certificates 

Mid-connection handshakes. Secure vs. insecure 

handshakes. 

Insecure renegotiations rejected, SNI mismatches. 

SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, DTLS 

Key Exchange Methods Anonymous Diffie-Helman (ADH), Diffie-Helman (DH) + 

RSA certificate, RSA certificate, elliptic curve Diffie- 

Helman (ECDH) with RSA certificate, ECDH with 

ECDSA certificate, DH + DSS certificate 

Ciphers 

Digest Methods 

SSL Hardware Acceleration 

Session Cache 

SSL Records 

Failures 

Session Tickets 

SSL Forward Proxy 

OCSP Stapling 

AES, AES-GCM, DES, RC2, RC4, no encryption 

MD5, SHA, none 

Full, partial, none (software) 

Size, hits, lookups, overflows, invalidations 

In, out, bad 

Premature disconnects, handshake failures, 

renegotiations rejected, fatal alerts 

Reused, reuse failures 

Connections, cached certificates, destination IP 

bypasses, source IP bypasses, hostname bypasses 

Connections, response status errors, response 

validation errors, certificate status errors, OCSP 

connection HTTP errors, OCSP connection timeouts, 

OCP connection failures 

The statistics panel can provide useful information about the aggregate statistics of all 

clientssl or serverssl connections. It can enable an administrator to see configuration issues 

by noticing a spike in connection errors or connections that shouldn’t have been made. 

Accessing SSL debugging information 

To debug individual connection errors, an administrator or certificate manager may need 

something more surgical than the instrument panel. The TMOS platform allows the 

administrator to turn on verbose instrumentation specifically for SSL connections. Select 

the System menu on the left panel, select Logs, and then select Configuration. Tune the 

SSL control to get more verbose log messages. The maximum setting is Debug, which will 

51



log all messages associated with SSL connections, even those that are purely informational. 

Typically log message are sent to the file /var/log/ltm unless otherwise configured. 

Figure 17: Tuning the SSL logging level 

F5 recommended practices for SSL instrumentation: 

• Use the SSL statistics panel to see a holistic and aggregate statistical view. 

• Change the SSL debug log setting to suit your needs. But note that SSL debug 

mode may have significant performance impacts. Endeavor not to enable it on 

production systems. 

• Give the certificate manager role access to logs. 

• Use remote logging when debugging production systems. This is critical. 

Conclusion 

SSL has been the standard for encrypting transactions for the past two decades. Like all 

technology, SSL has experienced significant changes throughout its life, and the pace 

of change is expected to continue. These changes to SSL covers vast areas, while their 

impact ranges from the annoying to the critical. Changes to ciphers alone include: 

• New ciphers. 

• New classes of ciphers, such as ECC. 

• New approaches to ciphers, such as forward secrecy. 

52


Advanced Threat Protection with FireEye and F5 

SSL has become an attack surface that is particularly vulnerable to DDoS attacks taking 

advantage of the relatively large machine costs associated with hosting SSL server traffic. 

Administrators who wish to stay in front of changes, choosing proactive strategies instead 

of reactive tactics, need to remain aware of the most current options and trends. 

Those proactive administrators can follow F5 recommended practices to not only stay in 

front of existing trends but be prepared for hitherto unforeseen changes and fundamental 

shifts. These recommendations enable an organization to be favorably aligned to the 

existing SSL landscape while gaining the nimbleness to meet new challenges. Following the 

recommended practices optimally positions the organization for future security, scalability, 

and reliability. 

F5 Networks, Inc. 401 Elliott Avenue West, Seattle, WA 98119 888-882-4447 f5.com 

Americas 

info@f5.com 

Asia-Pacific 

apacinfo@f5.com 

Europe/Middle-East/Africa 

emeainfo@f5.com 

Japan K.K. 

f5j-info@f5.com 

©2015 F5 Networks, Inc. All rights reserved. F5, F5 Networks, and the F5 logo are trademarks of F5 Networks, Inc. in the U.S. and in certain other countries. Other F5 trademarks are identified at f5.com. 

Any other products, services, or company names referenced herein may be trademarks of their respective owners with no endorsement or affiliation, express or implied, claimed by F5. 1015 RECP-SEC-66014525-ssl

F5 SSL Everywhere

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?