Selection of ciphersuites for TLS and Logjam vulnerability. Yandex experience

    Now, against the backdrop of the Logjam vulnerability, everyone in the industry is once again discussing 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é more than once about how we implement traffic encryption on Yandex services: for example, Eldar kyprizel Zaitov spoke about this in great detail , but ciphersiutes were one of the things that at that time remained mostly behind the scenes. By the way, I want to reassure everyone and say that on Yandex servers the export version of the Diffie-Hellman algorithm has never been used. 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;
    • the actually 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 review the process of initializing a TLS connection as applied to HTTPS (of course, TLS is possible for other TCP and UDP protocols, but we will not consider this now). For details, see RFC5246 .

    image


    TLS has its own message division mechanism called record protocol. Each TLS message does not have to be equal to the TCP segment, it can be more or less.

    The TLS connection begins with the client by forwarding the ClientHello message. The most interesting part of the ClientHello message for us is just the list of ciphersuite supported by the client. The client also sends a list of elliptic curves known to him.

    Clienthello

    In response, the server forwards the ServerHello message containing the selected ciphersuite:

    Serverhello

    In this case, it is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. This option means that the 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 . An attentive reader will notice that GCM is an AEAD algorithm and thus does not require an additional MAC function. Why is it needed? The answer lies in the mechanism for generating session keys, but first, let's discuss some options for 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, you can use:
    • the classic Diffie-Hellman algorithm, it is denoted by DH and DHE;
    • a variant of the Diffie-Hellman algorithm on elliptic curves; it is denoted by ECDH and ECDHE;
    • random number generation by the client and its subsequent encryption on the public key of the server, in real situations, RSA is almost always used.

    The difference between DH options without the suffix E and with the suffix E is the ephemerality of the key. In the case of DHE and ECDHE, the key is really generated during a full-fledged 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 any) is the private key for DH exchange and thus the PFS property is not achieved.

    RSA is used almost exclusively as an authentication algorithm in practical realities. ECDSA takes the first steps, but we hope that it will be more widespread.

    As symmetric encryption algorithms, AES with a key length of 128 and 256 bits in CBC and GCM, RC4 and 3DES modes are widespread. You can meet ciphersuite with a single DES, CHACHA20and even NULL - this means that no encryption will actually be applied.

    As MAC algorithms, MD5, SHA1, SHA256 and, rarely, SHA384 are found.

    As mentioned above, in the case of the AES encryption algorithm in GCM mode, integrity control is provided by the encryption mode itself. Therefore, there is no need for a separate MAC function. In RFC on TLS1.2it is specifically indicated that in addition to 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 by a particular DH variant or is simply generated by a client, it is called a pre-master key. After receiving the pre-master key based on it (as well as based on 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, all the necessary key material is calculated from the master key using the same PRF function: keys for encryption algorithms, keys for MAC, initialization vectors.

    Ciphersuites in real life


    Now that the basic theory is clear, let's look at the ciphersuites settings on some popular sites. You can use the SSLLabs scanner for this , although we use a tool written by kyprizel in Yandex for our internal needs . In principle, you can use the openssl s_client command with the -cipher switch or try cipherscan , which is essentially a bash wrapper to call openssl.

    In order to test ciphersuites variants locally, it is convenient to use the openssl ciphers command , which will allow you to see what exactly the proposed set of conditions for ciphersuite will turn into.

    So, actually, 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 modern ciphersuites with the generation of a pre-master key via 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 options for ECDHE ciphersuites come options with AES encryption, but without PFS. Such options are used by browsers like the old Opera (version 12.x), and therefore we are forced to save them.

    Then comes 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 XPES with SP3 finally introduced 3DES support- An outdated but still robust encryption algorithm. Finally, for the unfortunate 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, therefore it is available only in the case of a handshake using 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 customers and the need to maintain old ones.

    A different situation 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 the 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 the same, but the tradeoff is shifted towards more security and less compatibility with older browsers. First up-to-date ciphersuite for TLS1.2: our favorite ECDHE + AES128 in GCM mode, then the same, but in CBC mode and, finally, the option 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 refuse it, so in the Mail we started a campaign to update user browsers . If you are setting 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 where there were browsers that still preferred it and probably did not have ECDH support (at one time it was related to Firefox on RedHat Linux, where for legal reasons there were no protocols with elliptic cryptography). At the same time, long before the publication of the Logjam attack , we understood the need to align key lengths and the futility of using 1024-bit DH with 2048-bit RSA keys in certificates. Therefore , DHE is available on passport.yandex.ru, but 2048-bitgenerated 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 versions, then DH with AES, then AES without PFS, and finally fallback in 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


    In general, I understand the logic of priorities: first ECDH and AES. Please note that Google decided to try the CHACHA20 cipher, which 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. Needless to say, dominance has its advantages - by controlling both the service and the platform, you can do things inaccessible to others. Interestingly, Google uses its fork of OpenSSL called BoringSSL . Its useful feature is the ability to set ciphersuites of equal priority. 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 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, understandable logic, very similar to ours in the Mail: first ECDHE, why AES without PFS and fallback on 3DES.

    The logic on vk.com is not clear to me. It seems that they just took all the ciphers and threw MD5 and RC4 out of 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


    Mail.ru first has ECDHE, then DHE, then ciphers without PFS, but again CAMELLIA, SEED. It seems that here no one chose ciphersuites , but relied on the options offered by OpenSSL by default.

    Interestingly, until recently, the nsa.gov server 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 on 3DES Similarly looks https on the CIA website . It's funny that https does not work at all on the FSB and SVR websites.

    However, in my personal assessment, the site with the worst ciphersuites on the Internet was the site of the Moscow Government Government Services login.mos.ru. At one time, he offered ciphersuite TLS_NULL_WITH_NULL_NULL - that is, without authentication and without encryption. However, measures have now been taken: the delay in setting up a TLS connection with sslabs.com is set in such a way that the scanner falls off by timeout. But ciphersuites are corrected, although RC4-MD5, RC4-SHA and 3DES-SHA are the highest priority, ECDH can be found in the list - this can be checked manually with the openssl s_client command with the -cipher switch.

    Recommendations for choosing ciphersuite


    What settings can I recommend to a regular site? Here 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 that our system administrators consult with the information security service 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.

    Also popular now: