F5 SSL Everywhere Recommended Practices

RECOMMENDED PRACTICES

F5 SSL Everywhere

David Holmes Principal Technical Marketing Manager Marty Scholes Marketing Solutions Architect

RECOMMENDED PRACTICES F5 SSL Everywhere

Contents Introduction 3 About the acronyms SSL vs. TLS

Deployment Scenarios

4

4

Deployment scenario: Inbound enterprise applications

5

Deployment scenario: Inbound retail data center

5

Deployment scenario: Inbound SSL pass-through

6

Deployment scenario: Outbound SSL visibility

6

A recommended security posture

6

Fine-Tuning Data Protection

8

A primer on SSL cipher strings

8

Transformational services

13

Client certificates

19

SSL failover options

22

Cipher agility

25

Key Management

28

Certificate expiration notification

29

Use the certificate manager role

30

Key protection

31

Revocation verification

34

Visibility and Control

42

SSL and the OWASP Top Ten

42

SSL outbound visibility

43

Mitigating brute force attacks

47

Instrumentation: The SSL statistics panel

50

Conclusion 52

2


Introduction The cryptographic protocol historically known as the Secure Sockets Layer (SSL) and now known as Transport Layer Security (TLS) is quickly becoming the de facto protocol for all important, and even casual, electronic communication today. Only a decade ago, SSL was reserved only for financial institutions and the login pages of the security conscious. Today SSL is ubiquitous. Even the world’s most popular video sites use SSL for streaming. Although SSL can be an everywhere, all-the-time security protocol, it is not always easy to deploy correctly, or without challenges, into an architecture. For example, SSL offers protection for data in transit, not at rest. It offers forward secrecy, but usually at the cost of monitoring or diagnostic utilities. SSL also faces numerous attacks, despite being constantly improved and monitored by the Internet Engineering Task Force (IETF). Finally, implementation issues such as the OpenSSL group’s Heartbleed incident remind the world that cryptography is difficult—even for cryptographers. The F5® SSL Everywhere™ reference architecture aggregates the set of common solutions for securing data in transit from users to applications, between enterprise services, and from corporate users to the Internet. The key to the reference architecture is the custombuilt SSL software stack that is part of every F5 BIG-IP® Local Traffic Manager™ (LTM) deployment. This recommended practices document, which is based on the SSL Everywhere reference architecture, can guide architects and administrators through strategic deployments of SSL and serve later as a quick reference for specific concerns. It includes: • Common deployment scenarios. • Advanced key management recommendations. • Tips for fine-tuning data protection. • Suggestions for enhancing visibility and control. • Dozens of technical tips and recommended practices for maximizing security posture (and value). These may include example F5 TMOS® shell (TMSH) commands such as: (tmos)# modify ltm profile http2 http2-ni enforce-tls-requirements disabled

Basic familiarity with SSL, server administration, and BIG-IP platform administration is assumed. The recommended practices apply to the BIG-IP family of products, with version 12.0.0 of the BIG-IP platform providing the baseline for referenced features and configurations unless otherwise noted.

3


About the acronyms SSL vs. TLS Vagueness is anathema to engineers. As a result, many engineers refer to modern web encryption as TLS and consider the acronym SSL obsolete. But the fact is that SSL has become shorthand for “a secure connection” even in casual conversation between security professionals and the same security engineers who dislike seeing SSL in print. So for the purposes of brevity and search engine optimization, this document uses the acronym SSL to refer to the collection of encryption protocols that encompass SSLv2, SSLv3, TLSv1, TLSv1.1, and TLSv1.2, except where it is important to specify a particular version. When SSL is used as an adjective (for example, SSL VPN), it should be understood that the subject encompasses the current, accepted protocols for transport layer security. SSLv3 is rapidly being phased out, with SSLv2 long dead. Even TLSv1.0 is discouraged today, and only TLSv1.1/1.2 should be used whenever possible. Perhaps, in time, the language will catch up to reality and TLS will be used in the same way SSL is commonly used today.

Deployment Scenarios For many organizations today, the main use case for SSL is securing data from customers and employees on the Internet to data center applications through an Application Delivery Controller (ADC). While the data center deployment is among the most mature of encrypted data center technologies, it’s not without innovation (and renovation). The deployment scenarios that follow include advanced SSL strategies such as HTTP Strict Transport Security (HSTS) and Online Certificate Status Protocol (OCSP) stapling. The recommended practices introduce how these technologies can be leveraged in inbound data center deployments for outbound visibility.

4


REFERENCE ARCHITECTURE: SSL Everywhere CONTENT TYPE: Product Map AUDIENCE: Security Architect CUSTOMER SCENARIO: SSL Everywhere (Inbound) DMZ

Web Application Firewall

NG-IPS

Passive Monitor, IDS, Customer Experience Solutions

Remote Users

User

SSL Termination and Inspection + Cipher Agility + SSL Transformation + Intelligent Traffic Management + SSL Re-Encryption Internet

Network Firewall

Network Firewall

Web/Application Servers

BIG-IP Platform

Customer Scenarios Data Protection Visibility and Control Key Management

HSM

SSL Crypto-Offload + SSL Termination and Inspection + SSL Re-Encryption + SSL Transformation

BIG-IP Local Traffic Manager

Simplified Business Models GOOD

BETTER

BEST

BIG-IP Platform

Figure 1: Common deployment scenarios for SSL

Deployment scenario: Inbound enterprise applications One of the primary deployment scenarios for SSL is to protect a suite of enterprise applications, from Microsoft Sharepoint and Exchange to a LAMP-based CGI application. A typical administrator for this deployment scenario is likely a network operations team member. In a larger organization there will be a security team, a security architect, an auditor, and sometimes even a separate certificate management team. Enterprise administrators will use an ADC to perform SSL bridging, which is the act of decrypting incoming connections, performing an action (such as a load-balancing pick or persistence), and then re-encrypting the connection to a server within the enterprise. Flexibility, extensibility, security, and visibility take precedence over availability for many of these administrators.

Deployment scenario: Inbound retail data center One of the most demanding scenarios for an ADC is the retail website. Even more demanding can be deployment for a hosting company dealing with multiple retail sites.

5


A hosting company that sports many very popular websites can have millions of connections flowing through the ADC at any minute, and hundreds to thousands of new SSL connections per second. For these customers, availability and compatibility are the most important characteristics of their deployments. They are also concerned with compliance to standards such as the Payment Card Industry Data Security Standard (PCI DSS). For retail customers, the ADC is often performing SSL termination, meaning that it is decrypting incoming connections and transitioning (proxying) the payloads to servers further into the data center.

Deployment scenario: Inbound SSL pass-through The majority of F5 customers use BIG-IP devices for application delivery services that include SSL. A significant number of customers use the BIG-IP platform for L4 load balancing and traffic steering. These customers include service providers running tens of millions of connections through single tiers of F5 ADC devices. These devices will be aware of SSL connections but won’t be actually terminating or even inspecting those connections. They can still provide a measure of control over the SSL flows. The term for this kind of flow control is called SSL pass-through—the SSL traffic is passing through the ADC instead of being terminated or bridged at the ADC.

Deployment scenario: Outbound SSL visibility One of the most significant new applications of SSL decryption is used in a scenario that has various names, such as SSL “air gap” or SSL interception. The problem it solves is simple in concept: Users inside a corporate headquarters are one of the most high-profile risks when they react to unsolicited email or browse the Internet. A targeted “spear phishing” campaign can snare a user into clicking a link that will pull malware from the Internet through an SSL connection. There are security solutions that scan for malware, but many of them are unable to scale to automatically and transparently decrypt SSL connections. The outbound SSL visibility scenario supports these security solutions. F5 devices sandwich these security solution devices to provide decryption and re-encryption services.

A recommended security posture The definitive resource for evaluating a web site’s SSL security posture (and comparing it to others) is the Qualys SSL Labs report. An administrator can connect to the test site and enter his web address, and the report will provide an elementary alphabetical grade. While some think that a single letter is oversimplifying many complicated ideas, the SSL Labs scanner grade is, at least, an objective, and there is no denying that SSL Labs is the most visible project grading SSL deployments and rating SSL security postures today.

6


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

Figure 2: A simple SSL Labs security posture report

Achieving an A+ grade is a non-trivial task; however, it can be done in an afternoon (even in less than an hour) when starting from the right point. Currently, to achieve an A+ rating with SSL labs, a user must follow these recommendations; otherwise the site would receive the following grade in brackets. • Disable SSLv3 [B] & RC4 [B/C] • Replace any SHA1 Certs [A] and sub-2k Certs [C] • Enable TLS_FALLBACK_SCSV [A] • Enable HTTP Strict Transport [A] • Enable and Prefer Perfect Forward Secrecy Compatible Ciphers [A-] Do not use DHE ciphers (only ECDHE). DHE ciphers will cap the grade at [B] on BIG-IP. • Enable TLS1.2 [C] • Enable Secure Renegotiation [A-] The DEFAULT cipher string included in BIG-IP version 12.0 will yield a B grade but offers full hardware acceleration. To get that coveted A+ grade, an administrator would need to have

7


a fairly restrictive cipher list. For example “!SSLv3:!DHE:ECDHE:RSA+HIGH” will get an A grade on SSL labs but would require every user to have a very recent browser. Note that the rating requirements change over time; see the Qualys SSL Labs Rating Guide for the latest.

Fine-Tuning Data Protection The primary goal of SSL is to secure data in transit. A BIG-IP device that is performing SSL termination or SSL bridging has dozens of settings, many of them very powerful, that can be fine-tuned for a specific security environment.

