Now that it is 2015, what SSL/TLS cipher suites should be used in a high security HTTPS environment?

  • It has become quite difficult to configure an HTTPS service that maintains "the ideal transport layer". How should an HTTPS service be configured to permit some reasonable level of compatibility while not being susceptible to even minor attacks?

    TLS downgrade attacks in combination Beast, Crime, Breach, and Poodle knocks out most if not all of SSLv3 and prior. Microsoft is disabling SSLv3 by default, which sounds like a good move to me. Due to weaknesses in RC4, MD5, and SHA1, there are even fewer cipher suites to choose from.

    Would an 'ideal' HTTPS service only enable TLS 1.0, 1.1 and 1.2 with key-size variants following ciphers? What should be the most preferred cipher suite?

    TLS_RSA_WITH_AES_128_CBC_SHA256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
    TLS_RSA_WITH_AES_128_GCM_SHA256
    TLS_DH_RSA_WITH_AES_128_GCM_SHA256
    

    Two out of five do not provide PFS.

    Further infos: MSFT security advisory to disable RC4. Logjam attack: diffie-hellman could be unsafe de en

    @LamonteCristo how ironic is it that this site does not use HTTPS? :D

    @SteveDL right?! At least it lets me see this on captive networks.

    @SteveDL I guess I'm too late, but it does use HTTPS now :)

  • Would an 'ideal' HTTPS service only enable TLS 1.0, 1.1 and 1.2 with key-size variants following ciphers?

    No, an 'ideal' HTTPS service would enable only TLS 1.2 and enable only AEAD (Authenticated Encryption with Associated Data) based cipher suites with SHA-2, 4096 bit DH parameters and 521 bit EC curves of a type that matches your requirements (government approved or not government generated).

    Said service would also be unable to connect be used by a wide variety of older clients, including Android 4.3 and earlier, IE 10 and earlier, Java 7 (at least u25) and earlier), OpenSSL 0.9.8y and earlier (OpenSSL 1.0.0 is simply not listed on my source), and so on. It would, however, be immune to any attack that works only on TLS 1.1 and below, any attack relying on SHA-1, and any attack relying on CBC mode or outdated ciphers like RC4.

    Client cipher suite limitations per https://www.ssllabs.com.

    What should be the most preferred cipher suite?

    It depends!

    I assume Foward Secrecy is a requirement.

    I assume "believed to be reasonably secure at this time" is a requirement.

    I assume "actually implemented by at least one major actor" is a requirement.

    All requirements regarding must have/cannot use some or another subset of ciphers (must use X, can't use Y, etc.).

    Thus, I would propose the following lists as a reasonable start. Begin with the top category (TLS 1.2 AEAD), then keep going down the list and adding categories until you reach a level that works with your userbase or you've reached the end of your comfort zone, whichever comes first.

    Include as many cipher suites of each category as you can, so that when the next attack rolls around, you'll be able to remove the affected cipher suites and continue with the remainder.

    Keep an eye on the threat environment so you can continue removing cipher suites that demonstrate vulnerabilities.

    Within each major category, please order or cull the cipher suites according to your taste: DHE is of course slower than ECDHE, but takes elliptic curve provenance out entirely, and so on. At this time, it appears that ordering is a tradeoff, but if you want speed, prefer or even require TLS_ECDHE_*. If you don't trust the currently commonly implemented elliptic curves, or are concerned about elliptic curves due to the NSA Suite B guidance from Aug 2015 indicating a move away from prior Suite B elliptic curves is coming in the near future, and are willing to burn CPU, prefer or even require TLS_DHE_* suites.

    Bear in mind that "normal" certificates are RSA certificates, which work with both TLS_ECDHE_RSA_* and TLS_DHE_RSA_* cipher suites. DSA certificates which work with TLS_ECDHE_ECDSA_* cipher suites are very rare so far, and many CA's don't offer them.

    • TLS 1.2 AEAD only (all are SHA-2 as well)
      • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (new 0xcca9, Pre-RFC7905 0xcc14)
      • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (new 0xcca8, Pre-RFC7905 0xcc13)
      • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (new 0xccaa, Pre-RFC7905 0xcc15)
      • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
      • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
        • For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-3
      • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
      • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
      • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
        • For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5
      • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
        • For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5
      • These are the highest level of security I'm currently aware of in common TLS implementations.
      • As of Jan 2017, major modern browsers DO handle this level, including but not limited to Android with 6.0 supporting AES-GCM and - alone of the main ones - old valued CHACHA20-POLY1305 and 7.0 supporting new CHACHA20-POLY1305, Chrome with both AES-GCM and CHACHA20-POLY1305, Firefox with both AES-GCM and CHACHA20-POLY1305, IE and Edge with only AES-GCM, Java with only AES-GCM, OpenSSL 1.1.0 with both AES-GCM and CHACHA20-POLY1305, Safari with only AES-GCM).
      • Many major browsers cannot handle this, even 2015 vintage ones (Safari 7 on OSX 10.9, Android 4.3 and earlier, IE 10 on Win7 (IE 11 even on Win7 will support 0x9f and 0x9e if Windows has been patched)
    • TLS 1.2 SHA2 family (non-AEAD)
      • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
      • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
      • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
      • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
        • For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-3
      • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
        • For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 may category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5
      • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
        • For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5
      • TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (0xc077)
      • TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0xc076)
      • TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0xc4)
      • Note that you've lost AEAD mode and are using the much older CBC mode; this is less than ideal. CBC mode has been a contributing factor for several attacks in the past, including Lucky Thirteen and BEAST, and it's not unreasonable to believe that CBC mode may be related to future vulnerabilities also.
      • Some modern browsers that don't have any AEAD cipher suites do have one more more suited in this category, for instance, IE 11 on Win7 can use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 and Safari 6 and 7 can use a few of these
        • again, this is if you don't have ECDHE_ECDSA GCM suites working)
    • TLS 1.0 and 1.1 with modern ciphers (and outdated hashes, since that's all that's available)
      • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
        • For U.S. folks who are interested in NIST compliance, this is a may category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-2
      • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
        • For U.S. folks who are interested in NIST compliance, this is a should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-2
      • TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
      • TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
      • TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)
      • TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)
      • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
      • Once you're including cipher suites from this level, you're likely to find something that works with almost all modern implementations.
      • At this level, you're not only using CBC mode, you're also using SHA-1. NIST SP800-131A recommended that SHA-1 be disallowed for digital signature generation after Dec 31, 2013 (a year ago today, actually).
    • TLS 1.0 and 1.1 with older but still reasonable ciphers and outdated hashes
      • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
      • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
        • For U.S. folks who are interested in NIST compliance, this is a should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-2
      • TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
        • For U.S. folks who are interested in NIST compliance, this is a should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-4
      • IE 8 on Windows XP is still out of luck, as is Java 6u45 due to DH parameter maximums.
      • This is absolutely the minimum level I'd recommend going to.
    • Note that for servers using RSA private keys and RSA certificates who need NIST SP800-52 revision 1 compliance, you SHALL, should, and may implement specific other TLS_RSA_* cipher suites which DO NOT PROVIDE forward secrecy, and thus I would not recommend unless this compliance is required.
      • Note also that paragraph 3.3.1 of that document states specific "The server shall be configured to only use cipher suites that are composed entirely of Approved algorithms. A complete list of acceptable cipher suites for general use is provided in this section..."
    • Other national and industry requirements will vary, of course.
      • and may conflict with each other; read all of those that apply to you carefully.

    I'll put in the usual plug here - try out your cipher list with your own tools (openssl ciphers -v '...' for openssl based systems), go to https://www.ssllabs.com/index.html first to check on cipher suites supported by various clients, then set up your site, and then go back to www.ssllabs.com and run their server test.

    Note that _ECDSA_ cipher suites require ECDSA certificates, of course, and those are still very hard to find.

    ETA: NSA Suite B EC advice, and IE 11/Win7 now supports 0x9f and 0x9e.

    ETA: As of Jan 2016, NIST SP800-52r1 is unchanged, and one new cipher suite (0xc00a) has been added to the list.

    ETA: As of Jan 2017, RFC7905 has change the three TLS 1.2 AEAD CHACHA20-POLY1305 ciphers, and "modern" browsers have drastically improved AEAD support as noted in new bullet. See https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 for up to date IANA cipher suites.

    This is the best answer so far. SHA1 is still a NIST approved algorithm, but should we be using it? Ideal is not so much keysize, but does the protocol suffer some non-trivial attack? SHA1 suffers from a non-trivial attack.

    @Rook, thank you! NIST SP800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths , published January of 2011, states that SHA-1 is disallowed for digital signature generation after Dec 31, 2013. For another reference, IBM Security Access Manager for Mobile 8.0 allows only TLS 1.2 in strict mode.

    @Rook HMAC-SHA-1 used as MAC is nowhere close to being broken (neither is HMAC-MD5). SHA-1 is only broken if you need collision resistance, such as the digital signatures used with certificates.

    @CodesInChaos That is a good point, and it is not feasible to generate a second-pre-image in the relatively short lifespan of an HTTPS connection, it is just not the right type of bug... Unfortunately, this question is more geared towards the financial world where there are strict interpretations of what it means to be secure.

    This is exactly what I was looking for. Good job, I like the updates.

    I cannot find the OpenSSL equivalent name for TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 either here or here. Does anyone know (how to get) the corresponding OpenSSL name?

    Late but FYI: OpenSSL 1.0.0 doesn't support TLS 1.1 or 1.2; 1.0.1 up does, including SHA2 and GCM but not CCM, and ChaCha-Poly is only in 1.1.0. Oracle/OpenJDK Java 7 _does_ implement TLS 1.1 and 1.2 (but not AEAD) but _client_ side does not _enable_ them by default so you must tweak your code and/or config. Also Java 7 supports DHE only up to 1024; Java 8 supports 2048 but not more (not 4096). Java 7 or 8 does support ECDHE with all named curves including P521, as does OpenSSL. @JanDoggen: OpenSSL (currently) implements rfc4137 but not 5932 and 6367 thus excluding the suite you asked about.

    There were some recent findings about vulnerabilities with CBC ciphers (here and here) so you might update the answer.

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM