This is meant to supersede issues #5 and #412.

Prefer Strongest First Cipher Order

Apache 2.4.6 on CentOS 7 default is:
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

Removing MEDIUM does a pretty good job but fails forward secrecy for a couple of the SSL Labs reference browsers.

We're using the "Modern" cipher suite (and the order) recommended here: https://wiki.mozilla.org/Security/Server_Side_TLS As https://www.fashion.net already has everything set up to achieve an A+ rating at ssllabs.com, it would be great if we'd keep that as we transition to LE.

+1 for Mozilla modern ssl cipher suite would be best for most folks

The problem I have with the modern cipher suite recommended by Mozilla is that it prefers AES128 over AES256. I prefer strongest first where available. Only use weaker when necessary. Change up the order to prefer AES256 ciphers and it's probably a pretty good suite of ciphers.

Absolutely. It seems AES_128 is still in wide use -- google.com, instagram.com, eff.org, facebook.com, et cetera, all use AES_128. But I trust that soon will change. Bing.com, for example, uses AES_256 (although they are using an obsolete cipher suite). It would be great if LE would optimize the suites on a regular basis so all sites using its certificates would always be up-to-date.

A couple thoughts.

1. If AES256 is stronger than AES128 and the performance impact is negligible, then it would seem to be silly to prefer AES128, and a no-brainer to prefer to prefer AES256 instead.
2. If AES256 is stronger than AES128 and the performance impact is NOT negligible, offer the cipher suite in two orders. One ordered to prefer AES256 and one to prefer AES128. Comment out the weaker one by default so that for those who AES256 is a performance issue can change which one is active/default simply by changing which one is commented out in the config file.

Hey @n0yb ! Some interesting information on AES128 vs AES256 here: https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic ("AES 128 is preferred to AES 256. There has been discussions on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks.")

Don't see any reference there that establishes when "at the moment" was. AES128 will always be faster than AES256. So the performance criteria shouldn't be which is faster. But which is better / strongest security while still having acceptable performance on current hardware/software technology.

I assume this page is, and will be, constantly updated. The stats at the bottom of the page indicate the information is current:

This page was last modified on 28 August 2015, at 15:11.
This page has been accessed 405,583 times.

I saw that page update date at the bottom. But that doesn't speak to when the priorities were established nor when they were last affirmed. That page update could be as simple and meaningless to the priorities as a typo correction anywhere in the page. That's the problem with publishing things like this that are going to be around for awhile with vague statements like "at the moment". A few years down the road nobody knows or can depend on it's current relevance.

It seems the people who maintain that page are at: https://github.com/mozilla/server-side-tls/graphs/contributors

That document was originally committed to github Oct 2014. There does not appear to be any commits that update the modern cipher suite (I could have missed it though). So it is at least that old. But until the date of the original document is established we still don't know how much technology water has flowed down the river since that cipher suite and its priority order was created.

initial github pages commit of ssl-config-generator
commit b201a1191ba38e6f933cd02a4f425f683ffa9be4 0 parents
@gene1wood gene1wood authored on Oct 18 2014

Also without the document origin established and the criteria and objectives for cipher suite order we also don't know how it aligns with current criteria and objectives of the Let's Encrypt project.

In short, the cipher suite needs to be evaluated against Let's Encrypt project criteria and objectives. Not just taken at face value as being authoritative and appropriate for all projects and uses.

It's a good cipher suite. But that doesn't mean it's the right one for the Let's Encrypt project or the right preference order.

Sure thing. It seems https://mozilla.github.io/server-side-tls/ssl-config-generator/ is up-to-date.

That appears to be the intermediate cipher suite. Isn't it the modern cipher suite we are talking about?

I don't understand why the Modern configuration has been grayed out for Apache; switch to Nginx and the modern suite becomes available. I suppose the best way to figure this out is to contact the people at https://github.com/mozilla/server-side-tls/graphs/contributors and ask.

@n0yb

In short, the cipher suite needs to be evaluated against Let's Encrypt project criteria and objectives.

