Cipher suite

Last updated

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm. [1]

Contents

The key exchange algorithm is used to exchange a key between two devices. This key is used to encrypt and decrypt the messages being sent between two machines. The bulk encryption algorithm is used to encrypt the data being sent. The MAC algorithm provides data integrity checks to ensure that the data sent does not change in transit. In addition, cipher suites can include signatures and an authentication algorithm to help authenticate the server and or client.

Overall, there are hundreds of different cipher suites that contain different combinations of these algorithms. Some cipher suites offer better security than others. But with the adoption of TLS 1.3, only 5 cipher suites have been officially supported and defined. [2]

The structure and use of the cipher suite concept are defined in the TLS standard document. [3] TLS 1.2 is the most prevalent version of TLS. The newest version of TLS (TLS 1.3) includes additional requirements to cipher suites. Cipher suites defined for TLS 1.2 cannot be used in TLS 1.3, and vice versa, unless otherwise stated in their definition.

A reference list of named cipher suites is provided in the TLS Cipher Suite Registry. [4]

History

The use of ciphers has been a part of the Secure Socket Layer (SSL) transit protocol since its creation. SSL has been succeeded by TLS for most uses. However, the name Cipher Suite was not used in the original draft of SSL. Instead the ability for a client and a server to choose from a small set of ciphers to secure their connection was called Cipher-Choice. [5] [6] It was not until SSL v3 (the last version of SSL) that the name Cipher Suite was used. [7] Every version of TLS since has used Cipher Suite in its standardization. The concept and purpose of a Cipher Suite has not changed since the term was first coined. It has and still is used as a structure describing the algorithms that a machine supports in order for two machines to decide which algorithms to use to secure their connection. What has changed is the versions of the algorithms that are supported in the cipher suites. Each version of TLS has added support for stronger versions of the algorithms and removed support for versions of the algorithms that have been identified as insecure.

TLS 1.3 marks a change in how cipher suites are coordinated between machines. The cipher suite chosen for two communicating machines to use is determined by the handshake process. Modifications were done in TLS 1.3 to the handshake process to cut down on the number of messages needed to be sent. This allows for less processing, less packet traffic and more efficiency compared to previous versions of TLS.

Naming scheme

Each cipher suite has a unique name that is used to identify it and to describe the algorithmic contents of it. Each segment in a cipher suite name stands for a different algorithm or protocol. An example of a cipher suite name: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The meaning of this name is:

TLS
defines the protocol that this cipher suite is for; it will usually be TLS.
ECDHE
indicates the key exchange algorithm being used.
RSA
authentication mechanism during the handshake.
AES
session cipher.
128
session encryption key size (bits) for cipher.
GCM
type of encryption (cipher-block dependency and additional options).
SHA
(SHA2)hash function. For a digest of 256 and higher. Signature mechanism. Indicates the message authentication algorithm which is used to authenticate a message.
256
Digest size (bits).

Full handshake: coordinating cipher suites

To use cipher suites, the client and the server must agree on the specific cipher suite that is going to be used in exchanging messages. Both the client and the server must support the agreed upon cipher suite. If the client and server do not agree on a cipher suite, no connection will be made. [8] This selection process occurs during the TLS Handshake Protocol. TLS 1.3 includes a TLS Handshake Protocol that differs compared to past and the current version of TLS/SSL.

After coordinating which cipher suite to use, the server and the client still have the ability to change the coordinated ciphers by using the ChangeCipherSpec protocol in the current handshake or in a new handshake.

To test which TLS ciphers a server supports, an SSL/TLS Scanner may be used.

TLS 1.0–1.2 handshake

Visual representation of how a client and server operating on TLS 1.2 coordinate which cipher suite to use TLS 1.2 Handshake.png
Visual representation of how a client and server operating on TLS 1.2 coordinate which cipher suite to use

This client starts the process by sending a clientHello message to the server that includes the version of TLS being used and a list of cipher suites in the order of the client's preference. In response, the server sends a serverHello message that includes the chosen cipher suite and the session ID. Next the server sends a digital certificate to verify its identity to the client. The server may also request a client's digital certification if needed.

If the client and server are not using pre-shared keys, the client then sends an encrypted message to the server that enables the client and the server to compute which secret key will be used during exchanges.

