PRESENTED BY:
Cipher Suite Practices and Pitfalls: An Overview of Cipher Suite Configuration and Pitfalls on BIG-IP
https://en.wikipedia.org/wiki/Cipher_suite
“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.” – Wikipedia
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.
https://en.wikipedia.org/wiki/Cipher_suitehttps://support.f5.com/csp/article/K15194
Let’s consider this cipher suite:
ECDHE-RSA-AES256-GCM-SHA384Key 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.
What about this cipher suite:
AES128-SHAKey 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 is to illustrate 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 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.
This presentation is really about cipher suite configuration and ciphers, and not the SSL/TLS
protocol, so I won’t dive too deeply here. 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 – Kpublic and Kprivate. Since you can openly share the
public key there is no need to pre-share keys with anyone. The downside is 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 Kprivate. Both ends use the same key, which poses the problem of key
distribution. The advantage is higher performance; common key sizes are 128-bit or 256-bit.
SSL/TLS uses both systems – the Key Exchange Algorithm is the public key system used to
exchange the symmetric key. Examples: ECDHE, DHE, RSA, ECDH, ADH
This is sometimes grouped in with the Key Exchange Algorithm – written as ‘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. Using an ‘ADH’ cipher suite will
cause this. 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.
“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.” – Wikipedia
Examples: 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 cryptography humor see:
RFC2410: The NULL Encryption Algorithm and Its Use With IPsechttps://en.wikipedia.org/wiki/Cipher
https://tools.ietf.org/html/rfc2410https://en.wikipedia.org/wiki/Cipher
All of the secrecy in encryption comes from the key that is used. 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 at
the end if there is time.) 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 2128 vs.
2256.
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 an image from Wikipedia:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29
As I said earlier, 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 much higher performance on a
given HW platform than CBC. It is also immune to classes of attack that have
harried CBC, such as padding (BEAST, Lucky 13, etc.)
The main drawback to AES-GCM is that it was only added in the TLSv1.2 revision,
so any older clients which don’t support TLSv1.2 cannot use it.
Pronouncing Galois: https://youtu.be/bjHuJyGf-vE
https://youtu.be/bjHuJyGf-vE
“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, hash
sums, or simply hashes. [snip] 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.” – Wikipedia
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’ by browsers as it is falling victim to advances in
cryptographic attacks. It is encouraged to migrate to SHA-2 ASAP.
https://en.wikipedia.org/wiki/Hash_function
https://en.wikipedia.org/wiki/Hash_function
Now that we’ve covered what cipher suites are, lets 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 control plane
SSL/TLS is handled by OpenSSL and the configuration follows the standard
OpenSSL configuration options.
In tmm the cipher suites are configured in the Ciphers field of the Client SSL or
Server SSL profiles. See K14783 & K14806, respectively.
It is important to keep in mind that these are two different worlds with their own
requirements and quirks.
https://support.f5.com/csp/article/K14783https://support.f5.com/csp/article/K14806
SSL/TLS on the control plane basically means httpd. This is the default in 12.0.0:
tmsh list sys http ssl-ciphersuite
sys httpd {
ssl-ciphersuite DEFAULT:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP
}
You can configure the cipher suite with ’tmsh modify sys http ssl-ciphersuite ’.
Note that the default is not just ‘DEFAULT’, as it is in tmm. So what ciphers are actually
supported? For that you want to run:
openssl ciphers -v 'DEFAULT:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP‘
That will list out all of the ciphers enabled by this configuration. Let’s see that on the next
slide.
openssl ciphers -v 'DEFAULT:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP'
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
[snipped for length]
Let’s look at one of those:
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA
Enc=AESGCM(256) Mac=AEAD
The columns are:
- Cipher Suite
- Protocol
- Key Exchange Algorithm (Kx)
- Authentication Algorithm (Au)
- Cipher/Encryption Algorithm (Enc)
- MAC (Mac)
Since the control plane is OpenSSL you can use the standard OpenSSL
documentation: https://www.openssl.org/docs/man1.0.1/apps/ciphers.html
https://www.openssl.org/docs/man1.0.1/apps/ciphers.html
In TMM Client SSL and Server SSL are just about identical, so I’ll just use Client SSL
examples. I created a Client SSL profile creatively named ‘test’.
tmsh list ltm profile client-ssl test ciphers
ltm profile client-ssl test {
ciphers DEFAULT
}
You can configure it with ‘tmsh modify ltm profile client-ssl ciphers ’.
Note here the default is really just DEFAULT. What that actually expands to will vary
depending on the version of TMOS. You can check K13156, or use:
tmm --clientciphers DEFAULT
Let’s take a look on the next slide.
https://support.f5.com/csp/article/K13156
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
[snipped for length]
Some differences 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.
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. We are planning to correct this display to be ‘AEAD’.
Let’s say you have determined that you need to support only AES & AES-GCM, 128-
bit or 256-bit, and only ECDHE key exchange. Any MAC or Authentication is fine.
On 12.0.0 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. Fortunately there is an alternative –
keywords! This results 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.
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. Actually not that reliable due to many platform variations, not recommended.
@STRENGTH: Re-orders the list to put ‘stronger‘ (larger keys) ciphers first.
Protocol:
TLSv1_3 – cipher suites available under TLSv1.3
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!
Key Exchange Algorithms (sometimes with Authentication specified):
ECDHE or ECDHE_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 on 11.x
HIGH: ‘High’ security cipher suites; >128-bit
MEDIUM: ‘Medium’ security cipher suites; effectively 128-bit suites (Also 3DES)
LOW: ‘Low’ security cipher suites;
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 EXPORT! 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 versions, when using COMPAT, it also enables two additional keywords:
SSLv2: Ciphers supported on the SSLv2 protocol
RC2: RC2 ciphers.
So back to our example:
tmm --clientciphers 'ECDHE+AES-GCM:ECDHE+AES‘
Note that you can combine keywords using ‘+’. And multiple entries in the ciphers
configuration line are separated with ‘:’.
We can also exclude suites or keywords. There are two ways to do that:
‘!’ is a hard exclusion. Anything excluded this way cannot be implicitly or explicitly re-
enabled. It is disabled, period.
‘-’ is a soft exclusion. Anything excluded this way can be explicitly re-enabled later in
the configuration string.
Let’s look at the different in hard and soft exclusions on the next slide.
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
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
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 we used ‘!DHE’ and even though we then explicitly
added ‘DHE+AES-GCM’ those ciphers were not enabled. While in the third example
we used ‘-DHE’ and then ‘DHE+AES-GCM’ did enable those ciphers.
You might be wondering what soft disabling is useful for – 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. Say I know 3DES is really 112-bit and
not 168-bit, and while I need it enabled, I want it to be last on the list.
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. Try it – compare
tmm --clientciphers 'DEFAULT‘
tmm --clientciphers 'DEFAULT:-3DES:!SSLv3:3DES+ECDHE:3DES+DHE:3DES+RSA'
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.
This seems straight forward – just configure it to use only ciphers on TLSv1.1 &
TLSv1.2. Right? Let’s try that:
tmsh modify ltm profile client-ssl 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.) 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‘ should’ve raised red flags.
Instead, this configuration would work without causing all of those problems:
tmsh modify ltm profile client-ssl ciphers ‘DEFAULT:!TLSv1:!SSLv3’
Another option is to disable the SSLv3 and TLSv1.0 protocols on the VIP.
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.
We’ve seen a lot of confusion over the cipher suite vs. the protocol on the SSL/TLS
connection. Many have the mistaken belief that using “!TLSv1” in the ciphers configuration
will disable the TLSv1.0 protocol, for example. That is incorrect.
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. Oops.
So how do you disable the specific SSL/TLS protocols, if not in the cipher suite?
Under ‘Options’ in the SSL Profile! You’ll find a few options:
No SSL – disable all SSL
No SSLv1 – disable the SSLv1 protocol
No SSLv2 – disable the SSLv2 protocol
No SSLv3 – disable the SSLv3 protocol
No TLS – disable all TLS
No TLSv1 – disable the TLSv1.0 protocol
No TLSv1.1 – disable the TLSv1.1 protocol
No TLSv1.2 – disable the TLSv1.2 protocol
No TLSv1.3 – disable the TLSv1.3 protocol
Note that this is for TMM profiles, for httpd on the host see SOL17491: Unable to limit
Configuration utility access to clients using only TLSv1.1 or TLSv1.2
https://support.f5.com/kb/en-us/solutions/public/17000/400/sol17491.html
In versions up to 11.5.0 the cipher suite configuration string was truncated at 256
bytes. Starting in 11.5.0 that was increased to 768 bytes (K11481, K63241636), but
that can still silently truncate long configurations. 13.0.0 resolved this along with the
introduction of Cipher Groups and Cipher Rules.
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.
https://support.f5.com/csp/article/K11481K63241636
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 256. 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 uses the exact same DES cipher, it just uses it three times –
hence the name. So you might think 3x56-bits = 168-bits. 2168 strong! Right? No, not really.
The standard implementation of 3DES is known as EDE – for Encrypt, Decrypt, Encrypt. (For
reasons I can explain.) You take the 64-bit data block, run it through DES once to encrypt it with K1,
then run it through again to decrypt it using K2, then encrypt it once again using K3.
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 via EDE!)
We do use 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 2112. So it does not provide the expected 168-bits of security, and is in fact weaker
than AES128.
Worse, we used to describe 3DES as being 192-bit. That’s just flat out wrong no matter how
you look at it. DES operates on 64-bit data blocks, but that’s not the same as key size. See:
K17296: The BIG-IP system incorrectly reports a 192-bit key length for cipher suites using
3DES (DES-CBC3)
https://support.f5.com/csp/article/K17296
Cipher Suite Practices and Pitfalls:
https://devcentral.f5.com/articles/cipher-suite-practices-and-pitfalls-25564
BIG-IP SSL Cipher History by David Holmes: https://devcentral.f5.com/articles/big-
ip-ssl-cipher-history
OpenSSL ciphers docs: https://www.openssl.org/docs/man1.0.1/apps/ciphers.html
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 - 13.x)
K13156: SSL ciphers used in the default SSL profiles (11.x - 13.x)
K17370: Configuring the cipher strength for SSL profiles (12.x - 13.x)
K13171: Configuring the cipher strength for SSL profiles (11.x)
K14783: Overview of the Client SSL profile (11.x - 13.x)
K14806: Overview of the Server SSL profile (11.x - 13.x)
https://devcentral.f5.com/articles/cipher-suite-practices-and-pitfalls-25564https://devcentral.f5.com/articles/big-ip-ssl-cipher-historyhttps://www.openssl.org/docs/man1.0.1/apps/ciphers.htmlhttps://support.f5.com/csp/article/K8802https://support.f5.com/csp/article/K15194https://support.f5.com/csp/article/K13163https://support.f5.com/csp/article/K13156https://support.f5.com/csp/article/K17370https://support.f5.com/csp/article/K13171https://support.f5.com/csp/article/K14783https://support.f5.com/csp/article/K14806
F5 Security IncidentResponse Team
For emergency security response — call F5 Support!
24x7x365 Security Experts
Global availability
Included with your support contract
Report vulnerabilities to [email protected]
Top Related