A primer on SSL cipher strings The configuration knob that controls the negotiation of key-exchange, encryption, and authentication protocols is the cipher string setting of the F5 clientssl and serverssl profiles. Creating a cipher string that projects only strong cryptographic ciphers while maintaining broad compatibility among browsers can be a black art. Consider this actual, recommended cipher string for advanced BIG-IP administrators: ECDHE+AES-GCM:ECDHE+AES:ECDHE+3DES:DHE+AES-GCM:DHE+AES:DHE+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:-MD5:-SSLv3:-RC4

The BIG-IP device cipher string system is based on the one used by the open source project OpenSSL, though it does not follow it exactly. Find the full reference for OpenSSL cipher strings, and a few extra tips, here. An administrator can use the tmm command from the TMOS bash shell to see which ciphers are included in any given cipher string for any BIG-IP version: config # tmm --clientciphers ‘DEFAULT’

The tmm command should only be run on standby devices, because running the command incorrectly can interfere with application delivery. The cipher string is usually enclosed in single quotes otherwise any ‘!’ characters in the cipher string confuse the shell. By convention, UPPERCASE is always used for cipher strings. Also note that this command is one of the few in this document that is not a native TMOS shell command. An administrator must have access to the bash shell to run it, and can get to the bash shell by running this command from the TMOS shell:

8


(tmos)# run util bash

The ciphers represented by the cipher string are shown in the order in which they will be preferred by the BIG-IP device. In the DEFAULT example above, the first three preferred ciphers are: 1 DHE-RSA-AES256-GCM-SHA384 2 DHE-RSA-AES128-GCM-SHA256 3 DHE-RSA-AES256-SHA256

Unlike many server systems, when negotiating the SSL cipher with the client, the BIG-IP system will choose the preferred cipher according to the cipher string designated by the BIG-IP administrator rather than choosing the one preferred by the browser. Browser vendors consider this rude, but BIG-IP administrators prefer the control.

Building a cipher string There are four components of a cipher: key exchange, authentication, encryption, and hash. A cipher may describe any subset or combination of these components. • Common key exchange ciphers: RSA, DHE, ECDHE, ECDHE_ECDSA, ECDH_ ECDSA, DHE and DHE_DSS. • Common authentication ciphers: RSA • Common encryption ciphers: AES, RC4, DES, 3DES • Common message hash ciphers: SHA, SHA256, MD5 The hyphen character “-“ combines the elements into a single specific cipher. For example, the cipher string “DHE-RSA-AES256-SHA” specifies exactly one cipher.

Operators Besides the hyphen, four other character operators are used to build cipher strings. • Colon (:) The colon character “:” is the delimiter between two cipher string phrases. When used as part of a list, it is simply the additive operator. For example the cipher string “RSA:AES” means “all RSA-based ciphers plus all AES-based ciphers” and would include over 100 ciphers! • Plus (+)

9


The plus sign operator “+” has two uses. When used between two cipher names, the + operator doesn’t mean add, it means “the intersection of.” The cipher string “RSA+AES” means specifically just 11 ciphers that have RSA as the key exchange and AES as the encryption cipher. • Leading plus (:+) When used in front of a cipher name (that is, after a colon), the plus sign means “move these ciphers to the end of the list.” For example, RSA:RC4 and RSA:+RC4 will provide the same list of ciphers, but the latter will order RC4-based ciphers at the end of the list as least preferred. • Minus (-) The minus operator “-“ deletes the ciphers from the list of supported ciphers while making sure that some or all of the ciphers can be added again with later options. The “!” operator is used more commonly than the minus. For example, “RSA:SHA:DHE+SHA” means “all RSA-based ciphers except those that use SHA” plus “all DHE-based ciphers that include SHA”. Do not confuse the minus with the hyphen character “-“. • Not (!) The not operator “!” permanently deletes ciphers from the list of supported ciphers. The ciphers deleted can never reappear in the list even if they are explicitly stated. For example, “RSA:!MD5:MD5” is effectively the same as “RSA”. • At (@) The at operator “@” specifies that the following word will designate whether the cipher string is to order the list by cryptographic strength (@STRENGTH) or cryptographic performance (@SPEED). • No symbol If none of the above symbols appears in the string, the string is interpreted as a list of ciphers to be appended to the current preference list. If the list includes any ciphers already present, they will be ignored.

Special keywords The cipher string format includes a series of special keywords that can be used to group ciphers together: • DEFAULT

10


This is the ordered list of preferred ciphers as determined by the F5 security engineering team. It is different from the OpenSSL DEFAULT keyword. F5 optimizes DEFAULT to be a reasonable compromise between high security and high performance. The F5 engineering team agonizes over the list of ciphers that make up DEFAULT in each release. The main drawback to using DEFAULT is that when it changes (as new ciphers are developed or old ones fall out of favor), administrators that use DEFAULT may be surprised when they upgrade versions. In version 12.0 of the BIG-IP system, the following unsafe ciphers are excluded from DEFAULT and are unlikely to come back: EXPORT, SSL3, and NULL. Solution 13156 lists the ciphers included with the DEFAULT keyword for different versions of the BIG-IP system. • NATIVE The NATIVE keyword specifies the set of ciphers that are specially accelerated either in hardware or software in the F5 SSL software stack. The performance and support of NATIVE ciphers are much higher than non-NATIVE ciphers. The NATIVE cipher list includes ciphers that have since been shown to be inappropriately weak for modern use (such as RC4, MD5, and DES), so it should not be used without modification. • COMPAT The COMPAT cipher invokes a special mode for a handful of ciphers where the implementation is borrowed directly from the open source OpenSSL project to support legacy systems that could not be upgraded. Today, COMPAT should only be used very rarely, under specific guidance, when there is no other alternative. • ALL The ALL string includes all ciphers except the eNULL ciphers, which need to be explicitly enabled. The ALL ciphers are reasonably ordered by default. Use of ALL is highly discouraged for production systems, as it will allow many unsafe ciphers. • HIGH, MEDIUM, and LOW These keywords are largely maintained only for the purposes of compatibility. The HIGH string includes ciphers with 128-bit keys or larger, but in reality, HIGH is less secure than DEFAULT. Note that HIGH includes anonymous Diffie-Helman ciphers, which should not be used by production systems.

11


The MEDIUM string includes medium-strength encryption ciphers, and the LOW string includes ciphers that use 64- or 56-bit encryption algorithms but excludes ciphers in the EXPORT string. • EXPORT The EXPORT keyword includes export encryption algorithms, including 40- and 56-bit algorithms. These ciphers were defined to comply with U.S. export rules that have since been lifted. The EXPORT keyword is most useful when preceded by the Not (!) operator.

Cipher string examples Several examples of cipher strings an administrator could use for a clientssl profile: ECDHE+AES-GCM:ECDHE+AES:ECDHE+3DES:DHE+AES-GCM:DHE+AES:DHE+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:-MD5:-SSLv3:-RC4

This cipher string prioritizes elliptic-curve ciphers (EC). EC ciphers are thought to be easier on mobile devices. The Ephemeral Diffie-Helman (DHE) cipher invokes forward secrecy. By specifying DHE+AES, some SSLv3 ciphers get brought back in. The final “-SSLv3:-RC4” removes them. ‘ECDHE:HIGH:+DHE:!ADH’

This string commands: Prefer elliptic curve key exchanges (ECDHE). Allow ciphers with key sizes of 128-bits or larger (HIGH). Put ephemeral Diffie-Helman ciphers (DHE) at the end of the list. Disallow any anonymous Diffie-Helman ciphers (!ADH). ‘HIGH:!ADH:!SSLv3:!TLSv1@SPEED’

This string says: Allow ciphers with key sizes of 128-bits or larger (HIGH). Disallow any anonymous Diffie-Helman ciphers (!ADH). Effectively allow only TLSv1.2 and TLSv1.1 (!SSLv3 and !TLSv1). Order the remaining ciphers by speed.

F5 recommended practices for building cipher strings: • Disable anonymous ciphers such as ADH using the !ADH phrase. • Disable export ciphers using the !EXPORT phrase. • Use the keyword HIGH, but be sure to disable anonymous ciphers. • Disable SSLv3 when possible. This is an unsecure protocol version.

12


Transformational services BIG-IP devices serve as a full proxy for TCP, HTTP, and SSL, which means they create one connection to the client (browser) and a separate connection to the server. The transformational nature of an SSL proxy allows a site to provide SSL features that are decoupled from the capabilities of the application servers. An architect can therefore use the ADC to transform the interface to the web servers into any protocol the ADC supports, regardless of the back-end transport options. For example, an administrator can define that every application has 2K RSA keys on the ADC even if the application servers support only 1K RSA keys. Or the architect can support HTTP/2.0 for every application on the ADC even when none of the back-end servers support it. In other words, transformational services provide the ability to maintain compliance with an Internet-facing SSL policy without the need to enforce that policy on individual servers. This full-proxy capability allows BIG-IP devices to transform any combination of the client and server connections below. Client Connection

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.

13