After successfully verifying the authentication of the server and, if needed, exchanging the secret key, the client sends a finished message to signal that it is done with the handshake process. After receiving this message, the server sends a finished message that confirms that the handshake is complete. Now the client and the server are in agreement on which cipher suite to use to communicate with each other.

Visual representation of how a client and server operating on TLS 1.3 coordinate which cipher suite to use TLS 1.3 Handshake.png
Visual representation of how a client and server operating on TLS 1.3 coordinate which cipher suite to use

TLS 1.3 handshake

If two machines are corresponding over TLS 1.3, they coordinate which cipher suite to use by using the TLS 1.3 Handshake Protocol. The handshake in TLS 1.3 was condensed to only one round trip compared to the two round trips required in previous versions of TLS/SSL.

First the client sends a clientHello message to the server that contains a list of supported ciphers in order of the client's preference and makes a guess on what key algorithm is being used so that it can send a secret key to share if needed.

By making a guess on what key algorithm that is being used it eliminates a round trip. After receiving the clientHello, the server sends a serverHello with its key, a certificate, the chosen cipher suite and the finished message.

After the client receives the server's finished message it now is coordinated with the server on which cipher suite to use. [9]

Supported algorithms

In TLS 1.0–1.2

Algorithms supported in TLS 1.0–1.2 cipher suites
Key exchange/agreementAuthenticationBlock/stream ciphersMessage authentication
RSA RSA RC4 Hash-based MD5
Diffie–Hellman DSA Triple DES SHA hash function (SHA-1 and SHA-2)
ECDH ECDSA AES (128-bits and 256-bits)
SRP IDEA
PSK [10] DES
Camellia
ChaCha20
NULL

For more information about algorithms supported in TLS 1.0–1.2, see also: Transport Layer Security § Applications and adoption

TLS 1.3

In TLS 1.3, many legacy algorithms that were supported in early versions of TLS have been dropped in an effort to make the protocol more secure. [11] In addition, all encryption and authentication algorithms are combined in the authenticated encryption with associated data (AEAD) encryption algorithm. Also a hash algorithm must now be used in HMAC-based key derivation (HKDF). [12] All non-AEAD ciphers have been removed due to possible weaknesses or vulnerabilities and ciphers must use an ephemeral key exchange algorithm so that new key pairs are generated for every exchange. [13] NULL encryption have been removed.

DTLS with cipher suites

Datagram Transport Layer Security (DTLS) is based on TLS, but is specifically used for UDP connections instead of TCP connections. Since DTLS is based on TLS it is able to use a majority of the cipher suites described for TLS. There are special cases that must be considered when using TLS cipher suites with DTLS. DTLS does not support the stream cipher RC4 which means that no TLS cipher using RC4 can be used with DTLS. [14]

To determine if a TLS cipher suite is compatible with DTLS looking at its name will not help. Each TLS cipher suite will still include the TLS identifier space in its name. e.g.: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Instead, all TLS parameter registries now include the flag DTLS-OK to signal if a cipher suite supports DTLS. [15]

Vulnerabilities

A cipher suite is as secure as the algorithms that it contains. If the version of encryption or authentication algorithm in a cipher suite have known vulnerabilities the cipher suite and TLS connection may then be vulnerable. Therefore, a common attack against TLS and cipher suites is known as a downgrade attack. A downgrade in TLS occurs when a modern client connects to legacy servers that are using older versions of TLS or SSL.

When initiating a handshake, the modern client will offer the highest protocol that it supports. If the connection fails, it will automatically retry again with a lower protocol such as TLS 1.0 or SSL 3.0 until the handshake is successful with the server. The purpose of downgrading is so that new versions of TLS are compatible with older versions. However, it is possible for an adversary to take advantage of this feature and make it so that a client will automatically downgrade to a version of TLS or SSL that supports cipher suites with algorithms that are known for weak security and vulnerabilities. [16] This has resulted in attacks such as POODLE.

One way to avoid this security flaw is to disable the ability of a server or client to be able to downgrade to SSL 3.0. The shortcoming with this fix is that some legacy hardware cannot be accessed by newer hardware. If SSL 3.0 support is needed for legacy hardware, there is an approved TLS_FALLBACK_SCSV cipher suite which verifies that downgrades are not triggered for malicious intentions. [17]

Cipher suites for constrained devices

