4

I went through various online docs, e.g. SSL and TLS Deployment Best Practices, regarding the "right" selection of cipher suites for a website. The attached picture shows my selection of cipher suites with lower priority from top to bottom, e.g. ECDHE-ECDSA-CHACHA20-POLY1305 has the highest priority. In the following, I explain this selection and I would like to have your feedback.

I got the ciphers with the following command, provided by LibreSSL 2.4.1:

openssl ciphers -v | grep -i dhe | grep -i -e ecdsa -e rsa | grep -i -v camellia | grep -i -v rc4 | grep -i -v 3des | grep -i -v ChaCha20-Poly1305-Old

My reasons for the selection:

  • dhe: allow only ciphers that support forward secrecy
  • ecdsa/rsa: disable weak DSA/DSS ciphers
  • camellia: Not as much tested as AES?!? Patent!
  • rc4: weak
  • 3des: weak
  • ChaCha20-Poly1305-Old: draft cipher

Thereafter, I sorted the ciphers with security in mind:

  1. I first chose ciphers supporting AEAD due to among others:

    "You should rely chiefly on the AEAD suites ..." (SSLLABS best practices)

  2. Then, ECDSA ciphers are favoured over RSA. RSA1024 is weak, RSA2048 is all right for now, but RSA3072 and higher puts too much load on the server (IMHO).
  3. ECDH is favoured. DH with 2048 Bit and above is secure for now. But, vulnerabilites are known for lower key lengths. On the other hand, secp256r1 (NIST P-256), which is the most widely supported ECC, is insecure according to Bernstein (URL: safecurves.cr.yp.to). Furthermore secp256r1 comes from NIST! What do you think? Use DH with known vulnerabilities for short key lengths or ECDH with secp256r1 coming from NIST and being insecure according to Bernstein?

After making my selection based on the cipher's strength, I further prioritized based on the performance.

  1. First, I made my selection based on the encryption algorithm with the assumption that it has a bigger impact on performance than the chosen hash algorithm. Am I right or wrong?
  2. With PCs and Laptops being generally more performant than mobile devices, I put the focus on mobile devices and chose ChaCha20-based ciphers first, that run on ARM-based mobile devices faster than AES due to missing AES-NI support (URL: blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/). Modern PCs on the other hand have AES-NI support und run faster with AES.
  3. The further choices (AES128 over AES256 and SHA1->SHA256->SHA384) are self-explanatory. HMAC-SHA1 doesn't pose a risk AFAIK. Or am I wrong?

Btw, I don't mind connectivity issues with Windows XP and some other old systems. ECDSA and RSA will be available on my webserver simultaneously. Nginx supports multiple certs starting with version 1.11.0, while Apache supports it for a longer time. I am going to use the cleaner LibreSSL, which already has ChaCha20.

LibreSSL 2.4.1 cipher selection

closed as too broad by WhiteWinterWolf, Rory Alsop Jun 20 '16 at 16:54

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • The answer on your question can depend on personal preferences and from the balance between better performance and better security. In any way I personally would recommend you to remove all DHE cipher suits. See the feature of Chrome v53 with the corresponding description of the reason. I would place SHA1 after SHA256/SHA384 too because it's hash algorithm which should be removed soon like MD5. I would remove from the table SSLv3 too. Only TLS should be supported now. – Oleg Jun 19 '16 at 12:11
  • 1. "remove all DHE cipher suits": I keep DHE ciphers for now, because DH2048 is still considered secure. Furthermore, I regenerate it regularly as suggested by the Postfix devs. Using DH4096 might be an option for others. 2. I prefer HMAC-SHA1 for now. Collisions don't play a role with HMAC as state by Schneier. 3. "remove SSLv3": The column to the right with the protocol versions indicate the minimun required protocol to use the cipher. I will run only with TLS. – user2486134 Jun 19 '16 at 16:06
  • Chrome decided to remove DHE at all in version 53. ssllabs.com can be used to test HTTPS server and to see, which cipher suits will be used by connection from different web browsers. If you see that no from existing web browsers will use DHE cipher suits (or some other cipher suits) then it would be better to remove the suits. It will reduce the size and probably the number of TCP packages send during negotiation of TLS connection to every client. All my precious recommendation are personal. – Oleg Jun 19 '16 at 16:15
  • I understand that DH2048 and DH4096 could be consider as safe, but it will be really used only from systems which can support DH1024 which is unsafe. Thus DHE with 2048/4096 key and generated starting vector can be supported by the web server, but it gives no real advantage for any existing clients (web browsers). It just increases the size of TLS Hello. – Oleg Jun 19 '16 at 16:20
  • I decided to use only ECDH. Only the native webbrowser of Android 2.3.7 is not supported anymore according to ssllabs, which doesn't pose a problem for me due to its low marketshare of about 2% according to Google. – user2486134 Jun 19 '16 at 23:02