Make key exchange and cipher strengh 100%

hi all,

now i got the tlsv1.2 working im working on making the server bulletproof

im using to test my server -

https://www.ssllabs.com/ssltest/

and its A+ atm

atm heres my SSL cipher suite i use -

SSLCipherSuite 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

can anyone share there cipher suites they use

EDIT - do i need to make one using openssl?

cheers,

rob

Remember that stricter security settings prevent older browsers and operating systems from accessing your site.

2 Likes

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)

SHA1 ciphers:
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-RSA-CAMELLIA128-SHA
ECDH-RSA-AES256-SHA
ECDH-ECDSA-AES256-SHA
ECDH-RSA-AES128-SHA
ECDH-ECDSA-AES128-SHA
DHE-DSS-AES256-SHA
DHE-DSS-AES128-SHA
DHE-DSS-CAMELLIA256-SHA
DHE-DSS-CAMELLIA128-SHA
AES256-SHA
AES128-SHA
CAMELLIA256-SHA
CAMELLIA128-SHA

ciphers without perfect forwarding secrecy:
AES256-GCM-SHA384
AES256-SHA256
AES128-GCM-SHA256
AES128-SHA256
AES256-SHA
AES128-SHA
CAMELLIA256-SHA
CAMELLIA128-SHA

DSS:
DHE-DSS-AES256-GCM-SHA384
DHE-DSS-AES256-SHA256
DHE-DSS-AES128-GCM-SHA256
DHE-DSS-AES256-SHA
DHE-DSS-AES128-SHA
DHE-DSS-CAMELLIA256-SHA
DHE-DSS-CAMELLIA128-SHA

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.

i have followed a good guide -

https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html

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.

And review their output.

thanks rg305, i will do some tests using openssl but for now

found a mozilla one to use, im using the modern compatibility so older clients can connect and when i do another ssl test i get no weak errors -

https://wiki.mozilla.org/Security/Server_Side_TLS

ok i have puttied in on my server how do i produced Ephemeral Diffie-Hellman via openssl,

when i do -

openssl ciphers

i get loads and loads come up, one of them that comes up is - “ECDHE-RSA-AES256-GCM-SHA384”

can i get openssl to produce me a Ephemeral Diffie-Hellman cipher or key?

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.

1 Like

Hi,

Try this command...

For a list of possible curve names, run:

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..

Finally, generate the CSR as you have done:

openssl req -new -sha256 -key my.key.pem -out my.csr
From dsa - Generate an ECDSA key and CSR with OpenSSL - Super User

Thank you

thanks steven,

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 don’t need an EC private key nor certificate to use ECDHE.

RSA private keys/certificates => TLS-ECDHE-RSA-xxx
EC private keys/certificates => TLS-ECDHE-ECDSA-xxx

See Osiris’ explanation.

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.

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

but I feel like HBO have gotten it wrong with that advice.

2 Likes

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

It doesn’t make sense, no.

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.

No, it doesn't, not in the least. The cipher suites your web server will use aren't something that's in any way private information.

You might be thinking about

https://weakdh.org/

In that case, you might want to consult the authors’ advice at

https://weakdh.org/sysadmin.html

They say that you don’t need to generate your own ECDHE groups.

@_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.

I posted above about the paper authors' advice at

but in general I'd agree that for most purposes

Lol...makes me remember spending days generate 8192 bits key for several servers.:joy:

Take a look at this:
https://blog.qualys.com/ssllabs/2017/01/18/ssl-labs-grading-changes-january-2017

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.

Thank you

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.