Encryption, key exchange and authentication algorithms usually require a large amount of processing power and memory. To provide security to constrained devices with limited processing power, memory, and battery life such as those powering the Internet of things there are specifically chosen cipher suites. Two examples include:

  1. TLS_PSK_WITH_AES_128_CCM_8 (pre-shared key) [18]
  2. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (raw public key)

Each of these cipher suites has been implemented to run on devices with constraints in processing power and memory. They are both implemented in the open-sourced project TinyDTLS. The reason that they are able to work on these constrained devices is because they can be implemented in a light-weight fashion. Implementations of the pre-shared key cipher suite used only 1889 bytes of RAM and 38266 of flash ROM which is very resource-conscious compared to most encryption and security algorithms. [19] This low memory usage is due to these cipher suites using proven efficient algorithms that are secure, but maybe not as secure as more resource-required algorithms; exp: Using 128 bit encryption vs 256 bit encryption. In addition they use pre-shared key or raw public key which requires less memory space and processing power compared to using traditional public key infrastructure (PKIX). [20]

Programming references

In programming, a cipher suite is referred to in both plural and non-plural forms. Each one has different definitions:

CipherSuite cipher_suites
a list of the cryptographic options supported by the client. [21] An example of how cipher_suites is usually used during the handshake process:
struct{ProtocolVersionclient_version;Randomrandom;SessionIDsession_id;CipherSuitecipher_suites<2..2^16-2>;CompressionMethodcompression_methods<1..2^8-1>;select(extensions_present){casefalse:struct{};casetrue:Extensionextensions<0..2^16-1>;};}ClientHello;
CipherSuite cipher_suite
the cipher suite selected by the server from the client's cipher_suites. [22] An example of how cipher_suite is usually used during the handshake process:
struct{ProtocolVersionserver_version;Randomrandom;SessionIDsession_id;CipherSuitecipher_suite;CompressionMethodcompression_method;select(extensions_present){casefalse:struct{};casetrue:Extensionextensions<0..2^16-1>;};}ServerHello;

See also

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed it primarily at a client–server model, and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.

The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

In cryptography, Camellia is a symmetric key block cipher with a block size of 128 bits and key sizes of 128, 192 and 256 bits. It was jointly developed by Mitsubishi Electric and NTT of Japan. The cipher has been approved for use by the ISO/IEC, the European Union's NESSIE project and the Japanese CRYPTREC project. The cipher has security levels and processing abilities comparable to the Advanced Encryption Standard.

FTPS is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer cryptographic protocols.

Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications by allowing them to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport—the application does not suffer from the delays associated with stream protocols, but because it uses UDP or SCTP, the application has to deal with packet reordering, loss of datagram and data larger than the size of a datagram network packet. Because DTLS uses UDP or SCTP rather than TCP, it avoids the "TCP meltdown problem", when being used to create a VPN tunnel.

In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised, limiting damage. For HTTPS, the long-term secret is typically the private key of the server. Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. This by itself is not sufficient for forward secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys.

CCM mode is a mode of operation for cryptographic block ciphers. It is an authenticated encryption algorithm designed to provide both authentication and confidentiality. CCM mode is only defined for block ciphers with a block length of 128 bits.

Authenticated Encryption (AE) is an encryption scheme which simultaneously assures the data confidentiality and authenticity. Examples of encryption modes that provide AE are GCM, CCM.

<span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

In cryptography, Galois/Counter Mode (GCM) is a mode of operation for symmetric-key cryptographic block ciphers which is widely adopted for its performance. GCM throughput rates for state-of-the-art, high-speed communication channels can be achieved with inexpensive hardware resources.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

wolfSSL is a small, portable, embedded SSL/TLS library targeted for use by embedded systems developers. It is an open source implementation of TLS written in the C programming language. It includes SSL/TLS client libraries and an SSL/TLS server implementation as well as support for multiple APIs, including those defined by SSL and TLS. wolfSSL also includes an OpenSSL compatibility interface with the most commonly used OpenSSL functions.

The Transport Layer Security (TLS) protocol provides the ability to secure communications across or inside networks. This comparison of TLS implementations compares several of the most notable libraries. There are several TLS implementations which are free software and open source.