To counter this vulnerability, forward secrecy was proposed. Forward secrecy extends the key exchange protocol to generate a second, ephemeral key before generating the session key. In previous SSL key exchanges, the RSA keys are used to generate a session key, which in turn is used to encrypt the traffic. With forward secrecy, the RSA keys are used to facilitate generating a Diffie-Helman ephemeral key pair, which is used to generate the session key. This approach ensures that compromising the RSA private key will only provide access to encrypted traffic. Each individual SSL session is protected by the Diffie-Helman key pair generated on a per-session basis. Forward secrecy ensures that compromising a private key will not expose all traffic encrypted with that private key. BIG-IP version 12 prefers forward secrecy ciphers in the DEFAULT cipher. The tmm – clientciphers command shows the specific forward secrecy ciphers: [davidh@murky:Active:Standalone] ~ # tmm --clientciphers DHE:ECDHE ID SUITE BITS PROT 0: 159 DHE-RSA-AES256-GCM-SHA384 256 TLS1.2 2: 57 DHE-RSA-AES256-SHA 256 TLS1 3: 57 DHE-RSA-AES256-SHA 256 TLS1.1 ... 23: 49192 ECDHE-RSA-AES256-SHA384 256 TLS1.2 24: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 25: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.1

Applications that use the DEFAULT cipher need not make any changes to take advantage of forward secrecy. There is one scenario where forward secrecy can create problems: key sharing, such as may be used by monitoring or other security systems. Shared-key monitoring will fail when forward secrecy is enabled, so in such cases, forward secrecy is not appropriate. In cases where the SSL keys are being shared with other security services such as IDS/IPS, the options are either to eschew forward secrecy, risking future exposure of the traffic, or to terminate the SSL with the BIG-IP device. Terminating the SSL enables the use of forward secrecy while also allowing monitoring by other devices.

F5 recommended practices for forward secrecy: • Before enabling forward secrecy, ensure that the SSL private key is not being shared with any monitoring systems or with other security devices. • Understand that diagnostic tools such as ssldump will fail to work when forward secrecy is enabled.

14


Multiplexing TCP and SSL The F5 OneConnect™ feature of the BIG-IP system can increase network throughput by efficiently managing connections created between the BIG-IP system and back-end pool members. OneConnect works with HTTP keep-alives, enabling the BIG-IP system to minimize the number of server-side TCP connections by making existing connections available for reuse by other clients. For example, when a client makes a new connection to a BIG-IP virtual server configured with a OneConnect profile, the BIG-IP system parses the HTTP request, selects a server using the load-balancing method defined in the pool, and creates a connection to that server. When the client’s initial HTTP request is complete, the BIG-IP system temporarily holds the connection open and makes the idle TCP connection to the pool member available for reuse.

F5 recommended practices for multiplexing TCP and SSL: • Do not configure OneConnect for a virtual server doing SSL pass-through. • See the F5 DevCentral™ article “Persisting SSL Connections” for more information.

HTTP Strict Transport Security Many websites operate over HTTPS but offer the ability to downgrade to unencrypted HTTP when necessary. Other sites operate primarily on HTTPS but download some content—such as video or images—over unencrypted HTTP. A site that allows unencrypted traffic creates an attack surface for cookie hijacking or man-in-the-middle attacks. RFC 6797 provides HTTP Strict Transport Security (HSTS), a standard for directing web clients to connect only using secure and trusted connections. HSTS inserts a header into HTTPS traffic that directs the client only to use trusted and encrypted connections to retrieve objects. This restriction includes refusing to display pages with self-signed certificates. Clients will continue to enforce the restriction for the period of time specified in the header. All major browsers now support HSTS, making its use a good way to ensure that all traffic stays encrypted. With the BIG-IP system, the administrator can ensure that all pages for a domain have the HSTS header. Enabling HSTS is one of the easiest and most powerful ways to improve an application’s security posture. BIG-IP devices have three parameters for setting HSTS located within the HTTP profile.

15


Figure 3: Enabling HSTS in the HTTP profile

Select the Mode check box to enable HSTS. Use the Maximum Age field to specify for how many seconds the client should enforce HSTS after last seeing the header. The default value specifies that HSTS should be enforced for 186 days after the header was last seen, which is consistent with SSL Labs’ recommendation that the maximum age be at least 180 days. Select the Include Subdomains check box to indicate that subdomains should also enforce HSTS. Most administrators will want to select this option, forcing all subdomains to use HSTS. If there is an application on a subdomain that cannot use HSTS, such as an application that requires a self-signed certificate, then the administrator should clear this check box. HSTS provides a layer of protection for users against several common attack vectors, including cookie hijacking, man-in-the-middle, and downgrade attacks, that depend on unencrypted traffic. By selecting a single check box, administrators can ensure that all traffic will require encryption after only one encrypted connection. F5 product users running a version of TMOS prior to 12.0 can use a simple F5 iRules® script to turn on HSTS. For versions 11.6.0 and earlier, see Jason Rahm’s DevCentral article called “Implementing HTTP Strict Transport Security.” when HTTP_RESPONSE { HTTP::header insert Strict-Transport-Security “max-age=31536000 ; includeSubDomains” }

The includeSubdomains keyword instructs the browser to use encryption for object requests within the subdomains of the site. For example, if the site is example.com, the includeSubdomains keyword will instruct the browser to use HSTS for chat.example.com as well. An administrator must ensure that all subdomains are compatible with SSL before enabling includeSubdomains.

F5 recommended practices for HSTS: • Enable HSTS for applications.

16


• Use the includeSubdomains keyword, but only after ensuring all subdomains will continue to function. • Enable a 302 redirect on the virtual server at port 80. Solution 14996 describes how to configure redirects from HTTP to HTTPS.

HTTP/2 HTTP/2 is poised to replace HTTP/1.1 by reducing latency in typical web traffic. HTTP/2 reduces latency by compressing the headers, multiplexing client requests, and enabling servers to push data to the client before the client requests it. Since the major browsers now support HTTP/2 at the client level, a web application can provide a more pleasant user experience by implementing HTTP/2. The BIG-IP platform provides the ability to produce an Internet-facing HTTP/2 presence without the need for any changes to the back-end web servers. Since the dominant version of HTTP in use today is 1.1, most administrators would prefer to support HTTP/1.1 while making HTTP/2 available. BIG-IP devices support this scenario. Keeping all of the traffic on a single virtual server simplifies deployment and maintenance. The default behavior of the BIG-IP system is to support all versions, including HTTP/0.9 through HTTP/2, when an HTTP/2 profile is included. The HTTP/2 profiles can be added to a virtual server from the Acceleration section of the virtual server configuration. The BIG-IP platform permits SSL settings on the server side as well as the client side. These settings are independent, enabling the administrator to provide an HTTP/2 presence without making any changes to the web server infrastructure. All internally developed and externally licensed software can be exposed to the Internet as HTTP/2, regardless of the capabilities of the internal servers. In addition, the internal traffic can be encrypted between the BIG-IP device and the internal servers. Encrypting all traffic increases the level of security both in terms of encryption and by eliminating a possible man-in-the-middle attack by a rogue system on the corporate LAN. The level of encryption exposed to external web clients is independent of the level of encryption used by internal servers so the latest algorithms can be used to face the Internet with older algorithms being used internally, where SSL traffic is less exposed. In response to several attacks based on SSL renegotiation, the HTTP/2 specification requires that SSL renegotiation be disabled, but the default clientssl profile allows renegotiation. The implication is that the default HTTP/2 settings and the default clientssl settings are incompatible. The administrator must decide whether to disable renegotiations (in support of HTTP/2 compatibility) or to allow renegotiations. In order to use HTTP/2, the administrator must change the default settings of either the clientssl profile or the HTTP/2 profile. 17


First, the administrator must determine whether or not renegotiations are needed. Actual SSL renegotiations are uncommon. One of the few use cases for renegotiation is for dynamically changing client authentication requirements based on content and then requesting a certificate from the client. Unless an administrator’s site uses this technique, it should be safe to leave renegotiation disabled. For cases where the administrator wants to remain compliant with HTTP/2 requirements and does not need renegotiation, disable renegotiation at the clientssl profile associated with the virtual server.

Figure 4: Disabling renegotiation in a clientssl profile

F5 recommended practices for HTTP/2: • Leave the default setting, which disallows SSL renegotiation with HTTP/2. This restriction can be relaxed with the following TMSH command if needed. (tmos)# modify ltm profile http2 http2-ni enforce-tls-requirements disabled

• Attach an HTTP/2 profile to every externally facing virtual server. There is no downside. • HTTP/2 is not yet supported for BIG-IP server-side connections. If an application requires HTTP/2 from the client all the way to the server, use the BIG-IP device for layer 4 load-balancing to a pool of HTTP/2 servers.

Persistence and SSL Connection persistence is a technique to consistently pair the same client to the same server over time. For example, suppose that a server farm has 300 servers for an application. A user, Marty, comes in and is directed by the ADC to server 287 because it has the lowest load. Server 287 establishes an HTTP session with Marty and loads his profile information from the middle-tier database systems into its memory. As Marty uses the website, his browser opens new connections to the ADC. The ADC recognizes Marty and sends these new connections to, say, server 287, which already has Marty’s profile information loaded. This works because Marty’s connections information 18


has persisted on the ADC. Computer scientists call the property of matching requestors to data “locality of reference.” F5 holds the original patent for ADC persistence via HTTP cookies. There are many ways to accomplish persistence. Some early, crude models include persisting by client source address or layer 4 tuples. An administrator may notice that there is a persistence method that relies on SSL session ID. In actuality, this persistence method is rarely used for the following reasons: • It is not uncommon for a client and server to have multiple open sessions. • Sessions are ephemeral and can be invalidated at any time. • Many implementations of computation session identifiers are not deterministic, meaning that if Marty’s browser switched sessions mid-session (as it were), a persistence method based on SSL session ID could send his new session to the wrong server. The only time SSL session ID should be used as a persistence method is for the SSL pass-through case, where the BIG-IP device is not decrypting SSL and is simply passing it through to servers that will decrypt the SSL later.

