f5 ssl everywhere recommended practices
TRANSCRIPT
RECOMMENDED PRACTICES
F5 SSL Everywhere
David HolmesPrincipal Technical Marketing Manager
Marty ScholesMarketing Solutions Architect
2
RECOMMENDED PRACTICES
F5 SSL Everywhere
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
RECOMMENDED PRACTICES
F5 SSL Everywhere
3
IntroductionThe 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 custom-
built 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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
4
About the acronyms SSL vs. TLSVagueness 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 ScenariosFor 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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
5
REFERENCE ARCHITECTURE: SSL EverywhereCONTENT TYPE: Product MapAUDIENCE: Security ArchitectCUSTOMER SCENARIO: SSL Everywhere (Inbound)
SSL Termination and Inspection + Cipher Agility + SSL Transformation
+ Intelligent Traffic Management + SSL Re-Encryption
BIG-IP Platform
BIG-IP Platform
SSL Crypto-Offload+ SSL Termination and Inspection
+ SSL Re-Encryption + SSL Transformation
BIG-IP Local Traffic Manager
User
Remote Users
Web/Application Servers
Data Protection
Visibility and Control
Key Management
Customer Scenarios
Internet
NG-IPS
NetworkFirewall
NetworkFirewall
Web Application FirewallPassive Monitor, IDS,
Customer Experience Solutions
HSM
Simplified Business Models
GOOD BETTER BEST
DMZ
Figure 1: Common deployment scenarios for SSL
Deployment scenario: Inbound enterprise applicationsOne 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 centerOne 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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
6
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 visibilityOne 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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
7
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
RECOMMENDED PRACTICES
F5 SSL Everywhere
8
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 ProtectionThe 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 stringsThe 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:
RECOMMENDED PRACTICES
F5 SSL Everywhere
9
(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-SHA2563 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 (+)
RECOMMENDED PRACTICES
F5 SSL Everywhere
10
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
RECOMMENDED PRACTICES
F5 SSL Everywhere
11
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
12
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
13
Transformational servicesBIG-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 Server Connection
2K RSA HTTP/1.1
Elliptic Curve 1K RSA
Forward Secrecy (ECDHE, DHE) Multiplexed TCP
Client Certificate Authentication 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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
14
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
15
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
16
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
17
• 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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
18
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
RECOMMENDED PRACTICES
F5 SSL Everywhere
19
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 certificatesThe 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.”
RECOMMENDED PRACTICES
F5 SSL Everywhere
20
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
21
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
22
SSL failover optionsFull 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
RECOMMENDED PRACTICES
F5 SSL Everywhere
23
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
24
• 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 syn-
cookies. 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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
25
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
RECOMMENDED PRACTICES
F5 SSL Everywhere
26
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
RECOMMENDED PRACTICES
F5 SSL Everywhere
27
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
28
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 ManagementG.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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
29
Certificate expiration notificationCertificate 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 GMTCN=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).
RECOMMENDED PRACTICES
F5 SSL Everywhere
30
• 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 roleLarge 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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
31
• 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 protectionSSL 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
RECOMMENDED PRACTICES
F5 SSL Everywhere
32
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
33
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:
RECOMMENDED PRACTICES
F5 SSL Everywhere
34
-----BEGIN RSA PRIVATE KEY-----Proc-Type: 4,ENCRYPTEDDEK-Info: AES-128-CBC,3D566DD5B6DCAD115F9969835F53D942
0FbIpHrdPj2ypaVqViLunmNGAn8bOayuoEPALDYOzwzqUSNXUAwwlPgmoqsWAmwL6Fxhgy7m0w70Whhfm8z6dvT063qWBcBgsT4e5yz8L6sfx/zR2pBcYOjTGJ+YzKGsUMFXfe/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 passphrase-
encrypted 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 verificationThe 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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
35
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 Revocation Mechanism
Consumer website OCSP stapling or do nothing
Large member website OCSP stapling
Large enterprise CRL distribution points
Federal OCSP servers
SMB 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
RECOMMENDED PRACTICES
F5 SSL Everywhere
36
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
37
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
RECOMMENDED PRACTICES
F5 SSL Everywhere
38
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
RECOMMENDED PRACTICES
F5 SSL Everywhere
39
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-in-
the-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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
40
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
41
• 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®.
RECOMMENDED PRACTICES
F5 SSL Everywhere
42
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 ControlSecurity 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
RECOMMENDED PRACTICES
F5 SSL Everywhere
43
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 visibilityThe 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).
RECOMMENDED PRACTICES
F5 SSL Everywhere
44
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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
45
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.
Internet/Public Protected sites
InternalClients AFMLTM
Internal BIG-IP LTM
(ingress)
SSL/TLSExternal
BIG-IP LTM(egress)
Security Device(s)
Inspection Air Gap
LTMEncrypted
SSL/TLS
EncryptedUnencrypted Unencrypted
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
RECOMMENDED PRACTICES
F5 SSL Everywhere
46
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).
RECOMMENDED PRACTICES
F5 SSL Everywhere
47
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 attacksThe 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
RECOMMENDED PRACTICES
F5 SSL Everywhere
48
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.”
RECOMMENDED PRACTICES
F5 SSL Everywhere
49
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 high-
water 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.
RECOMMENDED PRACTICES
F5 SSL Everywhere
50
(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 panelThe 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:
RECOMMENDED PRACTICES
F5 SSL Everywhere
51
Statistic Category Associated Counters
Certificates / Handshakes Valid vs. invalid vs. no certificates
Mid-connection handshakes. Secure vs. insecure
handshakes.
Insecure renegotiations rejected, SNI mismatches.
SSL Protocols 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 AES, AES-GCM, DES, RC2, RC4, no encryption
Digest Methods MD5, SHA, none
SSL Hardware Acceleration Full, partial, none (software)
Session Cache Size, hits, lookups, overflows, invalidations
SSL Records In, out, bad
Failures Premature disconnects, handshake failures,
renegotiations rejected, fatal alerts
Session Tickets Reused, reuse failures
SSL Forward Proxy Connections, cached certificates, destination IP
bypasses, source IP bypasses, hostname bypasses
OCSP Stapling 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
RECOMMENDED PRACTICES
F5 SSL Everywhere
52
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.
ConclusionSSL 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.
RECOMMENDED PRACTICES
Advanced Threat Protection with FireEye and F5
©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 Networks, Inc. 401 Elliott Avenue West, Seattle, WA 98119 888-882-4447 f5.com
Europe/Middle-East/[email protected]
Japan [email protected]
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.