Your CipherSuite string allows for some things that should be lower on your accept list or excluded.
(some ciphers may be listed more than once - because they are included in more than one group)
It also includes ECDSA (and RSA) ciphers, but prefers RSA over ECDSA (this seems out-dated).
Note: Your site may not be providing dual certs, so that may be a non-issue for you.
basically HBO probed our public servers and they wanted me to make it more secure, they said -
The server side TLS endpoint’s configuration should be updated to allow only TLSv1.2 with cipher suites that use: Ephemeral Diffie-Hellman for key exchange
Well you are doing that...But what they didn't tell you is: What you shouldn't be doing.
Your CipherSuite string is long but doesn't really make much of a lockdown.
You would do even better with something a simple as: ALL:!3DES:!AESCCM:!aNULL:!CAMELLIA:!DES:!DSS:!eNULL:!IDEA:!MD5:!PSK:!RC4:!SEED:!SHA1
(Which is not really even the best you can do.)
I would recommend running the string through the same version of OpenSSL (presuming that is what your server is using).
Like: openssl ciphers kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES
or openssl ciphers ALL:!3DES:!AESCCM:!aNULL:!CAMELLIA:!DES:!DSS:!eNULL:!IDEA:!MD5:!PSK:!RC4:!SEED:!SHA1
OR just openssl ciphers
to see all that it can do.
ECDHE = the key exchange, in casu “ephemeral elliptic curve Diffie-Hellman” RSA = the asymmetric cipher for certificate/handshake signing, in casu the “Rivest–Shamir–Adleman” cipher AES256 = the symmetric cipher used to encrypt all the data on the TLS connection, in casu “Advanced Encryption Standard” GCM = the used mode of operation of the symmetric cipher, in casu “Galois/Counter Mode” SHA384 = the used hash algorithm for the message authentication algorithm of the data stream
In ECDHE, one of the two "E"s stands for ephemeral. In the case of ECDHE, it’s the last “E”, as the “EC” stands for “Elliptic Curve”.
All the EDH are also ephemeral, but use the non-elliptic curve Diffie-Hellman key exchange, which is MUCH more CPU intensive and therefore possibly much slower.
openssl ecparam -list_curves
Then, pick a curve from the list and replace your first line with:
openssl ecparam -name secp521r1 -genkey -noout -out my.key.pem
(replace secp521r1 with whichever curve you choose from the list) It's suggested to use ecdhe 256, not 512..
i dont really understand as im using lets encrypt for a public SSL certificate, so shall i stop using lets encrypt and use a private ie self sign cert ie using openssl to make one
You can use EC private keys with Let’s Encrypt, but it’s not necessary (and RSA has better compatibility).
Those “weak cipher” errors on Qualys SSL Labs are not really errors, it’s fine to have them for compatibility as long as you have server preferred, FS cipher suites available.
Use the compatible or modern ciphersuite profiles from the Mozilla SSL Config Generator and don’t worry about it!
Edit: I just read the thing about HBO … in that case you can limit your ciphers to e.g.
i am using the modern compatibility cipher suite, the mozilla wiki website,
could i get openssl to make/generate one for me instead of using one from the web, as isnt the one on the web not best to use as its public and if i use openssl to generate one it will be more secure as its not known?
sorry if doesnt make any sense, all this is above my head but im really kean on learning it
OpenSSL is a piece of software that runs the ciphersuites.
You have to tell it which ciphersuites to use.
That is an external, contextual decision that OpenSSL has no say in and has no opinion on.
You can check under the “cipher strings” section on https://www.openssl.org/docs/man1.1.0/apps/ciphers.html . It’s extremely complicated and the “HIGH” cipherstring gives less security than the Mozilla suggested choices.
Mozilla is the most trustworthy place you can get this advice.
@_az@danb35, there is the issue of selection of Diffie-Hellman groups, where the "Imperfect Forward Secrecy" paper described a risk in using the same group as a large number of other people, for classic Diffie-Hellman, if the group size also didn't meet prior expert recommendations.
Unlike ciphersuites, the specific groups used for a key exchange can be chosen by the server operator. In the past some people would use things like openssl gendh to generate Diffie-Hellman parameters for their own servers, and depending on how they did that, this might have made them much less vulnerable to that particular attack. The authors of the "Imperfect Forward Secrecy" paper do advise generating custom 2048-bit DH parameters if you're going to continue to use any classic DH ciphersuites on your servers, although I believe other software developers have also adopted other mitigations in the meantime, such as changing the default DH groups away from some of the groups that governments are likely to have performed precomputation attacks against. The authors don't seem to believe that any special precautions are necessary for ECDHE key exchanges.
This shows what setup you’ll need to use to make qualys evaluate your site to be 100%… (P.S. unless your site is as non-polular as mine, it’s not suggested to try score all 100% on your tests.)
Also, please share us your domain name so we can know what you would want to do to score 100% on ratings.