Choosing ciphersuites for TLS and Logjam vulnerability. Yandex experience
Now, against the background of the Logjam vulnerability, everyone in the industry once again discusses the problems and features of TLS. I want to take this opportunity to talk about one of them, namely about setting up ciphersiutes. We have already written on Habré how to implement traffic encryption on Yandex services: for example, Eldar kyprizel Zaitov spoke in great detail about this, but ciphersiutes were one of the things that were mostly behind the scenes at that time. By the way, I want to reassure everyone and say that the Yandex version of the Diffie-Hellman algorithm has never been used on Yandex servers.
So, Ciphersuite is a set of algorithms used in a particular TLS – session. These include:
In order to understand the role of each of the algorithms, let's briefly consider the process of TLS – connection initialization as applied to HTTPS (of course, TLS is possible for other TCP and UDP protocols, but for now we will not consider this). For details, contact RFC5246 .
')
TLS has its own message division mechanism called record protocol. Each TLS message does not need to be equal to a TCP segment, it can be more or less.
The TLS connection is started by the client — by forwarding the ClientHello message The most interesting part of the ClientHello message for us is the list of ciphersuite supported by the client. The client also sends a list of known elliptic curves.
In response, the server sends a ServerHello message containing the selected ciphersuite:
In this case, this is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. This option means that Diffie-Hellman algorithm on elliptic curves will be used to generate session keys, server authentication will be performed using RSA, and AES with a key length of 128 bits in GCM mode will be used as a traffic encryption algorithm. The attentive reader will notice that GCM is an AEAD algorithm and thus does not require the additional MAC function. Why is it needed? The answer lies in the mechanism for generating session keys, but first let's discuss some variants of each algorithm in ciphersuite. A complete list of all possible options is available on the IANA website .
So, as an algorithm for generating session keys can be used:
The difference between the DH variants without the E suffix and with the E suffix is ​​in the ephemerality of the key. In the case of DHE and ECDHE, the key is actually generated during the full DH exchange, where the encryption parameters are not saved and thus the PFS property is achieved. In ciphersuites DH and ECDH, the private key of the server (and the client, if one exists) is the private key for the DH exchange and thus the PFS property is not achieved.
As a real-time authentication algorithm, RSA is used almost exclusively, ECDSA takes the first steps, but we hope that it will be more common.
As symmetric encryption algorithms, AES with key lengths of 128 and 256 bits are widely used in CBC and GCM, RC4 and 3DES modes. One can come across ciphersuite with a single DES, CHACHA20 and even NULL - this means that no encryption will actually be used.
The MAC algorithms include MD5, SHA1, SHA256 and, rarely, SHA384.
As mentioned above, in the case of the AES encryption algorithm in GCM mode, integrity control is provided by the actual encryption mode. Therefore, there is no need for a separate MAC function. The RFC on TLS1.2 specifically states that besides the authentication function itself, the MAC algorithm in ciphersuite also performs the role of a pseudo-random function (PRF). When a random number between a client and a server is generated at the expense of one or another DH option or is simply generated by the client, it is called the pre-master key. After receiving the pre-master key based on it (as well as on the basis of random values ​​from the ClientHello and ServerHello messages), the master key is generated by applying the PRF function: master_secret = PRF (pre_master_secret, “master secret”, ClientHello.random + ServerHello.random) . Subsequently, from the master key, using the same PRF function, all the necessary key material is calculated: keys for encryption algorithms, keys for MAC, initialization vectors.
Now that the basic theory is clear, let's look at the ciphersuites settings on some popular sites. To do this, you can use the SSLLabs scanner , although in Yandex we use the kyprizel tool written for internal use. In principle, you can use the openssl s_client command with the -cipher key or try cipherscan , which is essentially a bash wrapper to call openssl.
In order to test the ciphersuites variants locally, it is convenient to use the openssl ciphers command, which will allow you to see what the proposed set of ciphersuite conditions will turn into.
So, in fact, Yandex. The list of ciphersuites supported by the server is quite large:
First come the modern ciphersuites with the development of a pre-master key through ECDHE. We prefer AES-128 in GCM mode. I personally do not see much benefit from AES256, but for yandex.ru we saved this set of ciphers for more paranoid users. After various variants of ECDHE ciphersuites, there are options with AES encryption, but without PFS. Such options are used by browsers like the old Opera (version 12.x), and therefore we have to save them.
Then there are two options with 3DES encryption: we save them primarily for Internet Explorer browsers on Windows XP with SP3 installed. Internet Explorer uses the Schannel system library, and XP with SP3 has finally added support for 3DES , an outdated, but still robust encryption algorithm. Finally, for accidents with Internet Explorer 6 on XP, we save RC4 ciphers — there are simply no other options on this platform. At the same time, we are aware of the likelihood that this cipher is vulnerable, so it is available only in the case of the handshake via the SSLv3 protocol. If the client connects with a more modern protocol - TLS 1.0, TLS 1.1 or TLS 1.2 - RC4-based ciphersuite is not offered.
Search servers thus offer a tradeoff between security for modern clients and the need to maintain old ones.
The situation is different on Yandex.Mail servers. Here, for example, the team made a product decision not to support IE6 (even in the so-called “light” layout) and this was reflected in support at the TLS level:
The logic is kept the same, but the tradeoff is shifted to greater security and less compatibility with older browsers. First, modern ciphersuite for TLS1.2: our favorite ECDHE + AES128 in GCM mode, then the same, but in CBC mode and, finally, a variant with a weaker SHA1. The following three options are the same, but without PFS. Closes the ciphersuite set for IE8: 3DES in CBC mode with SHA1 and without PFS. We really want to give it up, so in the Mail we started a campaign to update the users' browsers . If you set up computers for your parents, do not be lazy - install a modern browser. Do the same in your organization.
Another option is Yandex.Passport. Here we tried to keep the classic DH, because we noticed situations when there were browsers that still preferred it and might not have ECDH support (at one time it related to Firefox on RedHat Linux, where for legal reasons there were no protocols with elliptical cryptography). At the same time, long before the publication of the Logjam attack , we understood the need for leveling the key lengths and the uselessness of using 1024-bit DH with 2048-bit RSA keys in certificates. Therefore , DHE is available on passport.yandex.ru, but 2048-bit , generated specifically for this case, and the service is not affected by Logjam. The rest of the logic is the same: first ECDH with AES in various ways, then DH with AES, then AES without PFS, and finally fallback to 3DES without PFS.
Let's look at "their morals." Here is an example from gmail.com .
I generally understand the logic of priorities: first ECDH and AES. Please note that Google decided to try the CHACHA20 cipher I wrote about above. It seems to me that his main goal is to ease the load on the CPU (and, accordingly, power consumption) in Android smartphones. Of course, dominance has its advantages - by controlling both the service and the platform, you can do things that are inaccessible to others. Interestingly, Google uses its openSSL fork called BoringSSL . Its useful feature is the ability to set equal priority ciphersuites. So in this case (although ssllabs does not show this), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 have equal priority and among them the client determines which ciphersuite considers a priority.
Here is twitter.com :
And again the clear logic is very similar to ours in the Post: first ECDHE, why AES without PFS and fallback on 3DES.
The logic on vk.com is incomprehensible to me. It seems that they simply took all the ciphers and threw out MD5 and RC4 from them. I think a similar set can be obtained with the openssl ciphers 'ALL:! RC4:! MD5' command. CAMELLIA code? Are serious?
At mail.ru, first ECDHE, then DHE, then ciphers without PFS, but again - CAMELLIA, SEED. It seems, and here no one chose ciphersuites , but relied on the options offered by OpenSSL by default.
Interestingly, until recently nsa.gov had a very weak set of ciphersuites, the best option there was RC4 without PFS, but now the situation has been fixed with the same logic as ours: ECDHE and AES, RSA and AES, fallback to 3DES. Similarly, https on the CIA website . It's funny that https does not work at all on the sites of the FSB and SVR.
However, according to my personal assessment, the website with the state services of the Moscow government, login.mos.ru, was the site with the worst ciphersuites in the Internet. At one time, he offered ciphersuite TLS_NULL_WITH_NULL_NULL - that is, without authentication and without encryption. However, measures are now taken: the delay in establishing a TLS connection with sslabs.com is set so that the scanner falls off on timeout. But ciphersuites have been fixed, although RC4-MD5, RC4-SHA and 3DES-SHA are top priorities, ECDH can be found in the list - this can be checked manually with the openssl s_client command with the -cipher key.
What settings can I recommend a regular site? This is the recommended nginx config we use in Yandex by default:
If you need IE8 support on XP, you can use this set, it will enable 3DES:
If you need IE6 support on XP, you can enable RC4, but in such cases, we recommend our system administrators to consult with the information security service in order to accurately represent their risks. I'm not sure that some sites outside the first fifty of the most popular in runet really need such support.
By the way, you will find interesting ciphersuite settings on the Internet, write.
So, Ciphersuite is a set of algorithms used in a particular TLS – session. These include:
- algorithm for generating session encryption keys;
- the algorithm used to authenticate the server;
- proper symmetric traffic encryption algorithm;
- and finally, the integrity control algorithm (MAC, message authentication code).
In order to understand the role of each of the algorithms, let's briefly consider the process of TLS – connection initialization as applied to HTTPS (of course, TLS is possible for other TCP and UDP protocols, but for now we will not consider this). For details, contact RFC5246 .
')
TLS has its own message division mechanism called record protocol. Each TLS message does not need to be equal to a TCP segment, it can be more or less.
The TLS connection is started by the client — by forwarding the ClientHello message The most interesting part of the ClientHello message for us is the list of ciphersuite supported by the client. The client also sends a list of known elliptic curves.
In response, the server sends a ServerHello message containing the selected ciphersuite:
In this case, this is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. This option means that Diffie-Hellman algorithm on elliptic curves will be used to generate session keys, server authentication will be performed using RSA, and AES with a key length of 128 bits in GCM mode will be used as a traffic encryption algorithm. The attentive reader will notice that GCM is an AEAD algorithm and thus does not require the additional MAC function. Why is it needed? The answer lies in the mechanism for generating session keys, but first let's discuss some variants of each algorithm in ciphersuite. A complete list of all possible options is available on the IANA website .
So, as an algorithm for generating session keys can be used:
- Diffie-Hellman's classical algorithm, it is denoted DH and DHE;
- variant of the Diffie-Hellman algorithm on elliptic curves, it is denoted ECDH and ECDHE;
- generation of a random number by the client and its subsequent encryption on the server’s public key; in real situations, RSA is almost always used.
The difference between the DH variants without the E suffix and with the E suffix is ​​in the ephemerality of the key. In the case of DHE and ECDHE, the key is actually generated during the full DH exchange, where the encryption parameters are not saved and thus the PFS property is achieved. In ciphersuites DH and ECDH, the private key of the server (and the client, if one exists) is the private key for the DH exchange and thus the PFS property is not achieved.
As a real-time authentication algorithm, RSA is used almost exclusively, ECDSA takes the first steps, but we hope that it will be more common.
As symmetric encryption algorithms, AES with key lengths of 128 and 256 bits are widely used in CBC and GCM, RC4 and 3DES modes. One can come across ciphersuite with a single DES, CHACHA20 and even NULL - this means that no encryption will actually be used.
The MAC algorithms include MD5, SHA1, SHA256 and, rarely, SHA384.
As mentioned above, in the case of the AES encryption algorithm in GCM mode, integrity control is provided by the actual encryption mode. Therefore, there is no need for a separate MAC function. The RFC on TLS1.2 specifically states that besides the authentication function itself, the MAC algorithm in ciphersuite also performs the role of a pseudo-random function (PRF). When a random number between a client and a server is generated at the expense of one or another DH option or is simply generated by the client, it is called the pre-master key. After receiving the pre-master key based on it (as well as on the basis of random values ​​from the ClientHello and ServerHello messages), the master key is generated by applying the PRF function: master_secret = PRF (pre_master_secret, “master secret”, ClientHello.random + ServerHello.random) . Subsequently, from the master key, using the same PRF function, all the necessary key material is calculated: keys for encryption algorithms, keys for MAC, initialization vectors.
Real life ciphersuites
Now that the basic theory is clear, let's look at the ciphersuites settings on some popular sites. To do this, you can use the SSLLabs scanner , although in Yandex we use the kyprizel tool written for internal use. In principle, you can use the openssl s_client command with the -cipher key or try cipherscan , which is essentially a bash wrapper to call openssl.
In order to test the ciphersuites variants locally, it is convenient to use the openssl ciphers command, which will allow you to see what the proposed set of ciphersuite conditions will turn into.
So, in fact, Yandex. The list of ciphersuites supported by the server is quite large:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA (0x5) TLS_ECDHE_RSA_WITH_RC4_128_SHA First come the modern ciphersuites with the development of a pre-master key through ECDHE. We prefer AES-128 in GCM mode. I personally do not see much benefit from AES256, but for yandex.ru we saved this set of ciphers for more paranoid users. After various variants of ECDHE ciphersuites, there are options with AES encryption, but without PFS. Such options are used by browsers like the old Opera (version 12.x), and therefore we have to save them.
Then there are two options with 3DES encryption: we save them primarily for Internet Explorer browsers on Windows XP with SP3 installed. Internet Explorer uses the Schannel system library, and XP with SP3 has finally added support for 3DES , an outdated, but still robust encryption algorithm. Finally, for accidents with Internet Explorer 6 on XP, we save RC4 ciphers — there are simply no other options on this platform. At the same time, we are aware of the likelihood that this cipher is vulnerable, so it is available only in the case of the handshake via the SSLv3 protocol. If the client connects with a more modern protocol - TLS 1.0, TLS 1.1 or TLS 1.2 - RC4-based ciphersuite is not offered.
Search servers thus offer a tradeoff between security for modern clients and the need to maintain old ones.
The situation is different on Yandex.Mail servers. Here, for example, the team made a product decision not to support IE6 (even in the so-called “light” layout) and this was reflected in support at the TLS level:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA The logic is kept the same, but the tradeoff is shifted to greater security and less compatibility with older browsers. First, modern ciphersuite for TLS1.2: our favorite ECDHE + AES128 in GCM mode, then the same, but in CBC mode and, finally, a variant with a weaker SHA1. The following three options are the same, but without PFS. Closes the ciphersuite set for IE8: 3DES in CBC mode with SHA1 and without PFS. We really want to give it up, so in the Mail we started a campaign to update the users' browsers . If you set up computers for your parents, do not be lazy - install a modern browser. Do the same in your organization.
Another option is Yandex.Passport. Here we tried to keep the classic DH, because we noticed situations when there were browsers that still preferred it and might not have ECDH support (at one time it related to Firefox on RedHat Linux, where for legal reasons there were no protocols with elliptical cryptography). At the same time, long before the publication of the Logjam attack , we understood the need for leveling the key lengths and the uselessness of using 1024-bit DH with 2048-bit RSA keys in certificates. Therefore , DHE is available on passport.yandex.ru, but 2048-bit , generated specifically for this case, and the service is not affected by Logjam. The rest of the logic is the same: first ECDH with AES in various ways, then DH with AES, then AES without PFS, and finally fallback to 3DES without PFS.
Let's look at "their morals." Here is an example from gmail.com .
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA I generally understand the logic of priorities: first ECDH and AES. Please note that Google decided to try the CHACHA20 cipher I wrote about above. It seems to me that his main goal is to ease the load on the CPU (and, accordingly, power consumption) in Android smartphones. Of course, dominance has its advantages - by controlling both the service and the platform, you can do things that are inaccessible to others. Interestingly, Google uses its openSSL fork called BoringSSL . Its useful feature is the ability to set equal priority ciphersuites. So in this case (although ssllabs does not show this), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 have equal priority and among them the client determines which ciphersuite considers a priority.
Here is twitter.com :
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA And again the clear logic is very similar to ours in the Post: first ECDHE, why AES without PFS and fallback on 3DES.
The logic on vk.com is incomprehensible to me. It seems that they simply took all the ciphers and threw out MD5 and RC4 from them. I think a similar set can be obtained with the openssl ciphers 'ALL:! RC4:! MD5' command. CAMELLIA code? Are serious?
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA TLS_RSA_WITH_CAMELLIA_128_CBC_SHA At mail.ru, first ECDHE, then DHE, then ciphers without PFS, but again - CAMELLIA, SEED. It seems, and here no one chose ciphersuites , but relied on the options offered by OpenSSL by default.
Interestingly, until recently nsa.gov had a very weak set of ciphersuites, the best option there was RC4 without PFS, but now the situation has been fixed with the same logic as ours: ECDHE and AES, RSA and AES, fallback to 3DES. Similarly, https on the CIA website . It's funny that https does not work at all on the sites of the FSB and SVR.
However, according to my personal assessment, the website with the state services of the Moscow government, login.mos.ru, was the site with the worst ciphersuites in the Internet. At one time, he offered ciphersuite TLS_NULL_WITH_NULL_NULL - that is, without authentication and without encryption. However, measures are now taken: the delay in establishing a TLS connection with sslabs.com is set so that the scanner falls off on timeout. But ciphersuites have been fixed, although RC4-MD5, RC4-SHA and 3DES-SHA are top priorities, ECDH can be found in the list - this can be checked manually with the openssl s_client command with the -cipher key.
Ciphersuite Selection Guidelines
What settings can I recommend a regular site? This is the recommended nginx config we use in Yandex by default:
ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers kEECDH+AESGCM+AES128:kEECDH+AES128:kRSA+AESGCM+AES128:kRSA+AES128:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; If you need IE8 support on XP, you can use this set, it will enable 3DES:
ssl_ciphers kEECDH+AESGCM+AES128:kEECDH+AES128:kRSA+AESGCM+AES128:kRSA+AES128:kRSA+3DES:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; If you need IE6 support on XP, you can enable RC4, but in such cases, we recommend our system administrators to consult with the information security service in order to accurately represent their risks. I'm not sure that some sites outside the first fifty of the most popular in runet really need such support.
By the way, you will find interesting ciphersuite settings on the Internet, write.
Source: https://habr.com/ru/post/258673/
All Articles