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.'' It was not until SSL v3 (the last version of SSL) that the name ''Cipher Suite'' was used. 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. 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 useTLS 1.0–1.2 handshake
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 usingTLS 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.Supported algorithms
In TLS 1.0–1.2
For more information about algorithms supported in TLS 1.0–1.2, see also: Transport Layer Security § Applications and adoptionTLS 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. 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). 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.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. 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.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 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. This has resulted in attacks such asCipher 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 theProgramming 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. An example of how ''cipher_suites'' is usually used during the handshake process:See also
*References
{{Reflist Secure communication Transport Layer Security