Open main menu

Wikipedia β

A cipher suite is a set of algorithms that help secure a network connection that uses Transport Layer Security (TLS) or 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]

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 compared to others.[2]

The structure and use of the cipher suite concept is defined in the TLS standard document.[3] TLS 1.2 is the current version of TLS. The current draft for the next version of TLS (TLS 1.3) adds additional requirements to cipher suites. TLS 1.3 is not standardized so it is currently not widely used and may change. 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]

Contents

PurposeEdit

Cipher suites are used to coordinate between a client and server on which security algorithms to use when sending and receiving information from each other when using TLS and SSL. Using a TLS connection without a cipher suite would result in the data being sent without encryption and some forms of authentication. Cipher suites are used wherever a TLS or SSL connection exists such as with HTTPS, FTPS, POP3, and SMTP.

HistoryEdit

The use of ciphers have been a part of the Secure Socket Layer (SSL) transit protocol since its creation. SSL is the preceded version of TLS. However, the name Cipher Suite was not use 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 that the name Cipher Suite was used.[7] SSL v3 was the last version of SSL. Every version of TLS since has used Cipher Suite in their 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 which versions of the algorithms 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.

The proposed draft for 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 the draft of 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 historical versions and the current version of TLS.

Naming SchemeEdit

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_RSA_WITH_3DES_EDE_CBC_SHA

The meaning of this name is:

  • TLS defines the protocol that this cipher suite is for; it will usually be TLS.
  • RSA indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.[8]
  • 3DES_EDE_CBC indicates the block cipher being used to encrypt the message stream.[9]
  • SHA indicates the message authentication algorithm which is used to authenticate a message.[10]

Full Handshake: Coordinating Cipher SuitesEdit

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.[11] This selection process occurs during the TLS Handshake Protocol. The draft of TLS 1.3 includes a TLS Handshake Protocol that differs compared to past and the current version of TLS/SSL.[12]

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

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

TLS 1.0 - 1.2 HandshakeEdit

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

This protocol first starts 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 be able 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 coordinated with which cipher suite to use when communicating with each other.

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

Current Draft Proposal for TLS 1.3 HandshakeEdit

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.[2]

Supported AlgorithmsEdit

In TLS 1.0 - 1.2Edit

Algorithms Supported in TLS 1.0 - 1.2 Cipher Suites
Key exchange / agreement Authentication Block / Stream Ciphers Message Authentication
RSA RSA RC4 Hash-based MD5
Diffie-Hellman DSA Triple DES SHA Hash Function
ECDH ECDSA AES
SRP IDEA
PSK DES
Camellia

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

Current Draft Proposal for TLS 1.3Edit

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.[14] 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).[15] Non-AEAD encryption algorithms (such as AES_128_CBC) are not allowed to be used. These changes were done because of flaws or possible vulnerabilities discovered since that last release that could result in an insecure TLS connection.

DTLS with Cipher SuitesEdit

Datagram Transport Layer Security (DTLS) is based on TLS, but is specifically used for UDP connections instead of TCP connections. Since DTLS is based off 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.[16]

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

VulnerabilitiesEdit

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 is then vulnerable. Therefore, a common attack against TLS and cipher suites is known as a Down Grade 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.[18] 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 SSL3.0. The shortcoming with this fix is that it will make it so that some legacy hardware can not 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.[19]

Cipher Suites for Constrained DevicesEdit

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)[20]
  2. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (Raw Public Key)

Each of these cipher suites have 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 most encryption and security algorithms.[21] 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).[22]

Programming ReferencesEdit

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.[23] An example of how cipher_suite is usually used during the handshake process:
   struct {
       ProtocolVersion client_version;
       Random random;
       SessionID session_id;
       CipherSuite cipher_suites<2..2^16-2>;
       CompressionMethod compression_methods<1..2^8-1>;
       select (extensions_present) {
           case false:
               struct {};
           case true:
               Extension extensions<0..2^16-1>;
       };
   } ClientHello;
[24]
CipherSuite cipher_suite
the cipher suite selected by the server from the client's cipher_suites[25] An example of how cipher_suite is usually used during the handshake process:
      struct {
          ProtocolVersion server_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suite;
          CompressionMethod compression_method;
          select (extensions_present) {
              case false:
                  struct {};
              case true:
                  Extension extensions<0..2^16-1>;
          };
      } ServerHello;
[26]

ReferencesEdit

  1. ^ "Cipher Suites in TLS/SSL (Schannel SSP) (Windows)". msdn.microsoft.com. Retrieved 2017-10-26. 
  2. ^ "tls and ssl cipher suites | research | sprawl". www.thesprawl.org. Retrieved 2017-10-26. 
  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. ^ <tim@dierks.org>, Tim Dierks. "The Transport Layer Security (TLS) Protocol Version 1.2". tools.ietf.org. Retrieved 2017-10-26. 
  9. ^ <tim@dierks.org>, Tim Dierks. "The Transport Layer Security (TLS) Protocol Version 1.2". tools.ietf.org. Retrieved 2017-10-26. 
  10. ^ <tim@dierks.org>, Tim Dierks. "The Transport Layer Security (TLS) Protocol Version 1.2". tools.ietf.org. Retrieved 2017-10-26. 
  11. ^ Villanueva, John Carl. "An Introduction To Cipher Suites". Retrieved 2017-10-25. 
  12. ^ <ekr@rtfm.com>, Eric Rescorla. "The Transport Layer Security (TLS) Protocol Version 1.3". tools.ietf.org. Retrieved 2017-10-25. 
  13. ^ <tim@dierks.org>, Tim Dierks. "The Transport Layer Security (TLS) Protocol Version 1.2". tools.ietf.org. Retrieved 2017-10-26. 
  14. ^ "TLS 1.3 Protocol Support | wolfSSL Embedded SSL/TLS Library". wolfSSL. Retrieved 2017-10-26. 
  15. ^ E. Rescorla (November 4, 2016). "The Transport Layer Security (TLS) Protocol Version 1.3". Retrieved 2016-11-11. 
  16. ^ N., Modadugu,; E., Rescorla,. "Datagram Transport Layer Security". tools.ietf.org. Retrieved 2017-10-25. 
  17. ^ Eric, Rescorla,; Nagendra, Modadugu,. "Datagram Transport Layer Security Version 1.2". tools.ietf.org. Retrieved 2017-10-25. 
  18. ^ Bodo, Moeller,; Adam, Langley,. "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks". tools.ietf.org. Retrieved 2017-10-25. 
  19. ^ Bodo, Moeller,; Adam, Langley,. "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks". tools.ietf.org. Retrieved 2017-10-25. 
  20. ^ Daniel, Bailey,; David, McGrew,. "AES-CCM Cipher Suites for Transport Layer Security (TLS)". tools.ietf.org. Retrieved 2017-10-26. 
  21. ^ Perelmen, Vladislav (June 29, 2012). "Security in IPv6-enabled Wireless Sensor Networks: An Implementation of TLS/DTLS for the Contiki Operating System" (PDF): 38. 
  22. ^ 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. 
  23. ^ RFC 5246, p. 41
  24. ^ <tim@dierks.org>, Tim Dierks. "The Transport Layer Security (TLS) Protocol Version 1.2". tools.ietf.org. Retrieved 2017-10-26. 
  25. ^ RFC 5246, p. 42-43, 64
  26. ^ <tim@dierks.org>, Tim Dierks. "The Transport Layer Security (TLS) Protocol Version 1.2". tools.ietf.org. Retrieved 2017-10-26.