Application-Layer Protocol Negotiation (ALPN) is a Transport Layer Security (TLS) extension that allows the application layer to negotiate which protocol should be performed over a secure connection in a manner that avoids additional round trips and which is independent of the application-layer protocols. It is used to establish HTTP/2 connections without additional round trips.

MatrixSSL is an open-source TLS/SSL implementation designed for custom applications in embedded hardware environments.

In cryptography, the Salted Challenge Response Authentication Mechanism (SCRAM) is a family of modern, password-based challenge–response authentication mechanisms providing authentication of a user to a server. As it is specified for Simple Authentication and Security Layer (SASL), it can be used for password-based logins to services like LDAP, HTTP, SMTP, POP3, IMAP and JMAP (e-mail), XMPP (chat), or MongoDB and PostgreSQL (databases). For XMPP, supporting it is mandatory.

Application Layer Transport Security (ALTS) is a Google-developed authentication and transport encryption system used for securing Remote Procedure Call (RPC) within Google machines. Google started its development in 2007, as a tailored modification of TLS.

ChaCha20-Poly1305 is an authenticated encryption with additional data (AEAD) algorithm, that combines the ChaCha20 stream cipher with the Poly1305 message authentication code. Its usage in IETF protocols is standardized in RFC 8439. It has fast software performance, and without hardware acceleration, is usually faster than AES-GCM.

References

  1. ↑ "Cipher Suites in TLS/SSL (Schannel SSP) (Windows)". docs.microsoft.com. Retrieved 2018-07-02.
  2. ↑ "Configuring a Cipher Suites List Using TLS v1.3". www.microfocus.com. Retrieved 2023-11-30.
  3. ↑ RFC   5246
  4. ↑ TLS Cipher Suite Registry
  5. ↑ "The SSL 0.2 Protocol". www-archive.mozilla.org. Retrieved 2017-12-07.
  6. ↑ "draft-hickman-netscape-ssl-00". tools.ietf.org. Retrieved 2017-12-07.
  7. ↑ "SSL 3.0 Specification". www.freesoft.org. Retrieved 2017-12-07.
  8. ↑ Villanueva, John Carl. "An Introduction To Cipher Suites" . Retrieved 2017-10-25.
  9. ↑ Valsorda, Filippo (23 September 2016). "An overview of TLS 1.3 and Q&A". The Cloudflare Blog. Retrieved 1 September 2020.
  10. ↑ ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2. doi: 10.17487/RFC8442 . RFC 8442.
  11. ↑ "TLS 1.3 Protocol Support | wolfSSL Embedded SSL/TLS Library". wolfSSL. Retrieved 2017-10-26.
  12. ↑ E. Rescorla (November 4, 2016). "The Transport Layer Security (TLS) Protocol Version 1.3" . Retrieved 2016-11-11.
  13. ↑ Sullivan, Nick (11 August 2018). "A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)". The Cloudflare Blog. Retrieved 11 August 2020.
  14. ↑ N., Modadugu; E., Rescorla. "Datagram Transport Layer Security". tools.ietf.org. Retrieved 2017-10-25.
  15. ↑ Eric, Rescorla; Nagendra, Modadugu. "Datagram Transport Layer Security Version 1.2". tools.ietf.org. Retrieved 2017-10-25.
  16. ↑ Bodo, Moeller; Adam, Langley. "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks". tools.ietf.org. Retrieved 2017-10-25.
  17. ↑ Bodo, Moeller; Adam, Langley. "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks". tools.ietf.org. Retrieved 2017-10-25.
  18. ↑ Daniel, Bailey; David, McGrew. "AES-CCM Cipher Suites for Transport Layer Security (TLS)". tools.ietf.org. Retrieved 2017-10-26.
  19. ↑ Perelmen, Vladislav (June 29, 2012). "Security in IPv6-enabled Wireless Sensor Networks: An Implementation of TLS/DTLS for the Contiki Operating System" (PDF): 38. Archived from the original (PDF) on August 29, 2017. Retrieved December 7, 2017.{{cite journal}}: Cite journal requires |journal= (help)
  20. ↑ Samuel, Weiler; John, Gilmore; Hannes, Tschofenig; Tero, Kivinen; Paul, Wouters. "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". tools.ietf.org. Retrieved 2017-12-07.
  21. ↑ RFC   5246, p. 41
  22. ↑ RFC   5246, pp. 42–43, 64
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.