F5 recommended practices for SSL persistence: • Use normal cookie-based persistence when SSL traffic is terminated or bridged on the BIG-IP device in full-proxy mode and the underlying protocol is HTTP. • For clientssl profiles where the underlying protocol is not HTTP, use layer 4 persistence. • For SSL pass-through configurations, use SSL session ID persistence.

Client certificates The vast majority of SSL sessions across the Internet use only one-way SSL authentication— the client authenticates the server by examining the server’s certificate data, public key, and associated signatures. If the server wants to identify the user, it typically asks for a username and password after the SSL session is established. But there are some applications that use SSL client certificate authentication as well as SSL server authentication. This is called mutual authentication, but since the server authentication is nearly always done anyway, people simply think of it as “client authentication with client certificates.”

19


How all the clients got their certificates is a management problem all in itself. Typically all the clients are members of a well-funded organization (like a branch of the military) or Wall Street traders, for instance. And often the certificates reside on smart cards or other devices where they are accessed over public key cryptography standard (PKCS) protocol #11. Part 8 of the DevCentral series on SSL profiles provides a detailed breakdown of exactly how client certificate authentication works within the TLS handshake. Historically, the most common intersection of client certificate authentication and the F5 platform occurs in SSL termination and SSL bridging modes: the BIG-IP device is acting as the SSL server to a client on the Internet and authenticating that client’s certificate. The back-end servers, which trust the BIG-IP system, need to get information about the client certificate. There are three ways to forward that client certificate information to the servers: • X509 extraction The oldest trick (and still one of the easiest) is to extract and insert fields from the client certificate’s X509 directory information into the underlying HTTP stream as headers. A typical iRules script might include gathering the issuer of the client certificate and then inserting it into the HTTP request to the server as “F5_CLIENT_ ISSUER=[X509::issuer [SSL::cert 0]]”. See this DevCentral post for a more complete example. • X509 whole certificate extraction A similar method is to extract and insert the entire certificate itself into the HTTP stream as a multi-line PEM-encoded header. Obviously, the server-side code will have to reassemble the certificate. The server can do the reassembly using a code library or by executing the openssl x509 command. The iRules script to do this on the BIG-IP device would look as simple as: when HTTP_REQUEST { if { [SSL::cert count] > 0 } { HTTP::header insert “F5CC” [X509::whole [SSL::cert 0]] } }

• ProxySSL mode There is a way to forward client certificates directly to the back-end server with a special F5 SSL setting called proxySSL mode. With proxySSL, the BIG-IP device must use the same certificate and key as the back-end server. Clients can then connect all the way through to the server and authenticate with their certificates.

20


The BIG-IP device can provide passive monitoring of the session. ProxySSL should only be used when there is a requirement for client certificate authentication directly to the back-end servers. See SSL and the OWASP Top Ten later in this document for more information about proxySSL.

F5 recommended practices for client certificates: • The SSL profile has a three-way setting for client certificate authentication: none, request, and require. When require is used and the client authentication fails for some reason (such as an expired certificate or OCSP failure), the user gets an ugly browser message. Some administrators use the request setting instead, which allows them to receive the certificate but passes the connection through even if authentication fails. When using the request setting, also use an iRules script that checks the certificate verification result and presents a more aesthetic error message or an HTTP 302 redirect. • Configure at least one revocation method—whichever one is best supported by the certificate authority—for client certificates. Certification revocation lists (CRLs) can be supported directly in the SSL profile. The other methods (OCSP and CRL distribution point or CRLDP) must be done via iRules. See the revocation section of this document for more information. • The TLS protocol includes a way to force a new handshake but without breaking the TCP connection. This is called a renegotiation and can be used to transition a client from one authenticated state (none) to another (client certificate authentication). However, the IETF frequently threatens to remove renegotiation, so consider it abandoned, and use it accordingly. • SSL forward proxy is a special mode that intercepts outbound SSL requests from a client on the inside of the BIG-IP platform boundary (inside the data center). This mode is used with the SSL outbound visibility deployment scenario. The BIG-IP device may try to intercept connections that are using client certificate authentication, but it will very likely not know what to do with the resulting connection. Whitelist any allowed, known hosts into a bypass list so that the BIG-IP device will not interfere. • There is a setting called “retain certificate” in clientssl profiles. This setting will improve the user experience by caching the client certificate across multiple connections (thereby avoiding extra popups in the browser). Enable this setting unless using a rare high-bandwidth, low-memory configuration where the extra few kilobytes associated with each connection could impact overall system performance.

21


SSL failover options Full SSL handshakes are computationally expensive. This is one reason enterprises continue to rely on ADCs stuffed with cryptographic acceleration hardware for SSL decryption. Sites that have significant amounts of SSL traffic need to be aware of this particular problem: What happens if the primary ADC stops receiving traffic and the secondary has to pick up all those active connections? Administrators may say they’d like the secondary device to resume each session exactly where the primary left off. In practicality, a seamless “SSL failover” like this is a very difficult problem to solve. In fact, the industry hasn’t yet standardized a solution. F5 customers have three options to choose from for SSL failover. Two have very similar names: SSL session mirroring and SSL connection mirroring. The third, SSL session tickets, is relatively new.

SSL session mirroring Recall that an SSL session is the set of state information that describes an individual SSL connection between a client and a server. This state information can be mirrored between BIG-IP devices in a traffic group. When session information is mirrored, a client can connect to any device in the group and resume the SSL session, avoiding the expensive and higher-latency full SSL handshake.

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

SSL session mirroring is relatively straightforward and controlled by two knobs. The first control is to toggle a system variable named statemirror.secure. Through the command line interface, an administrator can issue the following command: (tmos)# modify sys db statemirror.secure value enable

22


This must be done prior to creating SSL profiles that include the new SSL session mirroring attribute, and on all units in the cluster. It will cause the mirroring channel to drop and reestablish. The second control is to enable the SSL mirroring attribute in the clientssl profile associated with the application’s virtual server.

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

The attribute can also be set with this command: (tmos)# modify ltm profile client-ssl test1 session-mirroring enabled

Both the check box and the TMSH command will warn if the statemirror.secure variable discussed above has not been set.

SSL connection mirroring The second and more sophisticated approach to mirroring is SSL connection mirroring—a method administrators often think they want. Connection mirroring takes session mirroring one step further: Connections to a virtual server that has connection mirroring enabled can, in theory, be continued without interruption or restarted by any device in the device group. In reality, ADC administrators have found that connection mirroring (SSL or otherwise) is largely unnecessary due to the stateless and temporal nature of HTTP. The performance cost and additional latency added by full connection mirroring is rarely worth the benefit of fully mirrored connections for HTTP. This means that the number of valid applications for connection mirroring is a very small number indeed, and most F5 customers use it only for specific applications, such as long-term VPN tunnels. SSL connection mirroring has the following restrictions: • SSL connection mirroring is not compatible with the HTTP profile. • Server side SSL connection mirroring is not supported. • DTLS connection mirroring is not supported.

23


• SSL connection mirroring is incompatible COMPAT ciphers. • Multiple failover is not supported. • Failback is not supported. • iRules should not be applied to a virtual server using SSL connection mirroring. • The database variable statemirror.secure must be enabled.

F5 recommended practices for SSL connection mirroring • Only enable SSL connection mirroring for long-lived, non-HTTP sessions. • Under high connection rates, viewing tmctl ha_stat may show “overflows” incrementing. To mitigate this problem, change the database variable statemirror.queuelen to 256M. • If connections are occasionally lost on reset, enable the database variable statemirror.verify, which will take an extra step to verify the successful mirroring of each packet during normal transactions.

SSL session tickets The final option for mirroring is the use of a feature that’s relatively new to the world of SSL: called session tickets, it is defined by RFC 5077. SSL session tickets work like TCP syncookies. The server (the BIG-IP device in the cases of SSL bridging or SSL termination) can take the state information associated with the client connection, encrypt it, give it to the client (as a ticket), and then forget it. When returning with a new connection, the client can present the encrypted session ticket to the BIG-IP device, which will decrypt it and—voila!—the BIG-IP device has the needed session information and can resume that session without remembering everything. SSL session tickets make the session stateless for the ADC. This has three benefits: • The session can be resumed by a different BIG-IP device. • Sessions take less memory per connection. • The BIG-IP devices become more resilient against session-based denial-of-service (DoS) attacks. Not all browsers and clients support TLS session tickets yet. Currently, a virtual server, if it wants broad reach, must implement both session caching and SSL session tickets. For administrators, having to manage both negates some of the benefit of SSL session tickets.

24


The good news is that browsers and other TLS clients are upgrading quickly and becoming compatible with session tickets.

F5 recommended practices for all SSL mirroring: • Use both SSL session mirroring and SSL session tickets for inbound data center and enterprise applications. • A smaller number of organizations may want to use SSL connection mirroring, but only for applications with exclusively low-bandwidth, long-lived, non-HTTP connections. • Applications that are under extreme memory strain due to circumstances such as SSL connection floods should use session tickets exclusively.

Cipher agility Handshake ciphers: RSA vs. DSA vs. ECC Since the beginning of the SSL protocol, RSA has been the main choice for key exchange. Over time, as brute force attacks became more feasible, RSA key lengths had to become longer. Today the RSA keys are so large that the key exchange is a very computationally expensive operation. Elliptic curve cryptography (ECC), a newer variant of asymmetric cryptography, promises to provide equivalent security with much shorter keys and a correspondingly lower demand for computing resources for key exchange.

