108

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
Community
  • 1
rook
  • 46,916
  • 10
  • 92
  • 181

4 Answers4

110

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.

Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
  • 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 Dec 30 '14 at 15:55
  • 1
    @Rook, thank you! [NIST SP800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths ](http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf), 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] (https://www-01.ibm.com/support/knowledgecenter/SSELE6_8.0.0.4/com.ibm.isam.doc_8.0.0.4/config/concept/nist_support.html) allows only TLS 1.2 in strict mode. – Anti-weakpasswords Dec 31 '14 at 01:11
  • 3
    @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 Jan 02 '15 at 16:49
  • @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. – rook Jan 06 '15 at 18:15
  • This is exactly what I was looking for. Good job, I like the updates. – rook Jan 07 '15 at 17:31
  • this is also very helpful: https://mozilla.github.io/server-side-tls/ssl-config-generator – warren Feb 29 '16 at 20:01
  • I cannot find the OpenSSL equivalent name for TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 either [here](https://testssl.sh/openssl-rfc.mappping.html) or [here](https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-SUITE-NAMES). Does anyone know (how to get) the corresponding OpenSSL name? –  Apr 04 '16 at 09:07
  • 1
    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. – dave_thompson_085 Oct 28 '16 at 01:29
  • There were some recent findings about vulnerabilities with CBC ciphers ([here](https://blog.qualys.com/technology/2019/04/22/zombie-poodle-and-goldendoodle-vulnerabilities) and [here](https://www.tripwire.com/state-of-security/vert/tls-cbc-padding-oracles)) so you might update the answer. – Stoinov Apr 27 '19 at 11:25
13

I'd usually not answer with just a link, but since answers to this questions are changing so often I am doing so. Also, the 'ideal' cipher suite completely depends on the application and target audience. Which do you control, which choices are you able to and can you afford to make (e.g. do you need to support IE6?), these all influence the 'ideal' answer.

Anyway, https://cipherli.st/ has a nice summary of cipher suites and configuration samples for popular applications. As others pointed out, Qualys SSLLabs has a nice tool for testing your configuration and has some nice explanations.

Teun Vink
  • 6,788
  • 2
  • 27
  • 35
7

A good starting point is Mozilla recommended TLS ciphers.

A good way to test the security of public HTTPS websites is Qualys SSL Labs, this site also contains many articles on TLS/SSL (with focus on HTTPS).

Rap
  • 137
  • 1
  • 8
DavisNT
  • 194
  • 6
  • 3
    Some of the ciphers listed for "Modern compatibility" rely upon broken primitives. – rook Dec 28 '14 at 22:10
  • @Rook Which ones rely on broken primitives? – cpast Dec 28 '14 at 22:19
  • 1
    @cpast - the DSS ciphers on the Mozilla list, at least, were a massive red flag for me, since DSS implementations are limited to 1024 bit DSA keys; far, far too short to be considered secure now. – Anti-weakpasswords Dec 29 '14 at 04:45
  • @Rook and thus a very good example why there's no such thing as an "ideal" set of cipher suites. As others have pointed out, the answer is quite subjective. There's no one single answer. Someone could probably select 3-4 different use cases though for different scenarios. High compatibility, high security, low processor usage. Pick your values, and you can answer the question. In the absence of values, values will be assumed. – Steve Sether Jan 02 '15 at 20:28
1

Update 2016 via SSL Labs:

You should rely chiefly on the AEAD suites that provide strong authentication and key exchange, forward secrecy, and encryption of at least 128 bits. Some other, weaker suites may still be supported, provided they are negotiated only with older clients that don't support anything better.

There are several obsolete cryptographic primitives that must be avoided:

Anonymous Diffie-Hellman (ADH) suites do not provide authentication.

  • NULL cipher suites provide no encryption.
  • Export cipher suites are insecure when negotiated in a connection, but they can also be used against a server that prefers stronger suites (the FREAK attack).
  • Suites with weak ciphers (typically of 40 and 56 bits) use encryption that can easily be broken.
  • RC4 is insecure.
  • 3DES is slow and weak.

Use the following suite configuration, designed for both RSA and ECDSA keys, as your starting point:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
EDH-RSA-DES-CBC3-SHA

Note This example configuration uses nonstandard suite names required by OpenSSL. For deployment in other environments (e.g., IIS), you'll need to use the standard TLS suite names.

Reference: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites

bhushan5640
  • 381
  • 3
  • 12