The BIG-IP Application Security Manager Part 1: What is the ASM?
tl;dr - BIG-IP Application Security Manager (ASM) is a layer 7 web application firewall (WAF) available on F5's BIG-IP platforms. Introduction This article series was written a while back, but we are re-introducing it as a part of our Security Month on DevCentral. I hope you enjoy all the features of this very powerful module on the BIG-IP! This is the first of a 10-part series on the BIG-IP ASM. This module is a very powerful and effective tool for defending your applications and your peace of mind, but what is it really? And, how do you configure it correctly and efficiently? How can you take advantage of all the features it has to offer? Well, the purpose of this article series is to answer these fundamental questions. So, join me as we dive into this really cool technology called the BIG-IP ASM! The Basics The BIG-IP ASM is a Layer 7 ICSA-certified Web Application Firewall (WAF) that provides application security in traditional, virtual, and private cloud environments. It is built on TMOS...the universal product platform shared by all F5 BIG-IP products. It can run on any of the F5 Application Delivery Platforms...BIG-IP Virtual Edition, BIG-IP 2000 -> 11050, and all the VIPRION blades. It protects your applications from a myriad of network attacks including the OWASP Top 10 most critical web application security risks It is able to adapt to constantly-changing applications in very dynamic network environments It can run standalone or integrated with other modules like BIG-IP LTM, BIG-IP DNS, BIG-IP APM, etc Why A Layer 7 Firewall? Traditional network firewalls (Layer 3-4) do a great job preventing outsiders from accessing internal networks. But, these firewalls offer little to no support in the protection of application layer traffic. As David Holmes points out in his article series on F5 firewalls, threat vectors today are being introduced at all layers of the network. For example, the Slowloris and HTTP Flood attacks are Layer 7 attacks...a traditional network firewall would never stop these attacks. But, nonetheless, your application would still go down if/when it gets hit by one of these. So, it's important to defend your network with more than just a traditional Layer 3-4 firewall. That's where the ASM comes in... Some Key Features The ASM comes pre-loaded with over 2,200 attack signatures. These signatures form the foundation for the intelligence used to allow or block network traffic. If these 2,200+ signatures don't quite do the job for you, never fear...you can also build your own user-defined signatures. And, as we all know, network threats are always changing so the ASM is configured to download updated attack signatures on a regular basis. Also, the ASM offers several different policy building features. Policy building can be difficult and time consuming, especially for sites that have a large number of pages. For example, DevCentral has over 55,000 pages...who wants to hand-write the policy for that?!? No one has that kind of time. Instead, you can let the system automatically build your policy based on what it learns from your application traffic, you can manually build a policy based on what you know about your traffic, or you can use external security scanning tools (WhiteHat Sentinel, QualysGuard, IBM AppScan, Cenzic Hailstorm, etc) to build your policy. In addition, the ASM comes configured with pre-built policies for several popular applications (SharePoint, Exchange, Oracle Portal, Oracle Application, Lotus Domino, etc). Did you know? The BIG-IP ASM was the first WAF to integrate with a scanner. WhiteHat approached all the WAFs and asked about the concept of building a security policy around known vulnerabilities in the apps. All the other WAFs said "no"...F5 said "of course!" and thus began the first WAF-scanner integration. The ASM also utilizes Geolocation and IP address intelligence to allow for more sophisticated and targeted defense measures. You can allow/block users from specific locations around the world, and you can block IP addresses that have built a bad reputation on other sites around the Internet. If they were doing bad things on some other site, why let them access yours? The ASM is also built for Payment Card Industry Data Security Standard (PCI DSS) compliance. In fact, you can generate a real-time PCI compliance report at the click of a button! The ASM also comes loaded with the DataGuard feature that automatically blocks sensitive data (Credit Card numbers, SSN, etc) from being displayed in a browser. In addition to the PCI reports, you can generate on-demand charts and graphs that show just about every detail of traffic statistics that you need. The following screenshot is a representative sample of some real traffic that I pulled off a site that uses the ASM. Pretty powerful stuff! I could go on for days here...and I know you probably want me to, but I'll wrap it up for this first article. I hope you can see the value of the ASM both as a technical solution in the defense of your network and also a critical asset in the long-term strategic vision of your company. So, if you already have an ASM and want to know more about it or if you don't have one yet and want to see what you're missing, come on back for the next article where I will talk about the cool features of policy building. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event LoggingCipher Suite Practices and Pitfalls
Cipher Suite Practices and Pitfalls It seems like every time you turn around there is a new vulnerability to deal with, and some of them, such as Sweet32, have required altering cipher configurations for mitigation. Still other users may tweak their cipher suite settings to meet requirements for PCI compliance, regulatory issues, local compatibility needs, etc. However, once you start modifying your cipher suite settings you must take great care, as it is very easy to shoot yourself in the foot. Many misconfigurations will silently fail – seeming to achieve the intended result while opening up new, even worse, vulnerabilities. Let's take a look at cipher configuration on the F5 BIG-IP products to try stay on the safe path. What is a Cipher Suite? Before we talk about how they're configured, let's define exactly what we mean by 'cipher suite', how it differs from just a 'cipher', and the components of the suite. Wikipedia had a good summary, so rather than reinvent the wheel: A cipher suite is a named combination of authentication, encryption, message authentication code (MAC) and key exchange algorithms used to negotiate the security settings for a network connection using the Transport Layer Security (TLS) / Secure Sockets Layer (SSL) network protocol. When we talk about configuring ciphers on BIG-IP we're really talking about configuring cipher suites. More specifically the configured list of cipher suites is a menu of options available to be negotiated. Each cipher suite specifies the key exchange algorithm, authentication algorithm, cipher, cipher mode, and MAC that will be used. I recommend reading K15194: Overview of the BIG-IP SSL/TLS cipher suite for more information. But as a quick overview, let's look at a couple of example cipher suites. The cipher suite is in the format: Key Exchange-Authentication-Cipher-Cipher Mode-MAC Note that not all of these components may be explicitly present in the cipher suite, but they are still implicitly part of the suite. Let's consider this cipher suite: ECDHE-RSA-AES256-GCM-SHA384 This breaks down as follows: Key Exchange Algorithm: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) Authentication Algorithm: RSA Cipher: AES256 (aka AES with a 256-bit key) Cipher Mode: GCM (Galois/Counter Mode) MAC: SHA384 (aka SHA-2 (Secure Hash Algorithm 2) with 384-bit hash) This is arguably the strongest cipher suite we have on BIG-IP at this time. Let's compare that to a simpler cipher suite: AES128-SHA Key Exchange Algorithm: RSA (Implied) – When it isn't specified, presume RSA. Authentication Algorithm: RSA (Implied) – When it isn't specified, presume RSA. Cipher: AES128 (aka AES with a 128-bit key) Cipher Mode: CBC (Cipher Block Chaining) (Implied) – When it isn't specified, presume CBC. MAC: SHA1 (Secure Hash Algorithm 1; SHA-1 always produces a 160-bit hash.) This example illustrates that the cipher suite may not always explicitly specify every parameter, but they're still there. There are 'default' values that are fairly safe to presume when not otherwise specified. If an algorithm isn't specified, it is RSA. That's a safe bet. And if a cipher mode isn't specified it is CBC. Always CBC. Note that all ciphers currently supported on BIG-IP are CBC mode except for AES-GCM and RC4. ALL. I stress this as it has been a recurring source of confusion amongst customers. It isn't only the cipher suites which explicitly state 'CBC' in their name. Let's examine each of these components. This article is primarily about cipher suite configuration and ciphers, and not the SSL/TLS protocol, so I won't dive too deeply here, but I think it helps to have a basic understanding. Forgive me if I simplify a bit. Key Exchange Algorithms As a quick review of the difference between asymmetric key (aka public key) cryptography and symmetric key cryptography: With the asymmetric key you have two keys – K public and K private –which have a mathematical relationship. Since you can openly share the public key there is no need to pre-share keys with anyone. The downside is that these algorithms are computationally expensive. Key lengths for a common algorithm such as RSA are at least 1024-bit, and 2048-bit is really the minimally acceptable these days. Symmetric key has only K private . Both ends use the same key, which poses the problem of key distribution. The advantage is higher computational performance and common key sizes are 128-bit or 256-bit. SSL/TLS, of course, uses both public and private key systems – the Key Exchange Algorithm is the public key system used to exchange the symmetric key. Examples you'll see in cipher suites include ECDHE, DHE, RSA, ECDH, and ADH. Authentication Algorithms The Authentication Algorithm is sometimes grouped in with the Key Exchange Algorithm for configuration purposes; 'ECDHE_RSA' for example. But we'll consider it as a separate component. This is the algorithm used in the SSL/TLS handshake for the server to sign (using the server's private key) elements sent to the client in the negotiation. The client can authenticate them using the server's public key. Examples include: RSA, ECDSA, DSS (aka DSA), and Anonymous. Anonymous means no authentication; this is generally bad. The most common way users run into this is by accidentally enabling an 'ADH' cipher suite. More on this later when we talk about pitfalls. Note that when RSA is used for the key exchange, authentication is inherent to the scheme so there really isn't a separate authentication step. However, most tools will list it out for completeness. Cipher To borrow once again from Wikipedia: In cryptography, a cipher (or cypher) is an algorithm for performing encryption or decryption—a series of well-defined steps that can be followed as a procedure. An alternative, less common term is encipherment. To encipher or encode is to convert information into cipher or code. In common parlance, 'cipher' is synonymous with 'code', as they are both a set of steps that encrypt a message; however, the concepts are distinct in cryptography, especially classical cryptography. This is what most of us mean when we refer to 'configuring ciphers'. We're primarily interested in controlling the cipher used to protect our information through encryption. There are many, many examples of ciphers which you may be familiar with: DES (Data Encryption Standard), 3DES (Triple DES), AES (Advanced Encryption Standard), RC4 (Rivest Cipher 4), Camellia, RC6, RC2, Blowfish, Twofish, IDEA, SEED, GOST, Rijndael, Serpent, MARS, etc. For a little cipher humor, I recommend RFC2410: The NULL Encryption Algorithm and Its Use With IPsec. Roughly speaking, ciphers come in two types – block ciphers and stream ciphers. Block Ciphers Block ciphers operate on fixed-length chunks of data, or blocks. For example, DES operates on 64-bit blocks while AES operates on 128-bit blocks. Most of the ciphers you'll encounter are block ciphers. Examples: DES, 3DES, AES, Blowfish, Twofish, etc. Stream Ciphers Stream ciphers mathematically operate on each bit in the data flow individually. The most commonly encountered stream cipher is RC4, and that's deprecated. So we're generally focused on block ciphers, not that it really changes anything for the purposes of this article. All of the secrecy in encryption comes from the key that is used, not the cipher itself. Obtain the key and you can unlock the ciphertext. The cipher itself – the algorithm, source code, etc. – not only can be, but should be, openly available. History is full of examples of private cryptosystems failing due to weaknesses missed by their creators, while the most trusted ciphers were created via open processes (AES for example). Keys are of varying lengths and, generally speaking, the longer the key the more secure the encryption. DES only had 56-bits of key data, and thus is considered insecure. We label 3DES as 168-bit, but it is really only equivalent to 112-bit strength. (More on this later.) Newer ciphers, such as AES, often offer options – 128-bits, 192-bits, or 256-bits of key. Remember, a 256-bit key is far more than twice as strong as a 128-bit key. It is 2 128 vs. 2 256 - 3.4028237e+38 vs. 1.1579209e+77 Cipher Mode Cipher mode is the mode of operation used by the cipher when encrypting plaintext into ciphertext, or decrypting ciphertext into plaintext. The most common mode is CBC – Cipher Block Chaining. In cipher block chaining the ciphertext from block n feeds into the process for block n+1 – the blocks are chained together. To steal borrow an image from Wikipedia: As I mentioned previously, all ciphers on BIG-IP are CBC mode except for RC4 (the lone stream cipher, disabled by default starting in 11.6.0) and AES-GCM. AES-GCM was first introduced in 11.5.0, and it is only available for TLSv1.2 connections. GCM stands for Galois/Counter Mode, a more advanced mode of operation than CBC. In GCM the blocks are not chained together. GCM runs in an Authenticated Encryption with Associated Data (AEAD) mode which eliminates the separate per-message hashing step, therefore it can achieve higher performance than CBC mode on a given HW platform. It is also immune to classes of attack that have harried CBC, such as the numerous padding attacks (BEAST, Lucky 13, etc.) Via Wikipedia: The main drawback to AES-GCM is that it was only added in TLSv1.2, so any older clients which don't support TLSv1.2 cannot use it. There are other cipher suites officially supported in TLS which have other modes, but F5 does not currently support those ciphers so we won't get too deep into that. Other ciphers include AES-CCM (CTR mode with a CBC MAC; CTR is Counter Mode), CAMELLIA-GCM (CAMELLIA as introduced in 12.0.0 is CBC), and GOST CNT (aka CTR). We may see these in the future. MAC aka Hash Function What did we ever do before Wikipedia? A hash function is any function that can be used to map data of arbitrary size to data of fixed size. The values returned by a hash function are called hash values, hash codes, digests, or simply hashes. One use is a data structure called a hash table, widely used in computer software for rapid data lookup. Hash functions accelerate table or database lookup by detecting duplicated records in a large file. An example is finding similar stretches in DNA sequences. They are also useful in cryptography. A cryptographic hash function allows one to easily verify that some input data maps to a given hash value, but if the input data is unknown, it is deliberately difficult to reconstruct it (or equivalent alternatives) by knowing the stored hash value. This is used for assuring integrity of transmitted data, and is the building block for HMACs, which provide message authentication. In short, the MAC provides message integrity. Hash functions include MD5, SHA-1 (aka SHA), SHA-2 (aka SHA128, SHA256, & SHA384), and AEAD (Authenticated Encryption with Associated Data). MD5 has long since been rendered completely insecure and is deprecated. SHA-1 is now being 'shamed', if not blocked, by browsers as it is falling victim to advances in cryptographic attacks. While some may need to continue to support SHA-1 cipher suites for legacy clients, it is encouraged to migrate to SHA-2 as soon as possible – especially for digital certificates. Configuring Cipher Suites on BIG-IP Now that we've covered what cipher suites are, let's look at where we use them. There are two distinct and separate areas where cipher suites are used – the host, or control plane, and TMM, or the data plane. On the host side SSL/TLS is handled by OpenSSL and the configuration follows the standard OpenSSL configuration options. Control Plane The primary use of SSL/TLS on the control plane is for httpd. To see the currently configured cipher suite, use ' tmsh list sys http ssl-ciphersuite '. The defaults may vary depending on the version of TMOS. For example, these were the defaults in 12.0.0: tmsh list sys http ssl-ciphersuite sys httpd { ssl-ciphersuite DEFAULT:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP } As of 12.1.2 these have been updated to a more explicit list: tmsh list sys http ssl-ciphersuite sys httpd { ssl-ciphersuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES128-SHA256:AES256-SHA256:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA } You can change this configuration via ' tmsh modify sys http ssl-ciphersuite <value> '. One important thing to note is that the default is not just 'DEFAULT' as it is on the data plane. This is one thing that users have been caught by; thinking that setting the keyword to 'DEFAULT' will reset the configuration. As OpenSSL provides SSL/TLS support for the control plane, if you want to see which ciphers will actually be supported you can use ' openssl ciphers -v <cipherstring> '. For example: openssl ciphers -v 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES128-SHA256:AES256-SHA256:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA' ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 Now let's see what happens if you use 'DEFAULT': openssl ciphers -v 'DEFAULT' ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1 ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1 EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export As you can see that enables far, far more ciphers, including a number of unsafe ciphers – export, MD5, DES, etc. This is a good example of why you always want to confirm your cipher settings and check exactly what is being enabled before placing new settings into production. Many security disasters could be avoided if everyone doublechecked their settings first. Let’s take a closer look at how OpenSSL represents one of the cipher suites: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD The columns are: Cipher Suite: ECDHE-RSA-AES256-GCM-SHA384 Protocol: TLSv1.2 Key Exchange Algorithm (Kx): ECDH Authentication Algorithm (Au): RSA Cipher/Encryption Algorithm (Enc): AESGCM(256) MAC (Mac): AEAD Since the control plane uses OpenSSL you can use the standard OpenSSL documentation, so I won't spend a lot of time on that. Data Plane In TMM the cipher suites are configured in the Ciphers field of the Client SSL or Server SSL profiles. See K14783: Overview of the Client SSL profile (11.x - 12.x) & K14806: Overview of the Server SSL profile (11.x - 12.x), respectively for more details. It is important to keep in mind that these are two different worlds with their own requirements and quirks. As most of the configuration activity, and security concerns, occur on the public facing side of the system, we'll focus on the Client SSL Profile. Most of the things we'll cover here will also apply to the Server SSL profile. In the GUI it appears as an editable field: Presuming the profile was created with the name 'Test': tmsh list ltm profile client-ssl Test ltm profile client-ssl Test { app-service none cert default.crt cert-key-chain { default { cert default.crt key default.key } } chain none ciphers DEFAULT defaults-from clientssl inherit-certkeychain true key default.key passphrase none } Modifying the cipher configuration from the command line is simple. tmsh list ltm profile client-ssl Test ciphers ltm profile client-ssl Test { ciphers DEFAULT } tmsh modify ltm profile client-ssl Test ciphers 'DEFAULT:!3DES' tmsh list ltm profile client-ssl Test ciphers ltm profile client-ssl Test { ciphers DEFAULT:!3DES } Just remember the ' tmsh save sys config ' when you're happy with the configuration. Note here the default is just 'DEFAULT'. What that expands to will vary depending on the version of TMOS. K13156: SSL ciphers used in the default SSL profiles (11.x - 12.x) defines the default values for each version of TMOS. Or you can check it locally from the command line: tmm --clientciphers 'DEFAULT' On 12.1.2 that would be: tmm --clientciphers 'DEFAULT' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 159 DHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 EDH/RSA 1: 158 DHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 EDH/RSA 2: 107 DHE-RSA-AES256-SHA256 256 TLS1.2 Native AES SHA256 EDH/RSA 3: 57 DHE-RSA-AES256-SHA 256 TLS1 Native AES SHA EDH/RSA 4: 57 DHE-RSA-AES256-SHA 256 TLS1.1 Native AES SHA EDH/RSA 5: 57 DHE-RSA-AES256-SHA 256 TLS1.2 Native AES SHA EDH/RSA 6: 57 DHE-RSA-AES256-SHA 256 DTLS1 Native AES SHA EDH/RSA 7: 103 DHE-RSA-AES128-SHA256 128 TLS1.2 Native AES SHA256 EDH/RSA 8: 51 DHE-RSA-AES128-SHA 128 TLS1 Native AES SHA EDH/RSA 9: 51 DHE-RSA-AES128-SHA 128 TLS1.1 Native AES SHA EDH/RSA 10: 51 DHE-RSA-AES128-SHA 128 TLS1.2 Native AES SHA EDH/RSA 11: 51 DHE-RSA-AES128-SHA 128 DTLS1 Native AES SHA EDH/RSA 12: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1 Native DES SHA EDH/RSA 13: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1.1 Native DES SHA EDH/RSA 14: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1.2 Native DES SHA EDH/RSA 15: 22 DHE-RSA-DES-CBC3-SHA 168 DTLS1 Native DES SHA EDH/RSA 16: 157 AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 RSA 17: 156 AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 RSA 18: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSA 19: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 20: 53 AES256-SHA 256 TLS1.1 Native AES SHA RSA 21: 53 AES256-SHA 256 TLS1.2 Native AES SHA RSA 22: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 23: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA 24: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 25: 47 AES128-SHA 128 TLS1.1 Native AES SHA RSA 26: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 27: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 28: 10 DES-CBC3-SHA 168 TLS1 Native DES SHA RSA 29: 10 DES-CBC3-SHA 168 TLS1.1 Native DES SHA RSA 30: 10 DES-CBC3-SHA 168 TLS1.2 Native DES SHA RSA 31: 10 DES-CBC3-SHA 168 DTLS1 Native DES SHA RSA 32: 49200 ECDHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 ECDHE_RSA 33: 49199 ECDHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 ECDHE_RSA 34: 49192 ECDHE-RSA-AES256-SHA384 256 TLS1.2 Native AES SHA384 ECDHE_RSA 35: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 Native AES SHA ECDHE_RSA 36: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.1 Native AES SHA ECDHE_RSA 37: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.2 Native AES SHA ECDHE_RSA 38: 49191 ECDHE-RSA-AES128-SHA256 128 TLS1.2 Native AES SHA256 ECDHE_RSA 39: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1 Native AES SHA ECDHE_RSA 40: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.1 Native AES SHA ECDHE_RSA 41: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.2 Native AES SHA ECDHE_RSA 42: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1 Native DES SHA ECDHE_RSA 43: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1.1 Native DES SHA ECDHE_RSA 44: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1.2 Native DES SHA ECDHE_RSA Some differences when compared to OpenSSL are readily apparent. For starters, TMM kindly includes a column label header, and actually aligns the columns. The first column is simply a 0-ordinal numeric index, the rest are as follows: ID: The official SSL/TLS ID assigned to that cipher suite. SUITE: The cipher suite. BITS: The size of the key in bits. PROT: The protocol supported. METHOD: NATIVE (in TMM) vs. COMPAT (using OpenSSL code). CIPHER: The cipher. MAC: The hash function. KEYX: The Key Exchange and Authentication Algorithms Note that the MAC is a little misleading for AES-GCM cipher suites. There is no separate MAC as they're AEAD. But the hashing algorithm is used in the Pseudo-Random Function (PRF) and a few other handshake related places. Selecting the Cipher Suites Now we know how to look at the current configuration, modify it, and list the actual ciphers that will be enabled by the listed suites. But what do we put into the configuration? Most users won't have to touch this. The default values are carefully selected by F5 to meet the needs of the majority of our customers. That's the good news. The bad news is that some customers will need to get in there and change the configuration – be it for regulatory compliance, internal policies, legacy client support, etc. Once you begin modifying them, the configuration is truly custom for each customer. Every customer who modifies the configuration, and uses a custom cipher configuration, needs to determine what the proper list is for their needs. Let's say we have determined that we need to support only AES & AES-GCM, 128-bit or 256-bit, and only ECDHE key exchange. Any MAC or Authentication is fine. OK, let's proceed from there. On 12.1.2 there are six cipher suites that fit those criteria. We could list them all explicitly: tmm --clientciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-CBC-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-CBC-SHA' That will work, but it gets unwieldy fast. Not only that, but in versions up to 11.5.0 the ciphers configuration string was truncated at 256bytes. Starting in 11.5.0 that was increased to 768bytes, but that can still truncate long configurations. We'll revisit this when we get to the pitfalls section. Fortunately, there is an alternative – keywords! This will result in the same list of cipher suites: tmm --clientciphers 'ECDHE+AES-GCM:ECDHE+AES' That specifies the ECDHE key exchange with AES-GCM ciphers, and ECDHE with AES ciphers. Let's take a closer look to help understand what is happening here. Keywords Keywords are extremely important when working with cipher suite configuration, so we'll spend a little time on those. Most of these apply to both the control plane (OpenSSL) and the data plane (TMM), unless otherwise noted, but we're focused on the data plane as that's F5 specific. Keywords organize into different categories. F5 specific: NATIVE: cipher suites implemented natively in TMM COMPAT: cipher suites using OpenSSL code; removed as of 12.0.0 @SPEED: Re-orders the list to put 'faster' (based on TMOS implementation performance) ciphers first. Sorting: @SPEED: Re-orders the list to put 'faster' (based on TMOS implementation performance) ciphers first. (F5 Specific) @STRENGTH: Re-orders the list to put 'stronger' (larger keys) ciphers first. Protocol: TLSv1_2: cipher suites available under TLSv1.2 TLSv1_1: cipher suites available under TLSv1.1 TLSv1: cipher suites available under TLSv1.0 SSLv3: cipher suites available under SSLv3 Note the 'Protocol' keywords in the cipher configuration control the ciphers associated with that protocol, and not the protocol itself! More on this in pitfalls. Key Exchange Algorithms (sometimes with Authentication specified): ECDHE or ECDHA_RSA: Elliptic Curve Diffie-Hellman Ephemeral (with RSA) ECDHE_ECDSA: ECDHE with Elliptic Curve Digital Signature Algorithm DHE or EDH: Diffie-Hellman Ephemeral (aka Ephemeral Diffie-Hellman) (with RSA) DHE_DSS: DHE with Digital Signature Standard (aka DSA – Digital Signature Algorithm) ECDH_RSA: Elliptic Curve Diffie-Hellman with RSA ECDH_ECDSA: ECDH with ECDSA RSA: RSA, obviously ADH: Anonymous Diffie-Hellman. Note the Authentication Algorithms don't work as standalone keywords in TMM. You can't use 'ECDSA' or 'DSS' for example. And you might think ECDHE or DHE includes all such cipher suites – note that they don't if you read carefully. General cipher groupings: DEFAULT: The default cipher suite for that version; see K13156 ALL: All NATIVE cipher suites; does not include COMPAT in current versions HIGH: 'High' security cipher suites; >128-bit MEDIUM: 'Medium' security cipher suites; effectively 128-bit suites LOW: 'Low' security cipher suites; <128-bit excluding export grade ciphers EXP or EXPORT: Export grade ciphers; 40-bit or 56-bit EXPORT56: 56-bit export ciphers EXPORT40: 40-bit export ciphers Note that DEFAULT does change periodically as F5 updates the configuration to follow the latest best practices. K13156: SSL ciphers used in the default SSL profiles (11.x - 12.x) documents these changes. Cipher families: AES-GCM: AES in GCM mode; 128-bit or 256-bit AES: AES in CBC mode; 128-bit or 256-bit CAMELLIA: Camellia in CBC mode; 128-bit or 256-bit 3DES: Triple DES in CBC mode; 168-bit (well, 112-bit really) DES: Single DES in CBC mode, includes EXPORTciphers;40-bit & 56-bit. RC4: RC4 stream cipher NULL: NULL cipher; just what it sounds like, it does nothing – no encryption MAC aka Hash Function: SHA384: SHA-2 384-bit hash SHA256: SHA-2 256-bit hash SHA1 or SHA: SHA-1 160-bit hash MD5: MD5 128-bit hash Other: On older TMOS versions when using the COMPAT keyword it also enables two additional keywords: SSLv2: Ciphers supported on the SSLv2 protocol RC2: RC2 ciphers. So, let's go back to our example: tmm --clientciphers 'ECDHE+AES-GCM:ECDHE+AES' Note that you can combine keywords using '+' (plus sign). And multiple entries in the ciphers configuration line are separated with ':' (colon). You may also need to wrap the string in single quotes on the command line – I find it is a good habit to just always do so. We can also exclude suites or keywords. There are two ways to do that: '!' (exclamation point) is a hard exclusion. Anything excluded this way cannot be implicitly or explicitly re-enabled. It is disabled, period. '-' (minus sign or dash) is a soft exclusion. Anything excluded this way can be explicitly re-enabled later in the configuration string. (Note: The dash is also usedinthe names of many cipher suites, such as ECDHE-RSA-AES256-GCM-SHA384 or AES128-SHA. Do not confuse the dashes that are part of the cipher suite names with a soft exclusion, which alwaysprecedes, or prefixes,the value being excluded. 'AES128-SHA': AES128-SHA cipher suite. '-SHA': SHA is soft excluded. '-AES128-SHA': the AES128-SHA cipher suite is soft excluded. Position matters.) Let's look at the difference in hard and soft exclusions. We'll start with our base example: tmm --clientciphers 'ECDHE+AES-GCM:DHE+AES-GCM' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 49200 ECDHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 ECDHE_RSA 1: 49199 ECDHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 ECDHE_RSA 2: 159 DHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 EDH/RSA 3: 158 DHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 EDH/RSA Now let's look at a hard exclusion: tmm --clientciphers 'ECDHE+AES-GCM:!DHE:DHE+AES-GCM' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 49200 ECDHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 ECDHE_RSA 1: 49199 ECDHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 ECDHE_RSA And lastly a soft exclusion: tmm --clientciphers 'ECDHE+AES-GCM:-DHE:DHE+AES-GCM' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 49200 ECDHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 ECDHE_RSA 1: 49199 ECDHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 ECDHE_RSA 2: 159 DHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 EDH/RSA 3: 158 DHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 EDH/RSA Note that in the second example, the hard exclusion, we used '!DHE' and even though we then explicitly added 'DHE+AES-GCM' those ciphers were not enabled. This is because, once excluded with a hard exclusion, ciphers cannot be re-enabled. In the third example, the soft exclusion, we used '-DHE' and then 'DHE+AES-GCM'. This time it did enable those ciphers, which is possible with a soft exclusion. You might be wondering what soft disabling is useful for; why would you ever want to remove ciphers only to add them again? Reordering the ciphers is a common use case. As an example, DEFAULT orders ciphers differently in different versions, but mainly based on strength – bit size. Let's say we know 3DES is really 112-bit equivalent strength and not 168-bit as it is usually labeled. For some reason, maybe legacy clients, we can't disable them, but we want them to be last on the list. One way to do this is to first configure the DEFAULT list, then remove all of the 3DES ciphers. But then add the 3DES ciphers back explicitly – at the end of the list. Let's try it – compare the following: tmm --clientciphers 'DEFAULT' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 159 DHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 EDH/RSA 1: 158 DHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 EDH/RSA 2: 107 DHE-RSA-AES256-SHA256 256 TLS1.2 Native AES SHA256 EDH/RSA 3: 57 DHE-RSA-AES256-SHA 256 TLS1 Native AES SHA EDH/RSA 4: 57 DHE-RSA-AES256-SHA 256 TLS1.1 Native AES SHA EDH/RSA 5: 57 DHE-RSA-AES256-SHA 256 TLS1.2 Native AES SHA EDH/RSA 6: 57 DHE-RSA-AES256-SHA 256 DTLS1 Native AES SHA EDH/RSA 7: 103 DHE-RSA-AES128-SHA256 128 TLS1.2 Native AES SHA256 EDH/RSA 8: 51 DHE-RSA-AES128-SHA 128 TLS1 Native AES SHA EDH/RSA 9: 51 DHE-RSA-AES128-SHA 128 TLS1.1 Native AES SHA EDH/RSA 10: 51 DHE-RSA-AES128-SHA 128 TLS1.2 Native AES SHA EDH/RSA 11: 51 DHE-RSA-AES128-SHA 128 DTLS1 Native AES SHA EDH/RSA 12: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1 Native DES SHA EDH/RSA 13: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1.1 Native DES SHA EDH/RSA 14: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1.2 Native DES SHA EDH/RSA 15: 22 DHE-RSA-DES-CBC3-SHA 168 DTLS1 Native DES SHA EDH/RSA 16: 157 AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 RSA 17: 156 AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 RSA 18: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSA 19: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 20: 53 AES256-SHA 256 TLS1.1 Native AES SHA RSA 21: 53 AES256-SHA 256 TLS1.2 Native AES SHA RSA 22: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 23: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA 24: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 25: 47 AES128-SHA 128 TLS1.1 Native AES SHA RSA 26: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 27: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 28: 10 DES-CBC3-SHA 168 TLS1 Native DES SHA RSA 29: 10 DES-CBC3-SHA 168 TLS1.1 Native DES SHA RSA 30: 10 DES-CBC3-SHA 168 TLS1.2 Native DES SHA RSA 31: 10 DES-CBC3-SHA 168 DTLS1 Native DES SHA RSA 32: 49200 ECDHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 ECDHE_RSA 33: 49199 ECDHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 ECDHE_RSA 34: 49192 ECDHE-RSA-AES256-SHA384 256 TLS1.2 Native AES SHA384 ECDHE_RSA 35: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 Native AES SHA ECDHE_RSA 36: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.1 Native AES SHA ECDHE_RSA 37: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.2 Native AES SHA ECDHE_RSA 38: 49191 ECDHE-RSA-AES128-SHA256 128 TLS1.2 Native AES SHA256 ECDHE_RSA 39: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1 Native AES SHA ECDHE_RSA 40: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.1 Native AES SHA ECDHE_RSA 41: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.2 Native AES SHA ECDHE_RSA 42: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1 Native DES SHA ECDHE_RSA 43: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1.1 Native DES SHA ECDHE_RSA 44: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1.2 Native DES SHA ECDHE_RSA tmm --clientciphers 'DEFAULT:-3DES:!SSLv3:3DES+ECDHE:3DES+DHE:3DES+RSA' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 159 DHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 EDH/RSA 1: 158 DHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 EDH/RSA 2: 107 DHE-RSA-AES256-SHA256 256 TLS1.2 Native AES SHA256 EDH/RSA 3: 57 DHE-RSA-AES256-SHA 256 TLS1 Native AES SHA EDH/RSA 4: 57 DHE-RSA-AES256-SHA 256 TLS1.1 Native AES SHA EDH/RSA 5: 57 DHE-RSA-AES256-SHA 256 TLS1.2 Native AES SHA EDH/RSA 6: 57 DHE-RSA-AES256-SHA 256 DTLS1 Native AES SHA EDH/RSA 7: 103 DHE-RSA-AES128-SHA256 128 TLS1.2 Native AES SHA256 EDH/RSA 8: 51 DHE-RSA-AES128-SHA 128 TLS1 Native AES SHA EDH/RSA 9: 51 DHE-RSA-AES128-SHA 128 TLS1.1 Native AES SHA EDH/RSA 10: 51 DHE-RSA-AES128-SHA 128 TLS1.2 Native AES SHA EDH/RSA 11: 51 DHE-RSA-AES128-SHA 128 DTLS1 Native AES SHA EDH/RSA 12: 157 AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 RSA 13: 156 AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 RSA 14: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSA 15: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 16: 53 AES256-SHA 256 TLS1.1 Native AES SHA RSA 17: 53 AES256-SHA 256 TLS1.2 Native AES SHA RSA 18: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 19: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA 20: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 21: 47 AES128-SHA 128 TLS1.1 Native AES SHA RSA 22: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 23: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 24: 49200 ECDHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 ECDHE_RSA 25: 49199 ECDHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 ECDHE_RSA 26: 49192 ECDHE-RSA-AES256-SHA384 256 TLS1.2 Native AES SHA384 ECDHE_RSA 27: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 Native AES SHA ECDHE_RSA 28: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.1 Native AES SHA ECDHE_RSA 29: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.2 Native AES SHA ECDHE_RSA 30: 49191 ECDHE-RSA-AES128-SHA256 128 TLS1.2 Native AES SHA256 ECDHE_RSA 31: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1 Native AES SHA ECDHE_RSA 32: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.1 Native AES SHA ECDHE_RSA 33: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.2 Native AES SHA ECDHE_RSA 34: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1 Native DES SHA ECDHE_RSA 35: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1.1 Native DES SHA ECDHE_RSA 36: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1.2 Native DES SHA ECDHE_RSA 37: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1 Native DES SHA EDH/RSA 38: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1.1 Native DES SHA EDH/RSA 39: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1.2 Native DES SHA EDH/RSA 40: 22 DHE-RSA-DES-CBC3-SHA 168 DTLS1 Native DES SHA EDH/RSA 41: 10 DES-CBC3-SHA 168 TLS1 Native DES SHA RSA 42: 10 DES-CBC3-SHA 168 TLS1.1 Native DES SHA RSA 43: 10 DES-CBC3-SHA 168 TLS1.2 Native DES SHA RSA 44: 10 DES-CBC3-SHA 168 DTLS1 Native DES SHA RSA I added something else in there which I'll come back to later. Pitfalls As should be clear by now cipher configuration is a powerful tool, but as the song says, every tool is a weapon if you hold it right. And weapons are dangerous. With a little careless handling it is easy to lose a toe – or a leg. Whenever you are working with cipher suite configuration the old rule of 'measure twice, cut once' applies – and then double-check the work to be certain. There are several common pitfalls which await you. Misuse Perhaps the most common pitfall is simply misuse – using cipher suite configuration for that which it is not intended. And the single most common example of this comes from using cipher configuration to manipulate protocols. Given the keywords, as described above, it seems common for users to presume that if they want to disable a protocol, such as TLSv1.0, then the way to do that is to use a cipher suite keyword, such as !TLSv1. And, indeed, this may seem to work – but it isn't doing what is desired. The protocol is not disabled, only the ciphers that are supported for that protocol are. The protocol is configured on the VIP independently of the ciphers. !TLSv1 would disable all ciphers supported under the TLSv1.0 protocol, but not the protocol itself. Note that the protocol negotiation and the cipher negotiation in the SSL/TLS handshake are independent. What happens if the VIP only supports TLSv1.0/v1.1/v1.2 and the client only supports SSLv3 & TLSv1.0? Well, they'd agree on TLSv1.0 as the common protocol. The cipher list the client sends in the Client Hello is independent of the protocol that is eventually negotiated. Say the client sends AES128-SHA and the server has that in its list, so it is selected. OK, we've agreed on a protocol and a cipher suite – only the server won't do any ciphers on TLSv1.0 because of '!TLSv1' in the ciphers configuration, and the connection will fail. That may seem like splitting hairs, but it makes a difference. If a scanner is looking for protocols that are enabled, and not the full handshake, it may still flag a system which has been configured this way. The protocol is negotiated during the SSL/TLS handshake before the cipher is selected. This also means the system is doing more work, as the handshake continues further before failing, and the log messages may be misleading. Instead of logging a protocol incompatibility the logs will reflect the failure to find a viable cipher, which can be a red herring when it comes time to debug the configuration. The right way to do this is to actually disable the protocol, which doesn't involve the cipher suite configuration at all. For the control plane this is done through the ssl-protocol directive: tmsh list sys http ssl-protocol sys httpd { ssl-protocol "all -SSLv2 -SSLv3" } For example, if we wanted to disable TLSv1.0: tmsh modify sys http ssl-protocol 'all -SSLv2 -SSLv3 -TLSv1' tmsh list sys http ssl-protocol sys httpd { ssl-protocol "all -SSLv2 -SSLv3 -TLSv1" } For the data plane this can be done via the Options List in the SSL Profile GUI, via the No SSL, No TLSv1.1, etc. directives: Or via the command line: tmsh list ltm profile client-ssl Test options ltm profile client-ssl Test { options { dont-insert-empty-fragments } } tmsh modify ltm profile client-ssl Test options {dont-insert-empty-fragments no-tlsv1} tmsh list /ltm profile client-ssl Test options ltm profile client-ssl Test { options { dont-insert-empty-fragments no-tlsv1 } } The values are slightly different on the command line, use this command to see them all: tmsh modify ltm profile client-ssl <profile-name> options ? Use the right tool for the job and you'll be more likely to succeed. Truncation As I previously mentioned, in versions up to 11.5.0 the ciphers configuration string was truncated at 256 bytes. Starting in 11.5.0 that was increased to 768 bytes (see K11481: The SSL profile cipher lists have a 256 character limitation for more information), but that can still silently truncate long configurations. This is not a theoretical issue, we've seen users run into this in the real world. For example, little over a year ago I worked with a customer who was then using 11.4.1 HF8. They were trying to very precisely control which ciphers were enabled, and their order. In order to do this they'd decided to enumerate every individual cipher in their configuration – resulting in this cipher suite configuration string: TLSv1_2+ECDHE-RSA-AES256-CBC-SHA:TLSv1_1+ECDHE-RSA-AES256-CBC-SHA:TLSv1_2+ECDHE-RSA-AES128-CBC-SHA:TLSv1_1+ECDHE-RSA-AES128-CBC-SHA:TLSv1_2+DHE-RSA-AES256-SHA:TLSv1_1+DHE-RSA-AES256-SHA:TLSv1_2+DHE-RSA-AES128-SHA:TLSv1_1+DHE-RSA-AES128-SHA:TLSv1_2+AES256-SHA256:TLSv1_1+AES256-SHA:TLSv1_2+AES128-SHA256:TLSv1_1+AES128-SHA:TLSv1+ECDHE-RSA-AES256-CBC-SHA:TLSv1+ECDHE-RSA-AES128-CBC-SHA:TLSv1+DHE-RSA-AES256-SHA:TLSv1+DHE-RSA-AES128-SHA:TLSv1+AES256-SHA:TLSv1+AES128-SHA:TLSv1+DES-CBC3-SHA That string would save in the configuration and it was there if you looked at the bigip.conf file, but it was silently truncated when the configuration was loaded. Since this was 11.4.1, only the first 256 bytes were loaded successfully, which made the running configuration: TLSv1_2+ECDHE-RSA-AES256-CBC-SHA:TLSv1_1+ECDHE-RSA-AES256-CBC-SHA:TLSv1_2+ECDHE-RSA-AES128-CBC-SHA:TLSv1_1+ECDHE-RSA-AES128-CBC-SHA:TLSv1_2+DHE-RSA-AES256-SHA:TLSv1_1+DHE-RSA-AES256-SHA:TLSv1_2+DHE-RSA-AES128-SHA:TLSv1_1+DHE-RSA-AES128-SHA:TLSv1_2+AES256-S Note the last suite is truncated itself, which means it was invalid and therefore ignored. If their configuration had worked they would've had nineteen protocol+suite combinations – instead they had eight. Needless to say, this caused some problems. This customer was missing ciphers that they expected to have working. That is bad enough – but it could be worse. Let's imagine a customer who wants to specify several specific ciphers first, then generally enable a number of other TLSv1.2 & TLSv1.1 ciphers. And, of course, they are careful to disable dangerous ciphers! TLSv1_2+ECDHE-RSA-AES256-CBC-SHA:TLSv1_1+ECDHE-RSA-AES256-CBC-SHA:TLSv1_2+ECDHE-RSA-AES128-CBC-SHA:TLSv1_1+ECDHE-RSA-AES128-CBC-SHA:TLSv1_2+DHE-RSA-AES256-SHA:TLSv1_1+DHE-RSA-AES256-SHA:TLSv1_2+DHE-RSA-AES128-SHA:TLSv1_1+DHE-RSA-AES128-SHA:TLSv1_2:TLSv1_1:!RC4:!MD5:!ADH:!DES:!EXPORT OK, that looks fairly solid, right? What do you suppose the problem with this is? This is the problem; in 11.4.1 and earlier it would truncate to this: TLSv1_2+ECDHE-RSA-AES256-CBC-SHA:TLSv1_1+ECDHE-RSA-AES256-CBC-SHA:TLSv1_2+ECDHE-RSA-AES128-CBC-SHA:TLSv1_1+ECDHE-RSA-AES128-CBC-SHA:TLSv1_2+DHE-RSA-AES256-SHA:TLSv1_1+DHE-RSA-AES256-SHA:TLSv1_2+DHE-RSA-AES128-SHA:TLSv1_1+DHE-RSA-AES128-SHA:TLSv1_2:TLSv1_1: All of the exclusions were truncated off! Now we have the opposite problem – there are a number of ciphers enabled which the customer expects to be disabled! And they're BAD ciphers – ADH, DES, MD5, RC4. So this customer would be at high risk without realizing it. Be aware of this; it is very sneaky. The configuration will look fine; the truncation happens in the code when it loads the configuration. This is also one reason why I always recommend listing your exclusions first in the configuration string. Then you can never accidentally enable something. Unintended Consequences Let's say a new CVE is announced which exposes a very serious vulnerability in SSLv3 & TLSv1.0. There is no way to mitigate it, and the only solution is to limit connections to only TLSv1.1 & TLSv1.2. You want a cipher configuration to accomplish this. It seems straight-forward – just configure it to use only ciphers on TLSv1.1 & TLSv1.2: tmsh modify ltm profile client-ssl <profile> ciphers 'TLSv1_2:TLSv1_1' Congratulations, you've solved the problem. You are no longer vulnerable to this CVE. You know there is a but coming, right? What's wrong? Well, you just enabled all TLSv1.2 & TLSv1.1 ciphers. That includes such gems as RC4-MD5, RC4-SHA, DES, and a few ADH (Anonymous Diffie-Hellman) suites which have no authentication. As recently as 11.3.0 you'd even be enabling some 40-bit EXPORT ciphers. (We pulled them out of NATIVE in 11.4.0.) So you just leapt out of the frying pan and into the fire. Always, always, always check the configuration before using it. Running that through tmm --clientciphers 'TLSv1_2:TLSv1_1' would've raised red flags. Instead, this configuration would work without causing those problems: tmsh modify ltm profile client-ssl <profile> ciphers 'DEFAULT:!TLSv1:!SSLv3' Another option, and probably the better one, is to disable the SSLv3 and TLSv1.0 protocols on the VIP. As I discussed above. Of course, you can do both – belt and suspenders. And just to show you how easy it is to make such a mistake, F5 did this! In K13400: SSL 3.0/TLS 1.0 BEAST vulnerability CVE-2011-3389 and TLS protocol vulnerability CVE-2012-1870 we originally had the following in the mitigation section: Note: Alternatively, to configure an SSL profile to use only TLS 1.1-compatible, TLS 1.2-compatible, AES-GCM, or RC4-SHA ciphers using the tmsh utility, use the following syntax: tmsh create /ltm profile client-ssl <name> ciphers TLSv1_1:TLSv1_2:AES-GCM:RC4-SHA Yes, I had this fixed long ago. Remember back in the section on keywords I had this comparison example: tmm --clientciphers 'DEFAULT' tmm --clientciphers 'DEFAULT:-3DES:!SSLv3:3DES+ECDHE:3DES+DHE:3DES+RSA' Who caught the '!SSLv3' in the second line? Why do you think I added that? Did I need to? Hint: What do you think the side effect of blanket enabling all of those 3DES ciphers would be if I didn't explicitly disable SSLv3? Cipher Ordering In SSL/TLS there are two main models to the cipher suite negotiation – Server Cipher Preference or Client Cipher Preference. What does this mean? In SSL/TLS the client sends the list of cipher suites it is willing and able to support in the Client Hello. The server also has its list of cipher suites that it is willing and able to support. In Client Cipher Preference the server will select the first cipher on the client's list that is also in the server's list. Effectively this gives the client influence over which cipher is selected based on the order of the list it sends. In Server Cipher Preference the server will select the first server on its own list that is also on the client's list. So the server gives the order of its list precedence. BIG-IP always operates in Server Cipher Preference, so be very careful in how you order your cipher suites. Preferred suites should go at the top of the list. How you order your cipher suites will directly affect which ciphers are used. It doesn't matter if a stronger cipher is available if a weak cipher is matched first. HTTP/2 How is HTTP/2 a pitfall? The HTTP/2 RFC7540 includes a blacklist of ciphers that are valid in TLS, but should not be used in HTTP/2. This can cause a problem on a server where the TLS negotiation is decoupled from the ALPN exchange for the higher level protocol. The server might select a cipher which is on the blacklist, and then when the connection attempts to step up to HTTP/2 via ALPN the client may terminate the connection with extreme prejudice. It is well known enough to be called out in the RFC – Section 9.2.2. F5 added support for HTTP/2 in 12.0.0 – and we fell into this trap. Our DEFAULT ciphers list was ordered such that it was almost certain a blacklisted cipher would be selected.; This was fixed in 12.0.0 HF3 and 12.1.0, but serves as an example. On 12.0.0 FINAL through 12.0.0 HF2 a simple fix was to configure the ciphers to be 'ECDHE+AES-GCM:DEFAULT'. ECDHE+AES-GCM is guaranteed to be supported by any client compliant with RFC7540 (HTTP/2). Putting it first ensures it is selected before any blacklisted cipher. 3DES Back in the section on ciphers I mentioned that we label 3DES as being 168-bit, but that it only provides the equivalent of 112-bit strength. So, what did I mean by that? DES operates on 64-bit data blocks, using 56-bits of key. So it has a strength of 2 56 . 3DES, aka Triple DES, was a stop-gap designed to stretch the life of DES once 56-bits was too weak to be safe, until AES became available. 3DES use the exact same DES cipher, it just uses it three times – hence the name. So you might think 3x56-bits = 168-bits. 2 168 strong. Right? No, not really. The standard implementation of 3DES is known as EDE – for Encrypt, Decrypt, Encrypt. (For reasons we don't need to get into here.) You take the 64-bit data block, run it through DES once to encrypt it with K 1 , then run it through again to decrypt it using K 2 , then encrypt it once again using K 3 . Three keys, that's still 168-bits, right? Well, you'd think so. But the devil is in the (implementation) details. First of all there are three keying options for 3DES: - Keying option 1: K1, K2, K3 – 168 unique bits (but only 112-bit strength!) - Keying option 2: K1, K2, K1 – 112 unique bits (but only 80-bit strength!) - Keying option 3: K1, K1, K1 – 56 unique bits, 56-bit strength (Equivalent to DES due to EDE!) F5 uses keying option one, so we have 168-bits of unique key. However, 3DES with keying option one is subject to a meet-in-the-middle cryptographic attack which only has a cost of 2 112 . It has even been reduced as low as 2 108 , as described in this paper. So it does not provide the expected 168-bits of security, and is in fact weaker than AES128. To add some confusion, due to an old issue we used to describe 3DES as being 192-bit. See: K17296: The BIG-IP system incorrectly reports a 192-bit key length for cipher suites using 3DES (DES-CBC3) for more details. Of course, with the appearance of the Sweet32 attack last fall I would encourage everyone to disable 3DES completely whenever possible. We're also seeing a growing number of scanners and audit tools recategorizing 3DES as a 'Medium' strength cipher, down from 'High', and correspondingly lowering the grade for any site still supporting it. If you don't need it, turn it off. See K13167034: OpenSSL vulnerability CVE-2016-2183 for more information. Conclusion Believe it or not, that's the quick overview of cipher suite configuration on BIG-IP. There are many areas where we could dig in further and spend some time in the weeds, but I hope that this article helps at least one person understand cipher suite configuration better, and to avoid the pitfalls that commonly claim those who work with them. Additional Resources This article is by no means comprehensive, and for those interested I'd encourage additional reading: BIG-IP SSL Cipher History by David Holmes, here on DevCentral Cipher Rules And Groups in BIG-IP v13 by Chase Abbott, also on DevCentral OpenSSL Cipher Documentation K8802: Using SSL ciphers with BIG-IP Client SSL and Server SSL profiles K15194: Overview of the BIG-IP SSL/TLS cipher suite K13163: SSL ciphers supported on BIG-IP platforms (11.x - 12.x) K13156: SSL ciphers used in the default SSL profiles (11.x - 12.x) K17370: Configuring the cipher strength for SSL profiles (12.x) K13171: Configuring the cipher strength for SSL profiles (11.x) K14783: Overview of the Client SSL profile (11.x - 12.x) K14806: Overview of the Server SSL profile (11.x - 12.x)Cipher Rules And Groups in BIG-IP v13
My mother used to always tell me two things before I left for school in the morning. Be wary of what ciphers your application supports Never use the Default cipher list unless you have compatibility concerns You may have had a different upbringing from me but my mom's lessons still apply to anyone using SSL/TLS enabled systems. We know from Señor Wagnon's Security Sidebar: Improving Your SSL Labs Test Grade how cumbersome modifying lengthy cipher strings can be to keep your SSL Labs A grade. We know as BIG-IP matures we update the DEFAULT cipher list to remove deprecated entries and introduce fancy new ones. This causes negative affects on those legacy applications we like to keep lying around. Lastly, we know that not everyone appreciates meditating in SSH sessions; pondering countless tmm --clientciphers commands to figure out what cipher string they'll need in order to get achieve an SSL Labs A+ grade. We have a solution for you. Cipher Rules & Groups BIG-IP version 13 introduces Cipher Rules & Groups; an alternate way to visualize, organize, and apply cipher suites to your client and ssl profiles. You still need a basic understanding of cipher strings and I recommend you review Megazone's article: Cipher Suite Practices and Pitfallsarticle before gallivanting through Cipher Rules & Groups; you'll stub a toe. Cipher rules and the subsequent groups that contain them allow the same boolean operators used in tmm cipher strings. Boolean Operations in Cipher Groups UNION = Allow the following: INTERSECT = Restrict the Allowed List to the following: DIFFERENCE =Exclude the following from the Allowed List: F5 includes 5 default cipher rules and applies them via 5 default cipher groups of the same name (included is the tmm command to view each cipher list used): f5-aes = tmm --clientciphers AES f5-default = tmm --clientciphers DEFAULT f5-ecc = tmm --clientciphers ECDHE:ECDHE_ECDSA f5-secure = tmm --clientciphers ECDHE:RSA:!SSLV3:!RC4:!EXP:!DES f5-hw_keys = tmm --clientciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-CBC-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DHE-RSA-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-CBC-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:RC4-SHA:RC4-MD5:DHE-RSA-DES-CBC-SHA:DHE-RSA-CAMELLIA256-SHA:CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:!TLSv1:!TLSv1_1:!SSLv3:!DTLSv1 The last one related to HSM ciphers was crazy long wasn't it. This is why we built cipher rules and groups; to prevent you from banging your head on the table because you got the operand wrong somewhere after ECDHE-RSA-AES128-GCM-SHA256. The F5 provided rules and groups are read-only and should used as a reference or starting template. If you rely only on the default F5 cipher rules/groups they will change as our cryptographic requirements change and you could end up with a bunch of incompatible legacy clients. Building A Cipher Rule Because Cipher Rules and Groups are applied to SSL Profiles, you can find them under Local Traffic in the web GUI. Clicking into Local Traffic => Ciphers gives you two options: Cipher Rules and Cipher Groups. I'll create one Cipher Rule based on tmm cipher string ALL:SSLv3:EXPORT. This is only for display purposes to better illustrate the boolean operations when we build the Cipher Group. Current ciphers based on BIG-IP version and Hotfix are listed in the NATIVE cipher list. Remember, we have to support a lot of ciphers that may not be appropriate for public consumption. Building Cipher Groups Now we'll build a Cipher Group starting with the chase_all Cipher Rule, because we're gluttons for punishment. Clicking the + expands the ciphers allowed under each Cipher Rule. Adding it to the "Allow the following" element, the Cipher Audit element below will automatically update to reflect the ciphers this group will provide the Client or Server Profile. Remember, anything added in that window is performing a Boolean Union operation. Adding the f5-aes Cipher Rule to the "Restrict the Allowed List to the following:" element which will reduce the chase_all cipher list to only ciphers common to both ALL:SSLv3:EXPORT and AES lists; performing a Boolean Intersection operation. The Cipher Audit element shows the results and we can see those pesky RC4-MD5 suites from EXPORT are gone, but ew... we have some SSLv3-enabled ciphers and we want those out. I'll create a new Cipher Rule called chase_sslv3 with the cipher string only being SSlv3. I'll add this new Cipher Rule to the "Exclude the following from the Allowed List:"; performing a Boolean Difference operation. We can also change the cipher sorting based on speed, strength, FIPS, or hardware accelerated via the Order dropdown. Ahh.... better, now we've paired down a horribly insecure cipher list with the intersection of the AES ciphers and exclusion of the SSlv3s. Yea, we could have started with the AES Cipher Rule as the base list but that's not as fun for this demonstration. The lifecycle of a BIG-IP SSL profile requires active management of cipher suites. This demo illustrates the flexability of additive/subtractive cipher management which reduces the complexity of recreating the wheel every time someone nullifies the security of existing algorithms or hash functions. Applying Cipher Groups to Client/Server Profiles Open an SSL Client or Server Profile and change the configuration to advanced. The cipher list becomes available and is defaulted to a Cipher String. Now you have a radio button for Cipher Group, selecting the newly created object or click the + button to create one from scratch. TMSH Support for Cipher Rules and Groups We have support for tmsh commands so you can take advantage of adding cipher groups to existing profiles. # tmsh list ltm cipher rule f5-secure all-properties ltm cipher rule f5-secure { app-service none cipher ECDHE:RSA:!SSLV3:!RC4:!EXP:!DES description "Cipher suites that maximize regulatory compliance." partition Common } # tmsh show ltm cipher rule f5-secure ----------------- Ltm::Cipher::Rule ----------------- Name Result ----------------- f5-secure ECDHE-RSA-AES128-GCM-SHA256/TLS1.2:ECDHE-RSA-AES128-CBC-SHA/TLS1.0:ECDHE-RSA-AES128-CBC-SHA/TLS1.1:ECDHE-RSA-AES128-CBC-SHA/TLS1.2:ECDHE-RSA-AES128-SHA256/TLS1.2:ECDHE-RSA-AES256-GCM-SHA384/TLS1.2:ECDHE-RSA-AES256-CBC-SHA/TLS1.0:ECDHE-RSA-AES256-CBC-SHA/TLS1.1:ECDHE-RSA-AES256-CBC-SHA/TLS1.2:ECDHE-RSA-AES256-SHA384/TLS1.2:ECDHE-RSA-DES-CBC3-SHA/TLS1.0:ECDHE-RSA-DES-CBC3-SHA/TLS1.1:ECDHE-RSA-DES-CBC3-SHA/TLS1.2:AES128-GCM-SHA256/TLS1.2:AES128-SHA/TLS1.0:AES128-SHA/TLS1.1:AES128-SHA/TLS1.2:AES128-SHA/DTLS1.0:AES128-SHA256/TLS1.2:AES256-GCM-SHA384/TLS1.2:AES256-SHA/TLS1.0:AES256-SHA/TLS1.1:AES256-SHA/TLS1.2:AES256-SHA/DTLS1.0:AES256-SHA256/TLS1.2:CAMELLIA128-SHA/TLS1.0:CAMELLIA128-SHA/TLS1.1:CAMELLIA128-SHA/TLS1.2:CAMELLIA256-SHA/TLS1.0:CAMELLIA256-SHA/TLS1.1:CAMELLIA256-SHA/TLS1.2:DES-CBC3-SHA/TLS1.0:DES-CBC3-SHA/TLS1.1:DES-CBC3-SHA/TLS1.2:DES-CBC3-SHA/DTLS1.0 # tmsh list ltm cipher group chases_cipher_group all-properties ltm cipher group chases_cipher_group { allow { chase_all { } } app-service none description "MY CIPHERS ARE THE BEST CIPHERS" exclude { chase_sslv3 { } } ordering default partition Common require { f5-aes { } } } # tmsh show ltm cipher group chases_cipher_group --------------------------- Ltm::Cipher::Group --------------------------- Name Result --------------------------- chases_cipher_group ECDHE-RSA-AES128-CBC-SHA/TLS1.0:ECDHE-RSA-AES128-CBC-SHA/TLS1.1:ECDHE-RSA-AES128-CBC-SHA/TLS1.2:ECDHE-RSA-AES128-SHA256/TLS1.2:ECDHE-RSA-AES256-CBC-SHA/TLS1.0:ECDHE-RSA-AES256-CBC-SHA/TLS1.1:ECDHE-RSA-AES256-CBC-SHA/TLS1.2:ECDHE-RSA-AES256-SHA384/TLS1.2:ECDH-RSA-AES128-SHA256/TLS1.2:ECDH-RSA-AES128-SHA/TLS1.0:ECDH-RSA-AES128-SHA/TLS1.1:ECDH-RSA-AES128-SHA/TLS1.2:ECDH-RSA-AES256-SHA384/TLS1.2:ECDH-RSA-AES256-SHA/TLS1.0:ECDH-RSA-AES256-SHA/TLS1.1:ECDH-RSA-AES256-SHA/TLS1.2:AES128-SHA/TLS1.0:AES128-SHA/TLS1.1:AES128-SHA/TLS1.2:AES128-SHA/DTLS1.0:AES128-SHA256/TLS1.2:AES256-SHA/TLS1.0:AES256-SHA/TLS1.1:AES256-SHA/TLS1.2:AES256-SHA/DTLS1.0:AES256-SHA256/TLS1.2:ECDHE-ECDSA-AES128-SHA/TLS1.0:ECDHE-ECDSA-AES128-SHA/TLS1.1:ECDHE-ECDSA-AES128-SHA/TLS1.2:ECDHE-ECDSA-AES128-SHA256/TLS1.2:ECDHE-ECDSA-AES256-SHA/TLS1.0:ECDHE-ECDSA-AES256-SHA/TLS1.1:ECDHE-ECDSA-AES256-SHA/TLS1.2:ECDHE-ECDSA-AES256-SHA384/TLS1.2:ECDH-ECDSA-AES128-SHA/TLS1.0:ECDH-ECDSA-AES128-SHA/TLS1.1:ECDH-ECDSA-AES128-SHA/TLS1.2:ECDH-ECDSA-AES128-SHA256/TLS1.2:ECDH-ECDSA-AES256-SHA/TLS1.0:ECDH-ECDSA-AES256-SHA/TLS1.1:ECDH-ECDSA-AES256-SHA/TLS1.2:ECDH-ECDSA-AES256-SHA384/TLS1.2:DHE-RSA-AES128-SHA/TLS1.0:DHE-RSA-AES128-SHA/TLS1.1:DHE-RSA-AES128-SHA/TLS1.2:DHE-RSA-AES128-SHA/DTLS1.0:DHE-RSA-AES128-SHA256/TLS1.2:DHE-RSA-AES256-SHA/TLS1.0:DHE-RSA-AES256-SHA/TLS1.1:DHE-RSA-AES256-SHA/TLS1.2:DHE-RSA-AES256-SHA/DTLS1.0:DHE-RSA-AES256-SHA256/TLS1.2:DHE-DSS-AES128-SHA/TLS1.0:DHE-DSS-AES128-SHA/TLS1.1:DHE-DSS-AES128-SHA/TLS1.2:DHE-DSS-AES128-SHA/DTLS1.0:DHE-DSS-AES128-SHA256/TLS1.2:DHE-DSS-AES256-SHA/TLS1.0:DHE-DSS-AES256-SHA/TLS1.1:DHE-DSS-AES256-SHA/TLS1.2:DHE-DSS-AES256-SHA/DTLS1.0:DHE-DSS-AES256-SHA256/TLS1.2:ADH-AES128-SHA/TLS1.0:ADH-AES256-SHA/TLS1.0 # tmsh list ltm profile client-ssl chases_ssl_client_profile ltm profile client-ssl chases_ssl_client_profile { app-service none cert default.crt cert-key-chain { default { cert default.crt key default.key } } chain none cipher-group chases_cipher_group ciphers none defaults-from clientssl inherit-certkeychain true key default.key passphrase none } # tmsh list ltm profile server-ssl chases_ssl_server_profile ltm profile server-ssl chases_ssl_server_profile { app-service none cipher-group chases_cipher_group ciphers none defaults-from serverssl } Validating Your Ciphers With NMAP A lot of users are not always comfortable with how we output our cipher lists. NMAP provides a user-preferred display using the ssl-enum-ciphers script. In this case, we'll check out SSL Labs web server's ciphers. Run the following: $ nmap -Pn -sT www.ssllabs.com -p 443 --script ssl-enum-ciphers Starting Nmap 6.40 at 2017-02-24 11:22 PST Nmap scan report for www.ssllabs.com (64.41.200.100) Host is up (0.035s latency). PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | SSLv3: No supported ciphers found | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | compressors: | NULL | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | compressors: | NULL | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | compressors: | NULL |_ least strength: strong Nmap done: 1 IP address (1 host up) scanned in 2.73 seconds Hopefully this overview and mini-demo got you pondering how you can improve cipher management in your infrastructure. As the crypto world discovers new ways to compromise math, we have to keep on our toes more than ever. Google Research and CWI Amsterdam just published the first real world hash collision for SHA-1 proving we need to stay informed. The idea is simple, create Cipher Rules based on your needs and reuse them against application or security policy-centric Cipher Groups. Segregating Cipher management from Client and Server SSL Profiles creates a more flexibility for application owners and should reduce the cipher string headache every time there's a new vulnerability. Drop us a line on your thoughts and let us know if we're going down the right path or if ther are other things you wish to see related to cipher management. Keep it real.Introducing the F5 Security Incident Response Team (F5 SIRT)
When your business is facing a security crisis, F5 has a team dedicated to helping you through it – the F5 Security Incident Response Team (F5 SIRT). During a security incident, the F5 SIRT engages rapidly with the resources you need to respond. The F5 SIRT also evaluates potential and published vulnerabilities and provides timely alerts to help you manage risks and deploy mitigation – before an attack brings down your business. Dedicated to quickly and effectively mitigating attacks and vulnerabilities to get your operations back to business as usual, this focused team of expert F5 security engineers, available globally and 24/7, applies passion and a proven process to mitigate new attacks, manage investigations, and help you address any vulnerabilities related to F5 products and services. Backed by extensive F5 insight and security experience, the F5 SIRT works with you to immediately address issues and enhance your protection going forward. The F5 SIRT works to protect your user identities, applications, corporate assets, and customer data. The team’s engineers coordinate with other F5 groups to develop ready-to-deploy technical countermeasures, share them with you, and help you put them in place. But the response doesn’t stop when the attack does; the team looks beyond the reported incident to reduce the overall harm to your organization, as well as understand, anticipate, and deter future threats. The F5 SIRT is composed of experienced security engineers who are well-versed in a broad range of security threats and incident handling methodologies and backed by the full F5 organization. The F5 SIRT follows industry-standard incident response methodologies and adheres to the ISO 9001-certified F5 Quality Management System, including the creation of procedures to drive mitigation of security incidents, attack analysis, vulnerability response, and reporting. How do I engage the F5 SIRT? Customers primarily engage the F5 SIRT via the Emergency Security Response Process (ESRP). The ESRP is designed to bring the appropriate resources to bear on your security emergency, quickly; getting your operations back to business as usual. The ESRP may be triggered by any F5 customer with a valid support agreement: simply inform the F5 support representative that you’re experiencing a security related emergency, such as an ongoing attack, when opening a case. The F5 support representative will invoke the ESRP to engage the most appropriate resources to address your issue, including the F5 SIRT. The reality of the Internet today is that every connected network could be attacked at any time. No one wants it to happen to them, but if it does you want experienced professionals in your corner, ready to work with you. The ESRP establishes standardized procedures and guidelines for F5 support to provide you with the most effective emergency response, bringing F5’s resources to bear when you need them most. You may also benefit from the work of the F5 SIRT by signing up for the F5 Security Alerts. The F5 SIRT is also involved in the creation of many of the Security Advisories published on AskF5. You may wish to create an RSS feed for new and updated security advisories so you’re always up to date on the latest notices from F5. Additionally, if you discover any potential security issues or vulnerabilities relating to F5 products or services, we encourage you to report them. We recommend that existing F5 customers do so by opening a support case through normal channels. For those who are not existing F5 customers, such as security researchers, we ask that you follow responsible disclosure and email the F5 SIRT at F5SIRT@f5.com. We’ll respond to arrange a secure communications channel, and investigate immediately. For more information, see our Vulnerability Policy. The security and availability of customer and company data are critical. But in the constantly evolving threat landscape, even the most well-planned infrastructure cannot protect against every attacker. When network or application security incidents occur, F5 will be there to help you.Getting Started with AFM
tl;dr - BIG-IP AFM is a stateful firewall solution available on BIG-IP infrastructure targeted for datacenter traffic protection. The BIG-IP Advanced Firewall Manager (AFM) is a high-performance, stateful, full-proxy network security solution designed to guard against incoming threats that enter the network on the most widely deployed protocols. It’s an industry leader in network protection, and one of its most impressive features is the scalability it can handle. It leverages the high performance and flexibility of F5's TMOS architecture in order to provide large data center scalability features that take second place to no one. In this article, we’ll cover the nomenclature and architectural components of the AFM module. A little history The truth is, BIG-IP has always had firewall features built-in. By nature, it is a default deny device. The only way to pass traffic through the BIG-IP is through a virtual server, which is an ip and a port. That ip could be 0.0.0.0/0 and that port could be 0, and thus you are allowing all IPs and all protocols, but that still is a configuration choice you made, not a default behavior of the BIG-IP. So given that a) the BIG-IP is already making the decision to allow or deny traffic based on virtual servers, and b) the capacity is far greater than most traditional network firewalls can handle, why not take the necessary steps to achieve certification as a firewall and give customers an opportunity to eliminate a layer of infrastructure for inbound application services? And thus AFM was born (David Holmes had a great story about the origins in our roundtable last year.) But it was more than just slapping on a brand name and calling it a day. Some things had to happen to make this viable for the majority of customers. A couple show stoppers that are obvious firewall functions are a solid logging solution and an adequate rule building interface. Logging Any good firewalling function needs logs. What else will Mr 1983 here to the right have to do all night in his mom’s basement if he didn’t have logs to parse? Seriously though, without logs, how could you determine what is being blocked, and more important, what isn’t that should be? And in the event of a compromise, the information to properly handle the incident response. BIG-IP’s high speed logging (HSL) functionality had been around for a while but it was enhanced over time to have a robust interface from several of the system modules. All the sources, formats, publishers, and destinations are configurable, and what’s cool about the interface is the pool functionality, so logs can be sprayed across a collection cluster so no one server is responsible for being 100% available. Follow the rules! It’s all about context.. For rule building, some underlying infrastructure had to change. The flexibility of BIG-IP allows for all services to be configured at a virtual server level, but that may not always be desired. So a global context was added to handle policy decisions at a system level. Just below the global context is the route domain. This level of separation allows administrators to have unique policies by route domain, segmenting strategically at routing boundaries for use cases like tenant deployments. Within the route domain, context rules can be applied to virtual servers and self IPs. During packet processing, AFM attempts to match the packet contents to criteria specified in its active security rules. These rules are maintained in a hierarchical context. Rules can be global and apply to all addresses on the BIG-IP that match the rule, or they can be specific, applying only to a specific route domain, virtual server, self-IP, or the management port. The first context list of rules a packet passes through are the Global rules. If a packet matches a rule's criteria, then the system takes the action specified. If a packet does not match a rule, then the system compares the packet against the next rule, continuing through the context hierarchy and checking, as appropriate, rules relating to route domains, virtual servers, self-IPs, and the management port. If no match is found, the packet is dropped by the default deny rule. This fall-through is shown well here: The Object Model Several sets of database tables have been created to support AFM rules. For each collection, a table set exists for each type of container. There is a table for global rules, virtual IP rules, self IP rules and management IP rules. There is a table for source addresses for global rules as well as a table for source addresses for virtual server rules. But each table essentially contains the same information, with keys that point at different parent containers. Instead of jamming everything into one table, normalization is done based on the type of parent configuration object that contains rules. The classification module has two components: a compiler that generates a classifier in compiled form from configuration directives, and a classification engine that uses the compiled classifier to determine the set of rules matching a packet based on the packet contents and other relevant inputs. The compiler resides in the control plane and the classification engine resides in the packet processing path, as part of the TMM process. Objects that use the classifier are: Whitelists Blacklists SYN-cookies Rate limiters iRules L4-7 signatures ACLs From a configuration perspective, the following containers of security rules are supported: Global Rules: global rules affect all traffic except for traffic on the management interface. There is only one container object for global rules, and this is the first rule set that a packet is processed against. Context Rules: context rules include rules for self-IP, virtual servers, route domains, SNATs and NATs, and management IP. Note that the management interface is not controlled by TMM, therefore it is handled by iptables in the Linux kernel. There can be multiple container objects for context rules since these rules are applied to specific objects and not globally. Rule Lists are collections of rules that can be referred to by any of the other rule containers listed here. Nesting of rule groups is not supported, and a rule group may not refer to another rule group. Also, a rule group is path/folder aware. Packet flow The packet flow is hinted at in the context section above, but for clarity this is a better visualization. There isanother version of this drawingwith even more details which we based one of our Whiteboard Wednesday’s on last year. Deployment modes The first mode is ADC mode. This enforcement mode implicitly allow configured virtual server traffic while all other traffic is blocked. In ADC mode the source and destination settings of each virtual server (and self IP) imply corresponding firewall rules. The second is firewall mode. This enforcement mode is a strict default deny configuration. All traffic is blocked through BIG-IP AFM, and any traffic you want to allow through must be explicitly configured in the security rules. On top of these two operation modes there exists a global default. The purpose of the global default is to deny traffic which does not match listener. The global default can not be changed. You must configure explicit rules to allow traffic. But Wait, There's More! We've covered some of the core functionality that needed to be enhanced, but what other surprises are up the AFM's sleeve? No rabbits, but the AFM is chock-full of useful features, including: Bad actor blacklisting IP reputation automation iRules extensions DNS firewall DDoS capabilities FQDN support in ACL rules ACL flow idle timeout UDP flood protection We will be working on more articles in the near future to futher flesh out the feature list in AFM. Conclusion The AFM is quite a powerful security tool to wield for your inbound application services. Hopefully this article has been helpful in breaking down some nomenclature and architecture on the product, and whet your appetite for more firewall goodness. There is a lot more to come in this series, which you can link to from the article listing below.
CloudBleed: Guess What? There was 0-day protection
About CloudBleed If you aren’t familiar with CloudBleed, take a moment to read the following articlesto get an understanding how it was found, what happened, and what PII/PCI data was (possibly) leaked: Vulnerability Disclosure from Tavis Ormandy (@taviso), a security researcher at Google Incident Response from CloudFlare 3rd party assessment from Ryan Lackey (@octal) In some of the examples shown by Tavis, or by digging into cached sites on less popular search engines, you can see how usernames, passwords, sessions, credit card info, etc could be seen in clear text despite the use of HTTPS (TLS1.2). A simplification of the flow would look like this: Request: Client >=====> CloudFlare >=====> Origin Web Server Response: Client <=====< CloudFlare <=====< Origin Web Server Despite the fact that the client is utilizing HTTPS, CloudFlare has the ability to terminate the secure connection since it has the private key. This is essentially the content (PII or PCI) that was being cached if certain conditions occurred on the CloudFlare reverse proxy. 0-day Protection Against CloudBleed So, what is the 0-day protection and what is it all about? Application Layer Encryption is a feature from F5 that would have left researchers scratching their heads when looking at the cached content. First things first, let’s dynamically encrypt sensitive parameter names using Application Layer Encryption. But really, what does that mean? Let’s take a deeper look. In all examples I will be using Google Chrome. Let’s say you have login pagewithoutApplication Layer Encryption. If I were to right click on the Password box and choose Inspect, I would see something like this: As you can see from the red boxes, the parameters for my username and password arelogandpwd. We can all agree that this is in human readable format (HRF). If I were to do the exact same thingwithApplication Layer Encryption, I would see this: In the screen shot above there are 3things I would like to focus your attention on: Both name=log and name=pwd are no longer in HRF. Notice in the first red box that there is a slight purple hue over the value? That’s the dynamic part of Application Layer Encryption. Every few seconds the valueswill change. This is done on the client side, not the server side. That value will never repeat and is completely unique to the user’s session. We also removed the element IDs, id=”user_login” and id=”user_pass”. With Application Layer Encryption turned on, every user will have a unique value for name=log and name=pwd moving forward. We can also turn upthe security a notch by inserting decoy fields to further confuse the bad guys. Decoy fields are only seen in the raw code and do not change the end users experience. As you can see above, there are additional IDs which makes it very difficult to pull apart in a replay attack. But Brian, what about the values being sent!?!!? Let’s look at a data submissionwithoutApplication Layer Encryption from the browservia the network tools in Chrome: As you can see from the picture above, the username is briandeitch and the password is test. Although this is sent via HTTPS, CloudFlare has the private key and this is the type of data that could have been cached by search engines. Yikes! Same exercise but this timewithApplication Layer Encryption: Decoy fields turned off: Decoy fields turned on: As you can see from the form data, both the parameter names and values have been dynamically encrypted on the client side. Let’s say this data was leaked by CloudFlare and cached by a search engine. Couple of points: These substituted and encrypted values are single use, meaning a replay attack wouldn’t work. Good luck reverse engineering any of this. Application Layer Encryption uses private/public key technology and this key, unlike the private key for the SSL Certificate, isn’t hosted on CloudFlare. This means the payload (form data shown above, you know the values for the username and password) is completely encrypted to CloudFlare (or any other proxy for that matter). In addition, the decoy fields are sent as well. Good luck deciphering which fields are mapped to the actual application(s). Personally, my favorite part ofApplication Layer Encryption is that is requires no change to my back end application. This solution requires no installation or modification to the end users web browser, is 100% client-less, and transparent to the end user. At the end of the day, you can still rely on HTTPS for transport layer security however Application Layer Encryption steps up your overall security posture by using cleverobfuscation andencryption to protect your datawhen there is a proxy (MITM device) between your customers andapplication(s). Lastly,Application Layer Encryption is a feature within F5 WebSafe. F5 has taken a complex security enhancement and created a point and click solution to easily protect your application(s). Configuring Application Layer Encryption Step 1: By creating a profile, specify the URIs you want protected. *Note: You are able to use wildcard URIs as well. Step 2: Add theparameters you want protected. The Encrypt checkbox is how we secure the username and password valuesthat are being sent. By encrypting the values, this will prevent replay attacks as the values can only be used once. TheSubstitute Value checkboxsubstitutes the parameter’s value with a random value in the web application while the form is being filled. This also prevents browser based malware fromcapturing keystrokes as they are being entered. The Obfuscatecheckbox encrypts the parameter’s name attribute. Step 2a: If you would like to insert decoy fields to further mess with the bad guys, you don’t have to be a rocketscientist. Relax, it is just a checkbox. Step 3: Associate the new profile to theapplication. That’s it! You have successfully configured and secured your application with Application Layer Encryption. Special thanks to BAM, Todd Morton, Chad Fazio, Jeffery McFerson, Joe Martin, and Ted Byerly for their contributions on this article.Encrypted malware vs. F5's full proxy architecture
Everyone knows that malware is a huge problem, and several recent studies (including one by our very own F5 Labs research center) have shown that nearly half of all malware is now encrypted. So, if all this malware is encrypted, then how do you go about finding it and stopping it if you can't even read it? This problem is critical to the security of web applications today and will be even more critical in the future as encrypted Internet traffic becomes more pervasive. There are two basic scenarios in which to categorize this situation: 1) inbound encrypted malware, and 2) outbound encrypted malware. What I'm calling "inbound" encrypted malware is when an attacker sends malicious traffic to your webserver in order to infect the server and/or a user accessing that server. The "outbound" encrypted malware is when a user in your organization visits an infected website and ultimately infects his/her computer with the malware from that infected site. Admittedly, the "outbound" encrypted malware situation is a huge problem and needs to be addressed, but for the purposes of this article, we will look at the "inbound" malware problem. When you configure a secure webserver (one that uses encryption), you have to generate and store the keys that are used for encryption. Those keys can be stored on the webserver itself, or they can be stored on a separate proxy device. Many organizations choose to use a proxy device because it is typically custom-built to handle cryptography operations much faster than standard webservers. This "handing off" of the crypto keys is called SSL offload. F5's BIG-IP is the best in the business at this. I won't go into all the marketing chatter about it, but suffice it to say, the BIG-IP is really, really good and fast at this. The SSL offload not only provides a faster encryption experience, but it also allows for a strategic point of control over your web traffic. The F5 BIG-IP also employs a full proxy architecture that allows full visibility of every single request to your web applications. When a user sends an HTTP request to your web application, the BIG-IP accepts that request on behalf of your webserver (in fact, the end user thinks he is talking directly to the webserver but he's really talking to the BIG-IP) and then tears down the request from layer 7 all the way down to layer 1 and then rebuilds the connection from layer 1 all the way back up to layer 7 before sending it on to the backend webserver. This is called a "full proxy" architecture because it establishes two completely independent connections...one with the client and one with the backend server. The reason this is important is that it allows the BIG-IP to inspect every single part of that request at every single layer to make sure it is legitimate traffic. If it's malware, the BIG-IP can reject it before it ever gets to the webserver. Check out the following diagram that shows the flow of the full proxy architecture: The full proxy allows for many other cool things as well (like using iRules to modify traffic in realtime at wire speed), but for the purposes of this discussion, it allows for the complete inspection of your traffic to ensure malware never reaches your webservers. By offloading SSL/TLS encryption onto the BIG-IP, you move the encryption point away from your webservers and onto the BIG-IP. From a BIG-IP configuration standpoint, you do this via the SSL profile where you actually load the encryption keys, certificates, etc. You can actually have one unique profile for the client-side connection and another, separate one for the server-side connection. This is cool as well because you can use two totally different encryption strengths, keys, etc for each side of the connection. Because the BIG-IP holds the encryption keys, it will decrypt all the web traffic and then have the ability to inspect the clear text traffic. Prior to decryption, there would be no way to feasibly inspect the traffic. When you offload all your SSL/TLS traffic onto the BIG-IP and let it inspect each request at every layer, you can free up your webservers to do what they do best...serve up those amazing web applications that we all love! Also, when an attacker sends encrypted malware to your webservers, the BIG-IP will decrypt it and stop it before it ever reaches your servers. Related Resources: SSL Ciphers Supported on BIG-IP SSL Profiles on BIG-IP (10-part article series)What To Expect In 2017: Security In The Cloud
Security is a chess board. Of the primary fundamentals in chess the King is the most valuable piece and the Queen is the most powerful piece (in terms of potential flexibility/impact). Stay with me... if we relate these rules to security we can assert the following supposition: Data at rest = King: If you lose your data or worse, data is stolen and exposed, the game is over. You lost the security game. Data at motion = Queen: Data in motion gives us admins the most flexibility/impact for infrastructure planning and solution choices. akin to the Queen, it offers flexibility and options but if exposed or captured, the death knell may be near. If security is our chess board; the adoption of cloud infrastructure and resources increase the size of the board (IaaS, SaaS, and private cloud for this metaphor). Seriously... stay with me... if your board size increases, do you: Replace one-for-one the existing pawns with new ones? Not sure why you would do this because they have the same function... maybe you want new pieces on the board to make you feel like you're playing a new game. Change your style of gameplay to hopefully create value-add off existing game pieces? You can increase their usefulness across the larger board by being creative... right? Add additional pieces to compliment the existing pieces? Imagine if you had three more pawns, an extra rook, bishop, and knight? If you didn't guess already, the other pieces on the board represent your IT security solutions. You could get by for a while with answer B but sooner or later, your opponent is going to whittle you down. If you answered A go into sales or marketing because you're selling up technology as a solution to a problem you never understood. If you're someone who evaluated changes in the chess board and chose additional pieces to play, you know answer C is the correct one. Don't sabotage your existing security model because there's a few new pieces to play with. The new game board allows for NEW attack vectors against your King, it doesn't necessarily remove the old ones. By the way, pieces != vendors, they represent solutions to prevent those spaces from exposure and exploitation. Our metaphor is mostly but you saw where I was going right? Cloud Security Is The Same Security With A New Home Security trends for 2017 seem to lead us towards new technology under the guise that we'e been doing it wrong this whole time and new product X will solve all your security needs. Threatstack summary of Gartner's 2017 Cloud Security key findings confirm what we already know: Consensus doesn't exist on what constitutes best practices for cloud security; this is creating organizational issues for control process Vendor focus on specific areas of cloud technologies (IaaS) is drawing attention away from other control vectors (SaaS) but is yet no less critical Gartner's findings marry well to previous risk analysis; CSA's 2016 study of top 12 threats remain mostly unchanged (including top 5): Data breaches (Losing your King) Weak Identity, Credential, and Access Management Insecure APIs Account Hijacking Malicious Insiders Emerging acronyms in cloud security deserve closer inspection which aim to address Gartner and CSA's analysis. An Extra Knight For The Board: Cloud Access Security Brokers CASBs are security policy enforcement points, placing inline security policies, encryption, identity management, and a host of other features against cloud service consumers and providers. Yes, it's existing technologies wrapped up with a nice bow but is no less important on premise or in the cloud. If you're already playing in the cloud chances are you already have some form of CASB, and if you're a datacenter traditionalist, you definitely have some of these services (TACACS, SSO/Federation services, RBAC). CASB's do encapsulate a lot of disparate solutions into a service offering which may alleviate administrative end point expansion, potentially lowering costs. However, with several new players offering CASB "solutions", there's a lot of contest on the proving grounds before enterprises can add those additional pieces to their security chess board. Remember chess pieces != vendors... they represent solutions. Cloud Workload Protection Platform: Protect the Queen Wherever She May Go There are many ways vendors are massaging CWPP definitions to meet their products functionality. Using the term workload as the key jump point, the purpose of CWPP's are to classify data through governance policies, and be apply rulesets to that data in flight and when it lands. This allows InfoSec departments the ability to expand data governance rules to more complex hybrid and cloud deployments to ensure data is landing only where authorized and by only the correct parties. Think SELinux for cloud data; policy-based security policies applied across an organization regardless of data's location. New vendors and existing vendors are deploying CWPP features but unless they can seamlessly integrate into your existing infrastructure and meet your policy needs, you're implementing a half-complete solution. You've left chess board tiles exposed. Can CWPP address a lot of security issues? If your InfoSec program is mature enough, then yes. CASB and CWPP's are new solutions to old problems and are a welcome addition to the expanding chess board. But don't throw away your existing solutions because they're "old". Traditional vulnerabilities still exist and we re-expose ourselves if we shift focus away to new attack methods. InfoSec's responsibility is to evaluate the changing security landscape and adjust accordingly, not purchase the shiny new toy your CISO saw advertised in the airline magazine. The game's expanding and so should your security solution footprint. Adjust smartly and according to your business requirements. An informed InfoSec team is much more effective than one kept in the dark; looking at you Sales & Marketing Shadow IT! Give me a shout out with your thoughts; if you disagree we can argue security trends until SGDQ. I have my priorities straight.Encryption Basics: How RSA Works
The RSA Conference starts today in San Francisco, CA and we wanted to start off this week with a video that shows how RSA works. RSA is a public key cryptosystem that absolutely rocked the world of cryptography back in the 1970s. Maybe you've heard about RSA but you've never really understood how it works. Check out today's video to learn more about this amazing cryptosystem. Enjoy! Related Resources: Elliptic Curve Cryptography Ciphers Supported on BIG-IPWhat to Expect in 2017: Mobile Device Security
We are mobile, our devices are mobile, the networks we connect to are mobile and the applications we access are mobile. Mobility, in all its iterations, is a huge enabler and concern for enterprises and it'll only get worse as we start wearing our connected clothing to the office. If the last 10 years wasn’t warning enough, 2017 will be a huge year for mobile…again. Every year, it seems, new security opportunities, challenges and questions surround the mobile landscape. And now it encompasses more than just the device that causes phantom vibration syndrome, it now involves the dizzying array of sensors, devices and automatons in our households, offices and municipalities. Mobile has infiltrated our society and our bodies along with it. So the security stakes are high. The more we become one with our mobile devices, the more they become targets. It holds our most precious secrets which can be very valuable. We need to use care when operating such a device since, in many ways, our lives depend on it. And with the increased automation, digitization and data gathering, there are always security concerns. So how do we stay safe? The consumerization of IT technologies has made us all administrators of our personal infrastructure of connected devices. Our digital self has become a life of its own. As individuals we need to stay vigilant about clicking suspicious links, updating software, changing passwords, backing up data, watching financial accounts, having AV/FW and generally locking down devices like we do the doors to our home. Even then, the smartphone enabled deadbolt can be a risk. And we haven’t even touched on mobile payment systems, IoT botnets or the untested, insecure apps on the mobile phone itself. Cybersecurity is a social issue that impacts us all and we all need to be accountable. For enterprises, mobile devices carry an increased risk, especially personal devices connecting to an internal network. From regulatory compliance to the disgruntled employee, keeping sensitive information secret is top concern. BYOD policies and MDM solutions help as does segmenting those devices away from critical info. And the issue isn’t so much seeing restricted information, especially if your job requires it, it is more about unauthorized access if the device is compromised or lost. Many organizations have policies in place to combat this, including a total device wipe…which may also blast your personal keepsakes. The endpoint security market is maturing but won’t fill the ever-present security gaps. From your workforce to your customers, your mobile web applications are also a target. The Anti-Phishing Working Group (APWG) reports a 250 percent jump in the number of detected phishing websites between October 2015 and March 2016. Around 230,000 unique phishing campaigns a month, many aimed at mobile devices arriving as worrisome text messages. Late 2016 saw mobile browsing overtake desktop for the first time and Google now favors mobile-friendly websites for its mobile search results. A double compatibility and SEO whammy. And those two might not be the biggest risk to an organization since weakest link in the security ecosystem might be third-party vendors and suppliers. On the industrial side, tractors, weather sensors, street lights, HVAC systems, your car and other critical infrastructure are now mobile devices with their own unique security implications. The Industrial Internet of Things (IIoT) focuses on industrial control systems, device to network access and all the other connective sensor capabilities. These attacks are less frequent, at least today, but the consequences can be huge – taking out industrial plants, buildings, farms, and even entire cities. The Digital Dress Code has emerged and with 5G on the way, mobile device security takes on a whole new meaning. ps Related: Mobile Trends For 2017 And Beyond Perspectives on Securing Mobile and Social Business, 12 Months On RSAC17: More ransomware and IoT-enabled attacks on the way, warns expert Mobile Malware Milestone Mobile banking and how to stay secure What Does Mobile Mean, Anyway? BYOD - concentrate on the apps, not the devices 10 Security Trends To Watch For At RSA 2017