Figure 7: The relative key lengths of RSA (factoring modulus) and ECC Source: www.keylength.com

25


The digital signature algorithm (DSA) standard was proposed by the National Institute of Standards in 1991 and has become a U.S. government standard. A site that interacts with federal agencies may have a need for DSA. DSA key length is the same as for RSA. RSA is ubiquitous, DSA is used by sites interacting with federal agencies, and ECC is poised to become the standard in the future. Which type of certificate should a site support? The BIG-IP platform can support all three simultaneously on a single virtual server. Every BIG-IP virtual server must have at least an RSA certificate, but can also have a DSA certificate and an ECC certificate (called ECSDA).

F5 recommended practices for handshake cipher selection: • Configure new virtual servers for both RSA and ECC handshakes. Administrators will likely know if they already have a DSA requirement. • To support multiple certificates: 1. First, upload the certificates to the BIG-IP device. In the client SSL profile, select the new files from the Certificate, Key, and Chain drop-down lists as appropriate.

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

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

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

26


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

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

4. Use the following cipher string names to enable the following groups of ciphers: ECDHE, ECDHE_ECDSA, ECDH_ECDSA, DHE and DHE_DSS

5. Save the configuration by clicking Update. At this point the BIG-IP device will provide both RSA and ECDSA certificates to any connecting client.

Disabling SSLv3 SSLv3 is no longer secure, as demonstrated by the POODLE attack in 2014. Google has removed fallback support in Chrome, and RFC 7568 deprecates its use. SSLv3 should no longer be used by client software. Applications that comply with the PCI DSS specification must discontinue use of SSLv3 and TLSv1 when PCI 3.0 takes effect in mid-2016. New PCI DSS deployments must already be disabling SSLv3 and TLSv1. In version 12.0 of the BIG-IP system, F5 has removed the SSLv3 protocol from the DEFAULT cipher string. That is, any virtual server using a clientssl profile with the cipher string DEFAULT will not accept client connections with SSLv3. Some administrators use a custom cipher string for each clientssl profile, preserving the cipher list from version to version. For example, an administrator running version 11.6 might have defined a cipher string like this: ‘TLSv1_2+AES256:SHA256:TLSv1_1:TLSv1:-RC4:SSLv3+RC4:!DES:!EXPORT’

Obviously, the way to remove SSLv3 from this cipher string would be to delete the ‘:SSLv3+RC4’ phrase. Before removing SSLv3, the administrator may want to know if the site is processing a significant amount of SSLv3 traffic. An administrator can determine the percentage of version 3 SSL connections by querying the clientssl profile statistics on the device. The statistics aren’t attached to the application’s virtual server; they are collated at the associated clientssl profile.

27


Suppose that an administrator has a created a clientssl profile named ssl-exchange-2. Query the protocol counters via the following TMSH command: (tmos)# show ltm profile client-ssl ssl-exchange-2

F5 recommended practices for SSLv3 • Prepare to disable SSLv3 and TLSv1. • Use this nmap script to locate any servers on the network that are still negotiating SSLv3. More information on tracking SSLv3 use on F5 devices can be found on DevCentral.

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

Key Management G.K Chesterson once opined, “An adventure is only an inconvenience rightly considered. An inconvenience is only an adventure wrongly considered.” So it is with the oft-maligned art of certificate management. Some may consider it an inconvenience, but…. Who are we kidding? There is no way to make key management sexy. With some patience, however, a veteran system administrator can take some of the adventure out of a task that is fraught with operational and security pitfalls.

28


Certificate expiration notification Certificate expiration notification may seem like an arcane tidbit not worthy of the first position in a certificate management discussion. Over a decade, however, the solution to certificate expiration has been requested from F5 far more often than any other vexing little problem. This issue comes out of this scenario: BIG-IP LTM is delivering hundreds of websites and applications for an enterprise. Some subset of those, still in the hundreds, is SSL-enabled. Each of these has its own certificate, and each certificate has its own expiration date. On any given week, one or more certificates may expire, which will cause the associated website or application to become unavailable. So how does an administrator stay on top of this whack-a-mole game of expiring certificates? There are a couple of recommended ways to monitor expiring certificates on the BIG-IP platform. However, most administrators of medium to large organizations prefer an external certificate management system because the organization has keys and certificates in many locations, not only on the BIG-IP system. In particular, F5 customers have had success with two external solutions: Venafi and Symantec. The following tmsh sys crypto check-cert command was designed specifically to check for expiring certificates. (tmos)# run sys crypto check-cert CN=www.sconats.com,OU=Domain Validated,OU=Thawte SSL123 certificate, in file / Common/sconats_rsa.crt expired on Mar 12 23:59:59 2015 GMT CN=192.168.2.55,OU=Marketing,O=F5 Networks,L=Loveland,ST=Colorado,C=US in file / Common/3bd_rsa_1k.crt expired on Apr 30 23:57:36 2015 GMT

The check-cert command will scan through all of the known certificate objects on the system. By default, check-cert will log expired or expiring certificate subject names to the /var/log/ltm file and print them to standard output. Users with the administrator, system manager, or certificate administrator role can run the check-cert command.

F5 recommended practices for certificate expiration notice: • To manage certificates across an enterprise, explore external certificate management systems from Venafi and Symantec. • Audit not just for expiring certificates, but also certificates with weak signatures (MD5 or SHA1) and weak keys (1024-bit).

29


• Use the check-cert command to monitor for expiration. For a full description of check-cert, run the ‘help’ command: (tmos)# help sys crypto check-cert

• The check-cert command is automatically run once a week on the BIG-IP system. When check-cert finds expiring or expired certificates, it will write the messages to /var/log/ltm. The administrator can then create a custom SNMP trap to have the BIG-IP system email any results. Solution 3667 has instructions on creating custom SNMP traps. • Read more information about certificate expiration monitoring in Solution 14318: Monitoring SSL Certificate Expiration on the BIG-IP System.

The certificate manager role Large enterprise organizations with 10,000 or more employees usually have dedicated security teams, and often they will have a person or persons whose primary job is certificate management. Typically these individuals are not on the network operations team, are not necessarily privy to the details of network architecture, and are not empowered to change the configuration on network-critical devices such as load balancers or ADCs. It is for these individuals that the certificate manager role was developed. These users can be assigned to the certificate manager role when they authenticate to the BIG-IP system. The role has management access only to objects related to certificates and key management systems.

Figure 10: Assigning the certificate manager role

A user with certificate manager role can: • Generate and import SSL keys and certificates.

30


• Delete SSL keys and certificates. • Manage on-board hardware security module (HSM) subsystems. • Configure expiration notifications for certificates. • Manage device certificates. • Manage the F5 Secure Vault key protection feature. The certificate manager cannot make network changes or modify any aspect of applications managed by the BIG-IP platform.

Key protection SSL keys are among an IT organization’s most prized assets. An attacker who gained possession of a target’s SSL key could impersonate the target’s applications and create the ultimate phishing portal. Because of this, organizations treat their SSL private keys very, very seriously. Many security architectures are designed to keep SSL private keys deep inside the data center, away from the perimeter, to minimize possible threat exposure. BIG-IP devices handle a large portion of data center SSL traffic and often retain dozens of high-value SSL keys. Certificate managers and administrators need ways to deploy SSL keys onto the BIG-IP devices while minimizing their exposure. BIG-IP devices use three methods to minimize exposure of plaintext SSL keys. Two of these involve the FIPS 140-2 standard.

FIPS 140-2 standard FIPS 140-2 is a United States federal standard defining requirements for advanced key protection in software and hardware systems. FIPS 140-2 consists of four security levels: Level

Security

Description

1

Basic

At least one of the approved algorithm; rare

2

Tamper-evident

Typically a software implementation and a sticker

3

Tamper-resistant

Physical key protection and user authentication

4

Tamper-resistant II

Very sensitive physical protection

Some organizations with an interest in FIPS 140-2 will find that the second level meets their requirements. Other organizations with more sensitive data may require the physical key 31


protection provided by level 3 devices, which are called hardware security modules (HSMs). Often level 3 devices are operated in level 2 mode to absolve the HSM user (often called the security officer) from having to log in to the device after every reboot.

Integrated FIPS 140-2 HSM The HSM is a clever piece of technology. Integrated HSM devices are hardware boards designed for insertion into an appliance. SSL keys are generated within, or imported to, the HSM. Ever after, the keys cannot be exported from the HSM. The controlling software (for instance, the BIG-IP system) uses the HSM as an SSL accelerator, offloading to it decryption requests. Each HSM component has a rigorous design, testing, and certification schedule. As a result, the performance of all HSM units is typically not equal to that of non-HSM SSL accelerators. Specific F5 hardware platforms have the HSM integrated directly onboard the system; find more information in the BIG-IP Platform FIPS Administration Guide. Organizations interested in the integrated HSM option must procure one of these specific platforms; the HSM option cannot be added to an existing non-HSM appliance. Platform

SSL TPS

10200v

9000

7200v

9000

5250v

5000

Platforms based on the F5 VIPRION® ADC do not have an HSM option. The F5 Virtual Clustered Multiprocessing™ technology (vCMP) is not compatible with integrated FIPS HSMs.

Network HSM key protection The FIPS 140-2 level 3 HSMs have evolved to become standalone devices called network HSM or netHSM devices. These devices reside on a network and service requests from other appliances on or across the network. Many organizations are moving to architectures that consolidate key management into a single cluster of network HSM devices. F5 supports integration with, and provides integration guides for, two brands of network HSM devices: Thales and Safenet.