Let me know if we (Mozilla Security) can be of any help.

As far as how current the recommendation is it should be correct. @jvehent can add more color to the accuracy of the recommendations.

@sugoiyo

I don't understand why the Modern configuration has been grayed out for Apache; switch to Nginx and the modern suite becomes available.

The rationale should display when you mouse-over "Modern" when it's grayed out (unless you're on mobile, a bug we're working on).

Modern isn't available in Apache 2.2.15 because TLS v1 and v2 were only added to Apache in version 2.4. If you change the Apache version around Modern will become available.

Howdy 👋
I authored the AES 128 vs 256 part 2 years ago and it doesn't seem like the state of the art has changed since. While the performance difference is probably not the highest concern, there has been some research that suggest that attacks on AES256 are easier to achieve than on the 128 variant. The reasoning is that most attack on AES do not directly target the rounds or the key length, but focus more on side channels like timing attacks. If AES 128 is more resistant to those than 256, then 128 should be preferred. This thread has more information: http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11325.html

I'm happy to explain more about the reasoning behind each level if you'd like. We spend a lot of time making sure the levels are current and support the security and compatibility needs of old, intermediate and modern web applications. It would be a great honor to have them included in letsencrypt!

Hey @gene1wood & @jvehent -- really good to be in touch!

And thanks, @gene1wood! While we're still using the older Apache 2.2.15 on https://www.fashion.net/, we managed to tweak our configuration to get an A+ on SSL Labs, and Google's Chrome browser reports:

Your connection to www.fashion.net is encrypted using a modern cipher suite.
The connection uses TLS 1.2.
The connection is encrypted and authenticated using AES_128_GCM and uses ECDHE_RSA as the key exchange mechanism.

How did we manage this with 2.2.15? Our configuration is:

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
SSLEngine on
SSLProtocol all -SSLv3 -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

@sugoiyo

How did we manage this with 2.2.15?

