Many times, when we are analyzing or configuring the security of our Internet connections, we find that we need to understand what those long names assigned to cipher suites mean and determine whether they are secure or not.
Cipher suites are used in a wide variety of scenarios where secure communication is required. Some examples include:
▪️Virtual Private Networks (VPNs): Cipher suites are used to establish a secure communication channel between a
VPN client and a VPN server. This allows users to securely access remote networks and resources as if they were
directly connected to the network. Cipher suites are also used specifically in tunnels created with the Internet Security
Protocol (IPSec) when establishing tunnels between two hosts or between a host and a network. IPSec provides
confidentiality, integrity, and authenticity to IP packets.
▪️Secure Email: Cipher suites are used to encrypt and sign email messages to protect them from eavesdropping
and tampering.
▪️Other Applications: Cipher suites are used to secure the connection between client and server to protect exchanged
data from eavesdropping and tampering. Examples include: Secure File Transfer Protocol (SFTP), Hypertext Transfer
Protocol Secure (HTTPS).
Encryption Suite
To understand these cryptic cipher suite names, we must first understand what a cipher suite is. We can define a cipher suite as a set of cryptographic algorithms used to create and exchange keys, as well as encrypt and decrypt information, where each algorithm defined within the set covers a specific function in the process of protecting information during transmission.
To establish communication between a server and a client, the server must first be configured with a set of cipher suites considered acceptable for the organization. Once this is done, it becomes ready to receive connections that follow this flow (the flow may vary slightly depending on the TLS version):
- The client sends the versions of cipher suites and compression methods it supports, in order of preference (ClientHello).
- The server selects from them the most suitable suite to begin encrypting data (ServerHello).
- The server sends its certificate with public encryption keys.
- The client verifies the certificate, checking both its validity and the server’s identity. If verification is successful, it proceeds to negotiate a secret key called the Master Secret, based on the selected cipher suite.
- The client sends an encrypted message to the server.
- The server verifies that the Message Authentication Code (MAC) is correct and that the message can be decrypted properly.
- The server responds to the message, which is also verified by the client.
Analyzing this flow, we see that several types of encryption are used in different parts of the communication establishment process. This is why cipher suites must identify each of their components. To understand each one, let’s use an example and identify the elements in the following diagram:
▪️TLS defines the protocol for which this cipher suite is intended, normally TLS.
▪️ECDHE indicates the key exchange algorithm.
▪️PSK indicates the digital signature or authentication method used during communication establishment.
▪️AES is the session cipher.
▪️256 is the size (in bits) of the session encryption key.
▪️GCM indicates the type or mode of encryption (block cipher dependency and additional options).
▪️SHA is the Message Authentication Code (MAC).
▪️384 is the size (in bits) of the digest or hash.
▪️P384 is the key size when using elliptic curve cryptography (sometimes omitted and considered optional).
If no encryption algorithm is used for a particular task within the suite, it is documented as NULL. An example of a suite that does not encrypt (and should never be used) is:
TLS_NULL_WITH_NULL_NULL
Of course, not all algorithms are secure, and we cannot always use the most demanding ones—either because the asset being protected is not highly valuable or because clients accessing the information use outdated or low power platforms. This leads us to configure different alternatives on our server.
The strength of a cipher suite is determined by its weakest component, which is why we must choose different alternatives that provide an adequate level of security for the specific situation.
Below is a table showing some examples of algorithms from most secure to least secure, but it is important to note that the evaluation criteria may change depending on the key size used, where applicable.
| Protocol | Key exchange | Key exchange algorithm | Data encryption algorithm | Hash algorithm |
| TLS | 1. ECDHE: Elliptic Curve Diffie-Hellman | 1. ECDSA (Elliptic Curve Digital Signature Algorithm) | 1. AES (Advanced Encryption Standard) | 1. SHA3 (Secure Hash Algorithm 3) |
| 2. DHE: Diffie-Hellman | 2. RSA (Rivest-Shamir-Adleman) | 2. ChaCha20 | 2. SHA384 (Secure Hash Algorithm384) | |
| 3. DSA (Digital Signature Algorithm) | 3. Camellia | 3. SHA256 (Secure Hash Algorithm256) | ||
| 4. Aria |
Some encryption algorithms and key exchange methods are generally considered insecure and should be avoided when choosing a cipher suite. Examples include:
▪️Obsolete and broken protocols: SSLv2, SSLv3, TLS 1.0. TLS 1.2 is recommended as
a minimum.
▪️Weak encryption algorithms: DES, Blowfish.
▪️Weak key exchange methods: RSA with key sizes below 2048 bits.
▪️CBC mode: Cipher Block Chaining mode has known vulnerabilities and should be avoided.
▪️MD5 and SHA 1: These hash functions are vulnerable to collisions and preimage attacks and should not be used
when a secure hash is required.
Key length is an important factor in determining the security of an encryption algorithm. Longer keys generally provide greater security.
▪️For symmetric algorithms like AES and Blowfish, keys of 128 bits or more are considered secure.
▪️For RSA, the minimum recommended key length is 2048 bits.
▪️For Elliptic Curve Cryptography (ECC), the minimum is 256 bits.
However, key length alone does not guarantee security. Other factors—such as secure key management, secure protocol design, and secure implementation—also play important roles.
Additionally, key length requirements evolve as computing power increases, so it is important to periodically evaluate and update system security to ensure that key lengths do not compromise the security of transmitted information or the system itself.
Keeping software updated is essential to avoid using obsolete or broken encryption. It is also important to consult standards and guidelines such as NIST SP 800 52r2 or OWASP for recommended and deprecated ciphers and key lengths.
Algorithms for Use in Highly Secure Environments
In high security environments, such as government or financial institutions, the highest level of security must be maintained. Therefore, it is important to use the most secure cipher suites available. Examples include:
▪️AES 256 GCM: Uses AES with a 256 bit key in Galois/Counter Mode. Considered one of the most secure
algorithms available.
▪️ChaCha20 Poly1305: A relatively new suite using the ChaCha20 stream cipher and Poly1305 authenticator.
Highly secure and recommended for TLS and IPSec.
▪️ECDHE ECDSA AES256 GCM SHA384: Uses ECDHE for key exchange, ECDSA for authentication, AES 256 GCM for
encryption, and SHA 384 for integrity.
▪️ECDHE RSA AES256 GCM SHA384: Similar to the above but uses RSA for authentication.
Security depends on many factors: algorithm strength, key size, and implementation quality. Regular evaluation and updates are essential.
Compliance with industry standards such as NIST SP 800 52r2 and OWASP is also important.
It is also important to keep in mind that, for high‑security environments, it is necessary to consider compliance with industry standards and regulations, such as NIST Special Publication 800‑52r2 or OWASP, which list recommended and deprecated ciphers and protocols.
Below are a couple of lists with cipher suites that (as of today) can be configured in secure environments.
Recommended Cipher Suites:
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECCPWD_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_ECCPWD_WITH_AES_256_GCM_SHA384
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
TLS_AES_128_CCM_8_SHA256
TLS_ECCPWD_WITH_AES_128_CCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CCM
TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256
TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256
TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256
TLS_ECCPWD_WITH_AES_256_CCM_SHA384
TLS_AES_128_CCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_128_CCM
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Algorithms for Use in Devices with Limited Computing Power
Some specialized devices, such as IoT devices, have limited resources (memory, processing power), making some cipher suites difficult to use. Examples of suitable suites include:
▪️AES‑128‑GCM: This cipher suite uses AES encryption with a 128‑bit key in
Galois/Counter Mode (GCM). It is considered secure and is relatively efficient in
terms of processing power and memory usage.
▪️ChaCha20‑Poly1305: This is a relatively new cipher suite that uses the ChaCha20
stream cipher and the Poly1305 authenticator. It is considered very secure and is
relatively efficient in terms of processing power and memory usage.
▪️ECDHE‑ECDSA‑AES128‑GCM‑SHA256: This cipher suite uses Elliptic Curve
Diffie‑Hellman (ECDHE) for key exchange, the Elliptic Curve Digital Signature
Algorithm (ECDSA) for authentication, AES‑128‑GCM for encryption, and SHA‑256
for message integrity.
▪️ECDHE‑RSA‑AES128‑GCM‑SHA256: Similar to the previous one, this suite uses
RSA for authentication and ECDHE for key exchange.
It is important to keep in mind that for resource‑constrained devices, security is not the only concern; other factors such as power consumption and communication bandwidth must also be considered. This is why a balance between security and performance is necessary.
Vulnerabilities of Cipher Suites
A weak encryption algorithm is vulnerable to a range of attacks that can compromise the security of communication. Here are some examples of attacks that can be used against weak ciphers:
▪️ Brute force: A brute‑force attack consists of trying all possible keys until the
correct one is found. With weak cipher suites, the key space may be smaller,
making it easier for an attacker to discover the correct key.
▪️ Cryptanalysis: Cryptanalysis is the process of analyzing a cipher or cryptographic
system to find weaknesses that can be exploited. With weak cipher suites, the
algorithms used may be vulnerable to known cryptanalytic attacks, making it easier
for an attacker to break the encryption.
▪️ Side‑channel attacks: Side‑channel attacks exploit information leaked during the
encryption or decryption process, such as power consumption or electromagnetic
radiation. With weak cipher suites, the algorithms used may be vulnerable to
side‑channel attacks, making it easier for an attacker to extract the encryption key.
▪️ Man‑in‑the‑middle: A man‑in‑the‑middle attack is a type of eavesdropping attack
in which the attacker intercepts communication between two parties and can read,
insert, or modify data. With weak cipher suites, communication may be vulnerable
to man‑in‑the‑middle attacks, making it easier for an attacker to intercept and alter
the communication.
It is important to note that these are only some examples of attacks that can be used against weak ciphers, and new attack methods are constantly being developed. It is essential to regularly assess and update the security of your systems to ensure that you are using cipher suites considered secure at any given time.
Verification of Configured Algorithms
When using cipher suites, the configurations on both ends of the communication must be verified—that is, the client and the server, or both endpoints of a point‑to‑point connection. To do this, you must start by inspecting the configuration settings provided by the software or operating system vendor, which in the case of clients—being operating systems or browsers—may be located in hard‑to‑access places such as registry keys. The goal is to ensure that, on the server side, no insecure protocol configurations are offered, and on the client side, connections to servers using insecure protocols are not allowed.
Third party tools can help verify configurations for public sites and client supported algorithms:
▪️https://www.immuniweb.com/ssl/
▪️https://www.site24x7.com/es/tools/tls-checker.html
▪️https://www.ionos.es/tools/ssl-checker
These are some command‑line tools that can be useful for testing encryption configurations:
▪️testssl.sh: A free Bash tool that checks a service on any port for TLS/SSL compatibility,
cryptographic flaws, and more.
▪️Cipherscan: Checks the SSL/TLS cipher ordering on a target, extracting information about certificates
and TLS options.
▪️OpenSSL: A versatile toolkit used to verify specific capabilities, such as Forward Secrecy support.
Referencias:
🔗Microsoft Learn. (14 julio 2023). Cipher Suites in TLS/SSL (Schannel SSP).
https://learn.microsoft.com/en-au/windows/win32/secauthn/cipher-suites-in-schannel
🔗Dierks, T., Rescorla, E. Internet Engineering Task Force (IETF). (agosto 2008). RFC 5246. The Transport Layer Security (TLS) Protocol Version 1.2.
https://datatracker.ietf.org/doc/html/rfc5246
🔗Rescorla, E. Internet Engineering Task Force (IETF). (agosto 2018). RFC 8446. The Transport Layer Security (TLS) Protocol Version 1.3.
https://www.rfc-editor.org/rfc/rfc8446
🔗Blake-Wilso, S., Bolyard, N., Gupta, V, Hawk C., Moeller B. Bochum R. Internet Engineering Task Force (IETF). (MAYO 2006). RFC 4492. Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS).
https://datatracker.ietf.org/doc/html/rfc4492
🔗IANA - Internet Assigned Numbers Authority. (12 diciembre 2023). Transport Layer 🔗Security (TLS) Parameters.
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
🔗Ciphersuite. 348 Cypher Suites.
https://ciphersuite.info/cs/?singlepage=true&sort=sec-desc
🔗Muscat, A. The Acunetix Blog - Web Security Zone. (10 abril 2019). Recommendations for TLS/SSL Cipher Hardening.
https://www.acunetix.com/blog/articles/tls-ssl-cipher-hardening/
🔗Giry, D. BlueKrypt (24 mayo 2020). Cryptographic Key Length Recommendation. https://www.keylength.com/