32


F5 recommended practices for FIPS 140-2: • In high-security environments, use FIPS 140-2 options that include either an onboard HSM or a network-based HSM solution such as those from Thales and SafeNet. • Plan for HSM failure contingencies. With integrated HSM devices, the situation can be recovered with the security officer password. Take care to keep and secure this password. • Create a contingency plan for the failure of both HSMs in a two-device cluster. Typically this plan will call for additional HSM units to function as backups. • Generate SSL private keys within the HSM for maximum security. However, some administrators choose to generate the keys on a separate device. That key generation device should have a hardware random number generator and should be in a safe location in the network. • The FIPS 140-2 specification requires the use of specific ciphers. Use following cipher string to ensure that these ciphers get preference: NATIVE:ECDHE+AES:ECDHE+3DES:ECDHE+RSA:!SSLv3:!TLSv1:!EXPORT:!DH:!ADH:!LOW:!MD5:!RC4: RSA+AES:RSA+3DES:@STRENGTH

• Monitor the number of transactions per second (TPS) of a BIG-IP device using SNMP. There is no direct SNMP OID to monitor FIPS 140-2 TPS, but we can calculate the FIPS TPS using several OID. In addition, if all clientssl profile on the BIG-IP system are using keys of the security type FIPS, then the following OID can be used, since it represents the TPS for the entire system: F5-BIGIP-SYSTEM-MIB::sy sClientsslStatTotNativeConns • Query the TPS for any individual clientssl profile via an OID named for the profile itself: F5-BIGIP-LOCAL-MIB::ltmClientSslStatTotNativeConns.”/Common/yourprofile1”

Software key protection All non-FIPS F5 appliances can protect passphrase-encrypted keys by storing only the encrypted key on disk. The key that protects the encrypted passphrases is stored in a chip within the BIG-IP device. On the disk, a passphrase-encrypted key will have a header that includes the encryption method:

33


-----BEGIN RSA PRIVATE KEY----Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,3D566DD5B6DCAD115F9969835F53D942 0FbIpHrdPj2ypaVqViLunmNGAn8bOayuoEPALDYOzwzqUSNXUAwwlPgmoqsWAmwL 6Fxhgy7m0w70Whhfm8z6dvT063qWBcBgsT4e5yz8L6sfx/zR2pBcYOjTGJ+YzKGs UMFXfe/GG9RmDSPNHCsTuSbhJlOC7HrPTHvL/YVTvOa8K7Kqp5aRLE3N4nk5Tobg …

The passphrases used to decrypt the individual keys are themselves encrypted by an F5 feature called Secure Vault. The Secure Vault stores its own key in a hardware chip in the physical appliance. Secure Vault should not be thought of as “software FIPS.” It is designed merely to ensure that the SSL keys are not stored in plaintext in the configuration. This is especially important considering that many administrators will periodically store device configuration archives on backup systems in lower-security zones (such as in the cloud).

F5 recommended practices for software key protection: • If FIPS 140-2 is not being used, certificate managers should use passphraseencrypted SSL keys protected by the Secure Vault feature. Passphrase-encrypted SSL keys can be imported to the BIG-IP system directly when included in PKCS 12 file archives. More information can be found by viewing the help for the sys crypto pkcs12 command: (tmos)# help sys crypto pkcs12

• Set a specific passphrase to unlock the master key when using the Secure Vault feature. A specific passphrase enables the manager to later recover all the keys from a backup file, even if the original hardware key is unavailable. More information about setting a specific passphrase for Secure Vault can found by viewing the help for the sys crypto master-key command. (tmos)# help sys crypto master-key

Revocation verification The Achilles heel of the public key infrastructure (PKI) has always been defining the process for handling compromised private keys. The trust system of PKI resides in the chains of signed public keys. However, when one of the associated private keys is compromised, there is no easy way to inform the participants of the PKI system. Neither is there an easy way to revoke a certificate and then distribute the revocation information to all who need it.

34


The PKI community has, over time, developed five mechanisms for distributing revocation information: 1. Do nothing. 2. CRL files. 3. CRL distribution points. 4. OCSP servers. 5. OCSP stapling. Use Case

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 35


considered untrusted, but many organizations do maintain different levels of network trust. • When the BIG-IP device is acting as an SSL server but is also authenticating clients via SSL certificate authentication. • When the BIG-IP device is acting as an HTTPS server and wants to provide its revocation status to connecting clients via OCSP stapling. F5 recommends practices for each revocation method use case shown in Figure 13.

Method 1: Certificate revocation lists The oldest mechanism for the distribution of compromised certificate serial numbers is simply a serial file called a certificate revocation list (CRL, sometimes pronounced “krill”). The file is signed by the associated CA and made available on an FTP or web server. Interested parties can download the file and make it available offline to their web server or ADC. Using straight-up CRL files is the most architecturally straightforward revocation distribution method, but it is also most error prone. Common errors include: • Difficulty retrieving the CRL file (for example, due to network errors). • Growth in CRL file size, consuming resources. • Corrupt CRL files, which happens more often than you might think. • Bad or unverifiable CA signatures on CRL files, which are also disturbingly frequent. In addition, BIG-IP devices have limitations on the maximum size of CRL files. The following table shows the maximum size supported by each version of the BIG-IP system. BIG-IP System Version

Max CRL File Size

12.0

64 MB

11.4.0 – 11.6.0

64 MB

11.0.0 – 11.3.0

32 MB

10.0.0 – 10.2.4

4 MB

For all of these reasons, straight-up CRL files are not a popular distribution mechanism. But there can be times when CRL files make sense.

36


F5 recommended practices for CRL file use: • Use only for private certificate authorities such as an internal IT CA or test CA. • Use only for small sets (less than 100,000) of revoked certificates. • Automate the process of retrieving the CRL file from the certificate authority. • Ensure that the CRL file is properly verified, not 0 length, includes a proper signature, and hasn’t expired. • Convert the file, if necessary, to the required PEM format. • Finally, copy the validated and converted CRL file to the BIG-IP device and instruct the device how to use it. Historically, administrators that rely on CRL files have found it better to develop an automated process on an external device (not the BIG-IP device itself) for CRL file updates. The reason for the external device is that many BIG-IP devices are never assigned a DNS server (so they can never be susceptible to frequent DNS failures). It is not uncommon for a CA to change the IP addresses of their CRL servers, which becomes problematic for the BIG-IP device because it cannot resolve the CRL server name. Certificate administrators who want the BIG-IP device to download and verify the CRL file can use a single command: (tmos)# modify sys file ssl-crl gdcrl source-path http://godaddy.com/repository/ gd.crl