This may be due to this bug on our side ( mozilla/server-side-tls#62 ) however that says support goes back to 2.2.23 not 2.2.15. I haven't dug into the bug yet to find the exact version where support was added. If you've got any details you want to add to that bug we'll try to get it fixed.

@gene1wood

Thanks! Looking for the installed versions of Apache and OpenSSL, we got:

apachectl -V

Server version: Apache/2.2.15 (Unix)
Server built: Aug 15 2014 03:02:07
Server's Module Magic Number: 20051115:25
Server loaded: APR 1.3.9, APR-Util 1.3.9
Compiled using: APR 1.3.9, APR-Util 1.3.9
Architecture: 64-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/usr/sbin/suexec"
-D DEFAULT_PIDLOG="run/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"

openssl version

OpenSSL 1.0.1e-fips 11 Feb 2013

@jvehent
Thanks for the state of the document updated and rational overview. Great to know.

I see google is using ChaCha20-Poly1305 rather than AES on the iPad; found a link about it here:

https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/

@jvehent

According to some Wikipedia articles it seems as though timing attacks may not be as significant of a threat as they were just as recent as a couple years ago.
Are there any plans, or ongoing schedule/interval, to re-evaluate the recommended "modern" cipher suite?

Wikipedia Transport Layer Security
https://en.wikipedia.org/wiki/Transport_Layer_Security

Padding Orical Attack
https://en.wikipedia.org/wiki/Padding_oracle_attack

Lucky Thirteen Attack
https://en.wikipedia.org/wiki/Lucky_Thirteen_attack

Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
https://tools.ietf.org/html/rfc7366

@n0yb : We don't have a particular timeline to make changes to the recommendation, it's always up for discussion.

Is there anything in the references you list that specifically discusses timing attacks on AES 256?

I'm happy to hear that folks from Mozilla Security are still always thinking about the up-to-dateness of your TLS configuration recommendations! And thank you for keeping us in the loop over here.

Mine vote (too) for using ECDHE-RSA-CHACHA20-POLY1305 as first choice. More info on that here: https://www.imperialviolet.org/2013/10/07/chacha20.html

These are primitives developed by Dan Bernstein and are fast, secure, have high quality, public domain implementations, are naturally constant time and have nearly perfect key agility.

IMHO most modern combination, no timing attacks, etc.

P.S. Sad that there is no ED25519 variant.. So if we don't trust NIST, then RSA is only other option..

We should always prefer GCM and Forward secrecy.
We should remove 3DES ciphers.
We shouldn't implement DSS ciphers as Mozilla recommend.
We may support camellia and ChaCha ciphers (available in future versions of OpenSSL and forks, GnuTLS and planned for NSS).
It would be better to disable TLS 1.0 (security over compatibility).
For AES256 we should use a >= 3072 bit private key.

(just mirroring)

These attacks are very theoretical and far from really affecting current connections. Especially using AES in hardware (AES-NI), whatever its performance may be, should save you from the timing attacks. And as far as I understand it, the other attacks released by Bruce Schneier in 2009 don’t apply at all to regular TLS connections and make very specific assumptions about nonstandard round length, known plaintext and related-key knowledge.

However, I don’t want to go into a debate about the presence or absence of AES256 security qualities. What I wanted say is that it is useless to enforce server-side cipher order (SSLHonorCipherOrder On) and list the AES256 ciphers behind their AES128 counterparts if all browsers which implement AES256 also implement AES128. So only those clients who tweak the ClientHello disallowing AES128 and only offering AES256 would actually ‘benefit’ from supporting this said-to-be weaker encryption based on AES256. Then, why have it on the list at all?

So, presuming “SSLHonorCipherOrden On”, if someone still feels safe with these discovered AES256 weaknesses he should actually put the AES256 ciphers in front of the respective AES128 ciphers – otherwise they’re never used at all. On the other hand, if he doesn’t trust AES256 for some reason, he should just throw these ciphers off the list instead of just moving them to lower priority.

Point is: Don’t use magical pattern matching in the SSLCipherSuite entry. Keep the list explicit and as short as possible. Understand (and possibly document) each used cipher’s strengths and weaknesses and which cipher is used by which browsers and what you think would be an appropriate time to drop it. Use SSL Labs tests early, use them often. Keep an eye on security mailing lists, and check your settings whenever you do an upgrade of any of your SSL/TLS related components (e.g., Apache/nginx, OpenSSL/LibreSSL, CPU with/without AES-NI, certificate renewal, key family upgrade RSA/ECDSA).

by @ecdsa-chacha20 at https://community.letsencrypt.org/t/lets-encrypt-is-trusted/1638/8?u=rugk

Hi guys, sorry for missing the topic here and posting to the community portal instead. I’m @ecdsa-chacha20 there, so kind of split identity 😄

The actual topic there https://community.letsencrypt.org/t/lets-encrypt-is-trusted/1638/2 was the appearance of https://helloworld.letsencrypt.org is not perfect IMHO, especially if it is there to show off LE’s properties. Just to summarize:

1. there is/was a OCSP issue shown which seems to have dissapeared since.
2. Suggestion to send the target intermediate CA heading the ISRG Root X1 to allow immediate adoption of the ‘real’ certification path once the new Root CA becomes permanent in the various browsers.
3. The suggestion to go either with TLS 1.2 only or to enable TLS 1.0. This topic also seems to have settled, TLS 1.0 is now enabled. The choice of offering CBC at TLS 1.0 again opens the door for BEAST for exactly those browsers that haven’t seen and will never see an upgrade for this security hole. Seems there is no way out: Either support them and open the BEAST, or close it and lock them out, as RC4 was dismissed.
4. Get rid of SSL Cipher Suite pattern matching and enable ciphers just as you need them to get in contact with your browsers, one by one. Keep separate lists for RSA and future ECDSA keys and keep each list short and easy to grasp. The browsers from the list at SSL Labs https://dev.ssllabs.com/ssltest/analyze.html?d=helloworld.letsencrypt.org&hideResults=on currently utilize a total of five different ciphers from the list of the offered 12, so 7 of them are unused and will likely never be used.

The spread of supported ciphers in modern browsers with TLS 1.2 becomes focused to a single one: ECDHE-RSA-AES128-GCM-SHA256 (optionally ECDHE-RSA-AES256-GCM-SHA384) so it is wise to catch the browsers at that security level. As I already explained, I don’t second the adverse for AES256, but it should be either dropped from the list, or given a higher priority than AES128. Second row for AES256 on a server with SSLHonorCipherOrder On doesn’t make any sense at all.

Someone seems to have made a decision to prioritize AESGCM before other ECDHE key exchange ciphers. This gives DHE a quite high priority in some non-upgradable but still maintained browsers like IE11 on Windows prior to Win10. AFAIK, CBC in TLS 1.2 is not broken but DHE is on the road to disposal, so I’d give ECDHE-RSA-AES128-SHA256 a higher priority. Note that IE11 is actually able to use AESGCM with ECDHE but only for ECDSA keys.

So for a broad compatibility (TLS 1.0 to 1.2) I’d go for the following SSL cipher suite:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA

(and for those lucky ones with CHACHA20 support):

ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA

For the brave who like AES256 or don’t dislike it enough (edit: re-added AES128-GCM):

ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA

Any of these three cipher suites with just three or four ciphers each just do the trick. It’s easy to argue for each cipher why it is there and which clients benefit from its use: CHACHA20 as a first glance of TLS 1.3 for Chrome and modern Android, GCM for the most recent and actively maintained browsers (edit: with some only supporting GCM with AES128), SHA384/SHA256 for recent TLS 1.2 capable browsers that feared GCM (perhaps due to performance issues), and SHA1 for browsers stuck at TLS 1.0 but still supporting PFS (note, BEAST not mitigated server-side due to CBC at TLS 1.0!).

Only drawback: They keep Android <4, IE on XP, Java < 7 and OpenSSL < 1.0.0 off the party. Ancient Android, Java 6 and OpenSSL 0.9.8 can be invited by enabling DHE-RSA-AES128-SHA keeping the Forward Secrecy property, but you cannot use SNI (Android, Java) and you have to limit your DH parameters within the 1024 limit (Java). And you have expect friendly fire from DHE in the future. Support for IE on XP (who still needs this, btw, except sites like download.firefox.mozilla.org?) would require going for non-PFS ciphers using DES-CBC3-SHA. Neither of these two ciphers I’d recommend to enable these days.

And if you’re not taking care of the poor souls stuck with TLS 1.0 or want to finally get rid of BEAST: Disable all SSL protocols except TLS 1.2 and enable only these two ciphers:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256

or, for LibreSSL:

ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256

or, for AES256 (edit: re-added AES128-GCM):

ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384

Once ECDSA is broadly used, I think TLS 1.0 and elder browsers will fade out and first TLS 1.3 support will be available, so apart from new ciphers I’d then make the cipher list something like the following:

ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256

or even just

ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256

or, with AES256 (edit: re-added AES128-GCM):

ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256

Dropping support for CBC ciphers will affect mostly Android < 4.4, IE < 11, OS X < 10.11 and iOS < 9 as well as Java < 8 and OpenSSL < 1.0.1, so YMMV.

EDIT: When going for AES256, at least AES128-GCM should be enabled as well so that some browsers not supporting AES256-GCM at all are not forced into a CBC cipher.

As you point out at the very end of your post, web browsers are not the only clients that connect to web servers. Readers of this issue should be careful how strict they want to be with default ciphersuites, they tends to break obscure clients in unexpected ways. Which is why we propose 3 levels in the Mozilla guidelines, and depending on the user's needs, more ciphers can be enabled.

I don't disagree that AES256 is superfluous, but it was kept because its security is good and it increase compatibility.

ChaCha20 isn't yet a standard. It will most likely change during standardization. Enabling it now just enables compatibility pain in the future.

Non-PFS ciphers should be discarded entirely. Even if that means using a slower DHE handshake. Your private keys are not going to be secure forever, and people don't change password, so decrypting today's traffic 10 years from now will still give valuable information.

The main topic I wanted to point out is: Explicit, short cipher list. It. Is. Possible. Don’t make it magic by letting OpenSSL choose ciphers based on the cryptic syntax, don’t enable ciphers nobody uses.

Anything else (AES256, DHE, BEAST, ChaCha20, even the three levels proposed in the Mozilla Guidelines) can be discussed later.

You're assuming that

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA

makes more sense to administrators than

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

While I agree the first one is neater, pretty, and saves a few bytes, my experience helping administrators is that they don't really understand the ciphersuite, regardless of its length. But they will get very frustrated if the ciphersuite breaks backward compatibility and their management comes breathing down their necks. Which is why we use a longer, uglier, but more backward compatible configuration that people will copy/paste anyway.

Second row for AES256 on a server with SSLHonorCipherOrder On doesn’t make any sense at all.

+1

AFAIK, CBC in TLS 1.2 is not broken but DHE is on the road to disposal, so I’d give ECDHE-RSA-AES128-SHA256 a higher priority. Note that IE11 is actually able to use AESGCM with ECDHE but only for ECDSA keys.

[...] GCM for the most recent and actively maintained browsers [...]

Isn't this an objection?
DHE is only bad, if you use it wrong (too short parameter, not changing parameter regularly).

As you point out at the very end of your post, web browsers are not the only clients that connect to web servers.

I'm sure we will talk about this again when we plan to support mail servers etc. but for a web server this looks quite robust.

@jvehent the last thing I care about are a few bytes on the server. 😄 It’s about maintainability and transparency. I think not even most people making suggestions about cipher suites can decipher (pun intended) the cipher suite with all its pattern, inclusions, exceptions, pre- and postfixes. It just doesn’t make sense. It did make sense when the server offered a list the client could pick from. Times have changed, we have SSLHonorCipherOrder On, and now the admin should make the best educated guess about the list of ciphers, and I definitely advocate to make it as short as possible, as long as absolutely necessary.

If it’s about the separation between RSA and ECDSA … well, merging them into a single line would still make the string short and understandable. But tell me who needs DHE-DSS-AES256-SHA in the list? Just who? And which browser will pick any of the long list of DHE ciphers when he can use a better ECDHE cipher? It just doesn’t make sense to have ciphers in the list just-for-fun. At least, there is no CAMELLIA in the list …

@J0WI I don’t understand: an objection about what? I think we all agree that GCM is preferred and CBC is only broken for TLS 1.0. DHE is quite safe using custom parameters/primes, but the more sessions built on a single prime, the more attractive it becomes to attempt recovery. If someone breaks CBC he can perhaps read a single session. If he breaks DHE, he will break a lot of things. Thinking of older Apaches with hard-coded DHE params, limited to 1024 or even 512 primes, I would definitely remove DHE from the list or make it very, very, very, very clear to the reader what he has to do in advance to make his DHE setup safe. But as @jvehent said, it’s the administrators with lack of understanding for the whole security topic who have to be helped, and disabling DHE is the best first step.

I think the bottom line was meant not just for other TLS services but for other http clients than browsers, like wget/curl, PHP or Java using some web API. They might be running on ancient OS with little to no support for updates (not even root CAs), administrators got used to disabling certificate checks and that like. All of them will suffer, now or later.

Security is a give and take. Clients also have to give.

The objection is, that we want to prefer GCM, but use CBC with IE.
For DHE params see #374

Ah, there is the issue for the DH parameters. So dropping DHE would immediately close #374 😉

So it's still about GCM vs DHE on IE

@schoen, here's what we should do to close this ticket:

• Put your (and others') research on various parties' recommendations on ciphersuites into a document in docs/
• Document what the plugins currently do in that document
• Point to Implement flags to control: security parameters in general, ciphersuites in particular, and autoupdating of those things #1123 as the way we're going to offer better control of these things in the near-ish future.