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.