Use the F5 iCall® technology subsystem to schedule the update periodically. (Special thanks are due to Matthieu Dierick for the iCall script.) create sys icall script CRL sys icall script CRL { app-service none definition { tmsh::modify sys file ssl-crl gdcrl source-path \ https://godaddy.com/repository/gd.crl puts “loading CRL” } description none events none } create sys icall handler periodic START first-occurrence 2013-12-06:16:15:00 interval 30 script CRL

37


While the iCall feature is an excellent solution when run on a BIG-IP device, many administrators use a dedicated device (such as a standard Linux server) with a bash script to update many CRLs at once. The DevCentral Codeshare includes an example of such a script.

Method 2: OCSP The PKI community developed a protocol that would provide the same information given by a CRL file but in a simple request-response fashion. The OCSP is designed so that a client can request the status of any particular certificate via its serial number and get a response from an agent of the CA. Typically these agents are separate servers (called OCSP servers or OCSP responders). A modern CA will publish the URL to its associated OCSP server within its own CA certificate. For example, Digicert lists its OCSP server as ocsp.digicert.com.

Figure 11: An example of OCSP information for a CA

38


While OCSP was originally seen as a giant step forward from dealing with clunky CRL files, administrators have since realized that OCSP is imperfect for different reasons: • Querying a separate OCSP server for each connection increases latency and leads to a degraded browsing experience. • OCSP servers are not typically provisioned for high availability situations. This is noticeable in that the servers are not reachable 100 percent of the time. Therefore browsers have learned to “fail open” with OCSP—meaning that if they cannot successfully connect to an OCSP server, they will proceed with the connection anyway. • Attackers have found interesting, trivial ways to defeat OCSP. A simple DoS attack against the OCSP server will work. So will sending the number 3 during a man-inthe-middle attack. For these reasons (and particularly the first), modern browsers are starting to ignore OCSP servers and aggregating the various CA CRL databases. With all that said, there are still valid use cases for OCSP. For example, military networks have trusted subnets and requirements to use OCSP servers. In these cases, where attackers theoretically cannot perform a simple DoS of the OCSP nor man-in-the-middle its traffic. For these cases, F5 has the following recommendations for configuring OCSP.

F5 recommended practices for OCSP servers: • Instead of using a single OCSP server, use an OCSP responder pool to maximize availability. • Use an OCSP monitor to monitor the health of your OCSP servers. • Consider OCSP with a CRL fallback for those times when OCSP servers are down. (Note that this achieves maximum operational complexity.)

Method 3A: OCSP stapling for clients A much faster and more interesting mechanism derived from OCSP is called stapling. When a PKI client sends an OCSP request about a particular certificate, what the client is looking for is a response that says, “The certificate is good” or “The certificate is revoked.” This response must be signed by the OCSP server. Because the OCSP server asymmetrically signs the message, it doesn’t really matter which device delivers the signed message! Therefore the message can simply be blended into the SSL handshake by the ADC.

39


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

RFC 4366 defines a TLS extension whereby the TLS server itself can fetch that signed message and then present it along with its certificate to the client. In this fashion, the client receives the certificate and the status message saying that the certificate is valid without having to connect to a separate server. The OCSP status message includes a recent time stamp so the client has some assurance that the status is fresh. The status response from the OCSP server is cached by the server and then “stapled” into each connection from the client. For the HTTPS client, the HTTPS server, and the OCSP responder, OCSP stapling is the best of all worlds. OCSP stapling is different from the other verification methods because the act of stapling assists the party trying to verify the certificate used by the BIG-IP device. Consider it a courtesy to clients connecting to the application or service.

F5 recommended practices for OCSP stapling for clients: • Enable OCSP stapling on the BIG-IP device by defining the appropriate objects in the SSL profile configuration. • Use the SSL Labs tool to test that OCSP stapling is working. • Build a script that uses the openssl s_client –status command to check the status, then add the script to an automated process to ensure it works over time. 40


• OCSP stapling implementations may vary depending on the registrar, and organizations often use more than one registrar. Validate your OCSP stapling configuration for each registrar you use.

Method 3B: OCSP stapling for servers An administrator can be forgiven for assuming that the BIG-IP device will simply check for OCSP stapling when using server-side SSL profiles. It does not. There’s actually a reason for that: Traditionally, IT administrators use only IP addresses for server pool members to avoid outages on DNS errors. This means that, strictly speaking, the BIG-IP device cannot perform real server certificate verification because it cannot match the IP address to the certificate’s DNS name. Typically those administrators will trade the security of a verified serverssl connection in favor of high availability by implicitly trusting that portion of the network. While that might not be the most secure strategy, it is a common one. Even where strict certificate verification is unavailable, it is still possible to check for OCSP revocation via stapling. Using what is called an external monitor, an administrator can check the revocation status of SSL server pool members and then mark them down if they get revoked. For organizations that use only IP addresses at their ADC, this may be the preferred approach.

F5 recommended practices for OCSP stapling for servers: • Use a BIG-IP device “external monitor” to examine OCSP responses stapled into serverssl connections. External monitors are defined in the Local Traffic section of the configuration. • This DevCentral Codeshare script is an example of an external monitor that can be used to mark a node down when its certificate status is revoked. • Note that it is better to look for the specific revoked status, and, if absent, mark the node as up. This is because there are many reasons a node may be unable to respond, commonly including being down for maintenance. The TCP monitor can mark that node as down.

Method 4: CRL distribution points The fourth and final method of checking for certificate revocation is CRLDP, a way of using existing corporate directories as revocation checkpoints. The technology is fairly mature, especially when used in an Active Directory environment. CRLDP is typically used for client certificate authentication in enterprise environments with BIG-IP® Access Policy Manager®.

41


CRLDP can also be sometimes be found in the inbound retail deployment scenario. For example, the certificate authorities GoDaddy and Entrust issue certificates with CRLDP information embedded in their X509 data.

F5 recommended practices for CRLDP: • Verify that your BIG-IP device is configured to use DNS and not simply IP addresses. • A BIG-IP device using CRLDP must, of course, have a route to the CRLDP servers. If the CRLDP servers are on the Internet, the BIG-IP device must have an outbound Internet route. • Check the size of the CRLs to confirm that they are not too large for the BIG-IP system. (See the table on p. 36.)

Visibility and Control Security management depends partly on visibility into traffic—or the ability to provide that visibility to security devices such as web application firewalls (WAFs)— so that it may be screened for known threats. Of course, SSL by definition obscures data. So how does an administrator gain the visibility to make the best use of his or her security investments? Several approaches maintain security while effectively revealing malicious traffic.

SSL and the OWASP Top Ten The Open Web Application Security Project (OWASP) categorizes and rates classes of application vulnerabilities every year into its OWASP Top 10 list. One of the highest priority classes of vulnerabilities is “insufficient transport security,” by which the OWASP group means not enough SSL. One use case for providing transport security to an application is via SSL termination and then sending the decrypted traffic through a WAF. a device specifically engineered to foil application attacks such as those found in the OWASP Top Ten. One effect of SSL bridging mode, where the ADC decrypts incoming traffic and then re-encrypts the traffic before it leaves the ADC, is that the ADC becomes the singular place where an application firewall can be deployed. While SSL termination and bridging are the primary technologies used to provide visibility into SSL for application security solutions like a WAF, there is a third way. The BIG-IP device can be configured to eavesdrop on an encrypted session between an incoming connection and a back-end server. This functionality is referred to as proxySSL. One of the only cases where proxySSL is preferred is when a back-end server requires client certificate 42


authentication, since client certificate authentication to the back-end server is incompatible with SSL termination and bridging at the BIG-IP device. With proxySSL, the BIG-IP device shares the same key and certificate as the back-end server, and the browser completes the handshake (including client certificate authentication) with the back-end server. The BIG-IP device can then decrypt the session key (because it shares the same key and certificate as the server). The ADC uses the session key to decrypt the rest of the session and forwards the decrypted payloads to a security device like a WAF. The security device can then inspect and report on the content. The use of proxySSL should be restricted to this specific case. Because proxySSL requires a shared-key environment, it is ultimately incompatible with the likely security roadmap of the TLS protocol: Forward secrecy was designed to foil systems exactly like this and is already preferred by over 60 percent of Internet web sites.

F5 recommended practices for application security visibility: • Use SSL termination or SSL bridging to provide inbound visibility to an application security device like a WAF. • If proxySSL is required to maintain client certificate authentication to the back-end web server, configure the server to use only RSA-based ciphers. Avoid forward secrecy because it breaks shared-key systems like proxySSL. • When proxySSL is used with a WAF, the WAF can find malicious traffic and then signal the ADC to block those connections. The only way to block at this point is to send a reset (RST) packet to the client to kill its connection. • Ensure that local logging is not used for production systems. High-speed logging to remote logging servers or SIEMs is preferred.

SSL outbound visibility The outbound SSL deployment scenario for the ADC is a relatively new, but rapidly growing, phenomenon. This deployment scenario has been driven by enterprises with a need to monitor and sanitize their outbound web traffic in attempts to mitigate advanced persistent threats (APTs). A typical APT will start with a spear phishing campaign to introduce malware tailored specifically to invade a single organization. Some of the most damaging penetrations of the last five years have been as a result of APT activity, including the infamous 2011 breach of the world’s premiere security brand, RSA. (Search for Anatomy of an Attack on the RSA blog).

43


These spear phishing campaigns begin with a series of emails injecting infected PDF, Word, or Excel files or simply enticing links that result in a malware download. The initial malware drop may be very quiet, performing only a few simple tasks such as keystroke logging or email address book collection. The attackers can then build on their received intelligence to patiently infiltrate further into the target over months or even years.

Figure 13: The APT life-cycle Source: Creative commons license, Dell SecureWorks

Detecting the subtle activity of spear phishing and malware activity is among the top priorities of security administrators today. High-profile technologies such as sandboxing and next-generation firewalls (NGFW), which have been developed to assist administrators in detecting these threats, are being rapidly adopted. Administrators deploy the security devices in a chain so they can complement each other (known as defense-in-depth). The next problem to solve is the fact that these new technologies are often blind to encrypted traffic. Malware and spear phishing authors know this and are very quickly moving to encrypt all communication between their malware and the outside world. Security analysts estimate that by 2017, 100 percent of new malware will use SSL to hide its tracks.

44


A deployment scenario sometimes called an SSL air gap or SSL intercept is emerging to address the APT problem and assist the chain of outbound visibility devices (such as sandboxes). The SSL air gap solution typically consists of an ADC on either side of the visibility chain. The ADC closest to the users decrypts their outbound traffic and sends the decrypted plaintext through the chain. The chain, which can now see the content, applies policy and controls to the plaintext, detecting and sanitizing spear phishing and malware. At the other end of the chain, another ADC re-encrypts the traffic as it leaves the data center. In some cases, instead of going through a second ADC, the traffic can be looped back to be re-encrypted by the first ADC.

Inspection Air Gap

Internal Clients

LTM

AFM

Encrypted

SSL/TLS

Unencrypted

Unencrypted

Internal BIG-IP LTM (ingress)

Security Device(s)

LTM

External BIG-IP LTM (egress)

Encrypted

SSL/TLS

Internet/Public Protected sites

Figure 14: The SSL air gap use case

The F5 solution for SSL outbound visibility is an F5 iApps® template for the SSL air gap. The template, with its detailed deployment guide, helps an administrator set up the necessary configuration items to decrypt and then re-encrypt the outbound traffic. This air gap iApp template will work with BIG-IP versions 11.4.0 through 12.0 and above, and customers are already using the F5 air gap iApps template with several partner technologies. A partial list of those partner solutions includes: • The F5 and SourceFire Reference Architecture. • The F5 and FireEye Recommended Practices and Deployment Guide. • The F5 and WebSense Deployment Guide. However, there are some nuances that warrant additional discussion. One of these topics is the issue of what traffic not to inspect, and the other is provisioning hardware resources within the vCMP subsystem.

Which sites should bypass SSL inspection There are times when an administrator will not want to inspect traffic between a corporate user and a web site for liability reasons. Chief among these is when a corporate user visits his or her online banking site. If the enterprise administrator snoops on the user’s connection and somehow money is incorrectly depleted from the user’s account, the 45


administrator could be seen as complicit or liable. Therefore, to reduce this complication, administrators have learned to whitelist the financial websites. Financial firms have experienced security teams and entire fraud departments, so their websites are vastly cleaner than a typical website. There are a couple of ways to implement such a whitelist for SSL bypass. • Using F5 URL categorization Several organizations maintain databases categorizing millions (or even billions) of URLs and provide this information as a product or service. F5 provides access to a URL categorization database through the F5 Secure Web Gateway Services. Secure Web Gateway Services users can simply leverage the URL categorization database to instruct the air gap iApp template not to inspect at financial websites. • Manually maintaining a whitelist bypass data group This is the more labor-intensive way to maintain a bypass list. When configuring the iApp template, enter the name of a data group that contains the list of IP addresses to bypass. As more addresses that should not be inspected are found over time, they can be manually added to this list. For smaller, low-touch deployments, this may be a workable option.

F5 recommended practices for SSL air gap egress inspection: • Use the F5 URL categorization service to automatically populate the bypass list. • Use transparent mode instead of explicit mode for the SSL air gap inspection. Explicit proxy mode works better for legitimate clients but ignores malware, making the transparent mode a requirement. • The F5 air gap iApp template offers a choice for dealing with Internet sites with expired certificates: drop or ignore. There are more expired certificates on the Internet than you might suspect, so F5 recommends dropping them, even though this may increase the number of inaccessible websites. When “ignore” is specified, expired certificates on the Internet may temporarily become valid when the air gap rewrites the certificate.

Provisioning SSL hardware resources to vCMP Another intricacy of the air gap solution is resource provisioning. F5 vCMP is a unique virtualization-in-a-box platform delivered on higher-end appliances. All VIPRION chassis systems can be configured with vCMP. In the vCMP system, one of the host processors runs a special version of TMOS that contains an F5 hypervisor. The vCMP hypervisor allows multiple virtual guest operating systems (which must be individual versions of TMOS).

46


In this way, a VIPRION system may be shared among different IT units such as networking, security, and DNS. Beginning with BIG-IP version 12.0, an administrator can now control if and how SSL resources are dedicated within the various guests inside the hypervisor. The following options are supported: • Dedicated: The guest will be assigned dedicated SSL cores. • Shared (default): Guests share from a pool of SSL cores. • None: The guest will have no access to SSL hardware (for example, BIG-IP DNS).

Figure 15: SSL resource dedication options in BIG-IP version 12.0 on the VIPRION chassis.

This functionality is available on the 5000, 7000, 10000, and 12000 platforms, as well as the B2250 blade.

Mitigating brute force attacks The complex nature of SSL continues to allow it to be an attack vector for distributed denial-of-service (DDoS) attacks. In addition to complexity, SSL by design blinds network equipment to network traffic. The combination of complexity and blindness of SSL makes

47


it a target for DDoS attacks. As the volume of legitimate SSL traffic continues to increase, malevolent DDoS traffic becomes more onerous to discern. As a result, good DDoS defense measures have emerged as climacteric for sites, and F5 recommendations address how to best mitigate specific classes of DDoS attacks.

SSL renegotiation attacks SSL renegotiation is a feature that allows a client to restart an SSL connection. Since the legitimate uses for SSL renegotiation are few and there are several attacks based on SSL renegotiation, newer protocols such as HTTP/2 require disabling SSL renegotiation. A single client can perform a DoS attack on a server. The premise of the attack is simple: An SSL/TLS handshake requires at least 10 times more processing power on the server than on the client. If a client machine and server machine were equal in RSA processing power, the client could overwhelm the server by sending ten times as many SSL handshake requests as the server could service. This vulnerability exists for all SSL negotiations; the only mitigation is the ratio between the two participants, which is why SSL acceleration is so critical.

F5 recommended practices to mitigate SSL renegotiation attacks: • If renegotiation is not needed for an application, disable SSL renegotiation in the clientssl profile associated with the virtual server. • If renegotiation is needed, use the many renegotiation options associated with the profile, including secure renegotiation, maximum renegotiation counts, and intervals. See the SSL Administration guide for the full list of renegotiation options.

No-crypto brute force attacks There is a new class of SSL attacks tools that could be called no-crypto attack tools. These new attack tools boost the computational asymmetry between the client and the server by orders of magnitude through a pronounced reduction in client workload. Basically, the new attack clients do not perform any crypto at all—they just send pre-canned packets that look like an SSL handshake but are not. In his excellent analysis of handshake attacks, Vincent Bernat writes about these efficient attack tools: “With such a tool and a 2048 bit RSA certificate, a server is using 100 times more processing power than the client. Unfortunately, this means that most solutions, except rate limiting, exposed [in his analysis] may just be ineffective.”

48


So far, these attacks have not been seen in the wild, but discussed in the academic and IETF community.

F5 recommended practices for mitigating no-crypto brute force attacks: • The ssl_hx_rlimit iRules script limits the number of connections from a single IP. Note that this iRules script could inadvertently block legitimate users originating from a so-called mega-proxy. • The sslsqueeze_rx iRules script will match and block the exact sslsqueeze signature. If an attacker ever changes the payload of the sslsqueeze tool, this iRules script will need to be modified to match the new payload. • Find more information in the DevCentral article called Mitigating No-Crypto Brute Force SSL Handshake Attacks.

SSL floods Unlike the no-crypto attacks, DDoS attacks as a flood of open SSL connections have been seen in the wild. These attacks can be a challenge to mitigate for the SSL pass-through deployment scenario because many devices on the network are blind to the attack. The high-capacity SSL connection tables are largely resistant to SSL floods. A typical SSL flood may involve only a few thousand to tens of thousands of empty SSL connections. However, even the smallest F5 platform can absorb 500,000 SSL connections or more.

F5 recommended practices for mitigating SSL floods: • Using SSL session tickets can enable legitimate clients to benefit from the session cache during an SSL connection flood. See the previous section on SSL failover options. • In the unlikely event that the BIG-IP device’s connection table does become full, connections will be reaped according to the adaptive reaping low-water and highwater settings. These can be adjusted downward from the default values of 85 and 95 to more quickly begin mitigating a “spiky” DDoS, thus reducing the initial attack window. Solution 15740 provides more detail on the workings of the adaptive reaper. (tmos)# modify ltm global-settings connection adaptive-reaper-lowater 75

• If the connection flood consists primarily of empty connections, instruct the BIG-IP device to be more aggressive about reaping connections by modifying the TCP profile associated with the virtual server. During a heavy attack, use smaller and smaller values. 49


(tmos)# create ltm profile tcp tcp_ddos { reset-on-timeout disabled idle-timeout 15 }

• The hardware-syn-cookie and zero-window-timeout values of the TCP profile may also be adjusted.

Instrumentation: The SSL statistics panel The BIG-IP platform’s SSL statistics panel is a powerful tool that collates useful counters for protocol handshake types, key exchange types, and connection failures. To view it, click Statistics on the left pane, select Module Statistics, and then click Local Traffic. Under Statistics Type, select Profiles Summary and then Client SSL.

Figure 16: The SSL statistics panel

In the BIG-IP system version 12.0, the information collected and displayed for SSL includes all the fields from the following table:

50


Statistic Category

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 DiffieHelman (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

51


log all messages associated with SSL connections, even those that are purely informational. Typically log message are sent to the file /var/log/ltm unless otherwise configured.

Figure 17: Tuning the SSL logging level

F5 recommended practices for SSL instrumentation: • Use the SSL statistics panel to see a holistic and aggregate statistical view. • Change the SSL debug log setting to suit your needs. But note that SSL debug mode may have significant performance impacts. Endeavor not to enable it on production systems. • Give the certificate manager role access to logs. • Use remote logging when debugging production systems. This is critical.

Conclusion SSL has been the standard for encrypting transactions for the past two decades. Like all technology, SSL has experienced significant changes throughout its life, and the pace of change is expected to continue. These changes to SSL covers vast areas, while their impact ranges from the annoying to the critical. Changes to ciphers alone include: • New ciphers. • New classes of ciphers, such as ECC. • New approaches to ciphers, such as forward secrecy.

52

RECOMMENDED PRACTICES Advanced Threat Protection with FireEye and F5

SSL has become an attack surface that is particularly vulnerable to DDoS attacks taking advantage of the relatively large machine costs associated with hosting SSL server traffic. Administrators who wish to stay in front of changes, choosing proactive strategies instead of reactive tactics, need to remain aware of the most current options and trends. Those proactive administrators can follow F5 recommended practices to not only stay in front of existing trends but be prepared for hitherto unforeseen changes and fundamental shifts. These recommendations enable an organization to be favorably aligned to the existing SSL landscape while gaining the nimbleness to meet new challenges. Following the recommended practices optimally positions the organization for future security, scalability, and reliability.

F5 Networks, Inc. 401 Elliott Avenue West, Seattle, WA 98119 Americas [email protected]

Asia-Pacific [email protected]

888-882-4447

Europe/Middle-East/Africa [email protected]

f5.com Japan K.K. [email protected]

©2015 F5 Networks, Inc. All rights reserved. F5, F5 Networks, and the F5 logo are trademarks of F5 Networks, Inc. in the U.S. and in certain other countries. Other F5 trademarks are identified at f5.com. Any other products, services, or company names referenced herein may be trademarks of their respective owners with no endorsement or affiliation, express or implied, claimed by F5. 1015 RECP-SEC-66014525-ssl

F5 SSL Everywhere Recommended Practices

Recommend Documents