[mongodb-dev] TLS more efficient and more secure ciphers

[Gijs Van Laer]

Hi all,

I was trying to set up mongoDB with TLS. When I followed the instructions
in the documentation, the cipher that the server uses
is tls_rsa_with_aes_256_gcm_sha384. But for both performance reasons, as
well as security reasons it would be better to use a cipher using ephemeral
Diffie-Hellman key exchange. (DHE handshake is faster than the RSA version,
and it has forward secrecy) I thought it should automatically select one of
these ciphers, as they are more secure, but apparently the code should be
updated to use these ciphers. Any chance this is already on the backlog, or
does someone has any idea about this?
The more appropriate ciphers are:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Thank you,
Kind regards,
Gijs

[Robert Moore]

Gijs -

A few of things.

1) It is really the client that determines the ciphersuite that is used in
a handshake with a MongoDB server. If you prefer the DHE cipher suites then
you can place them at the start of the cipher suite list your client offers
and the server will pick the first one that it finds to be acceptable.

2) I am not sure where you heard that the DHE handshake is faster than the
RSA version. I could see that a DHE operation is faster than a RSA
operation but that is dependant on the size of the keys used for each.
Also the cipher suites that you posted all are using RSA authentication so
you are not avoiding the RSA computation and are adding a DHE computation
so I am very suspect that the handshake would be any faster and would
expect it to be slightly slower.

3) I would encourage you to NOT worry about the time it takes for the
handshake to occur. MongoDB uses long lasting persistent connections where
the overhead of the initial handshake is amortized over the life of the
connection. Since TLS is security related, doing it right is much more
important than doing it fast.

Lastly, judging the relative security of the different cipher suites is not
a simple topic and while there are probably recommendations that all of the
experts will agree with (e.g., avoid anything with EXPORT in the name at
all costs) those same experts will not all agree on the absolute ordering
of the cipher suites. Even then I can cripple a cipher suite by using a
small or badly chosen key.

Personally, I think MongoDB does the right thing and leaves the cipher
suite list up to the experts and by default
uses "HIGH:!EXPORT:!***@STRENGTH" for the OpenSSL cipher suite
configuration. [1] You can modify that configuration for the server as you
see fit. [2]

Rob.

1:
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L608
2: https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L610

Post by Gijs Van Laer
Hi all,
I was trying to set up mongoDB with TLS. When I followed the instructions
in the documentation, the cipher that the server uses
is tls_rsa_with_aes_256_gcm_sha384. But for both performance reasons, as
well as security reasons it would be better to use a cipher using ephemeral
Diffie-Hellman key exchange. (DHE handshake is faster than the RSA version,
and it has forward secrecy) I thought it should automatically select one of
these ciphers, as they are more secure, but apparently the code should be
updated to use these ciphers. Any chance this is already on the backlog, or
does someone has any idea about this?
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Thank you,
Kind regards,
Gijs

[Gijs Van Laer]

Hi Rob,

Thank you for your quick response, in response to your remarks:
1) It is indeed both client and server that need to support a certain
ciphers. But if I set up an Apache server or a MongoDB server with the same
certificate, and connect using openssl s_client (without any specific
options), then it will connect using ECDHE to Apache and RSA to MongoDB.
Moreover, when specifying the cipher suite list "DHE:ECDHE" to the MongoDB
server, there will be no cipher suites available, therefore, it seems not
able to do DHE in the first place.
2) and 3) I have to admit that I didn't do tests on whether RSA or DHE is
faster, someone told me so, but you might be right that DHE is a little
slower. But as you suggest in your third point, maybe we shouldn't worry
about it indeed.
4) The relative security is indeed a difficult topic, I'm not suggesting
that the underlying mathematical RSA assumption is stronger than the DH
assumption. What experts do agree on, though, is the fact that using RSA
doesn't provide perfect forward secrecy [1]. Because RSA's private key is
stored, when a server gets compromised, previous captured communication can
be decrypted. This decreases long-term security significantly.

I'm not an expert on how to implement this, but a quick comparison between
the code for Apache and the code in MongoDB, it seems that for Apache they
added some specific code for DHE parameters generation. Unless I'm very
wrong about this, I think a code change is needed to provide these more
secure ciphers.

Kind regards,
Gijs

1: https://en.wikipedia.org/wiki/Forward_secrecy

Post by Robert Moore
Gijs -
A few of things.
1) It is really the client that determines the ciphersuite that is used in
a handshake with a MongoDB server. If you prefer the DHE cipher suites then
you can place them at the start of the cipher suite list your client offers
and the server will pick the first one that it finds to be acceptable.
2) I am not sure where you heard that the DHE handshake is faster than the
RSA version. I could see that a DHE operation is faster than a RSA
operation but that is dependant on the size of the keys used for each.
Also the cipher suites that you posted all are using RSA authentication so
you are not avoiding the RSA computation and are adding a DHE computation
so I am very suspect that the handshake would be any faster and would
expect it to be slightly slower.
3) I would encourage you to NOT worry about the time it takes for the
handshake to occur. MongoDB uses long lasting persistent connections where
the overhead of the initial handshake is amortized over the life of the
connection. Since TLS is security related, doing it right is much more
important than doing it fast.
Lastly, judging the relative security of the different cipher suites is
not a simple topic and while there are probably recommendations that all of
the experts will agree with (e.g., avoid anything with EXPORT in the name
at all costs) those same experts will not all agree on the absolute
ordering of the cipher suites. Even then I can cripple a cipher suite by
using a small or badly chosen key.
Personally, I think MongoDB does the right thing and leaves the cipher
suite list up to the experts and by default
configuration. [1] You can modify that configuration for the server as you
see fit. [2]
Rob.
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L608
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L610

Post by Gijs Van Laer
Hi all,
I was trying to set up mongoDB with TLS. When I followed the instructions
in the documentation, the cipher that the server uses
is tls_rsa_with_aes_256_gcm_sha384. But for both performance reasons, as
well as security reasons it would be better to use a cipher using ephemeral
Diffie-Hellman key exchange. (DHE handshake is faster than the RSA version,
and it has forward secrecy) I thought it should automatically select one of
these ciphers, as they are more secure, but apparently the code should be
updated to use these ciphers. Any chance this is already on the backlog, or
does someone has any idea about this?
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Thank you,
Kind regards,
Gijs

[Spencer Jackson]

Hi Gijs,

You're correct and some specific logic related to Diffie-Hellman parameter
selection needs to be added to our OpenSSL integration to enable this
functionality, because the library does not enable these ciphers by
default. We've discussed this internally, but it appears that I didn't file
a corresponding ticket. I've created
https://jira.mongodb.org/browse/SERVER-24897 to track this. Please feel
free to watch or comment on it. Thank you for bringing this up!

Spencer

Post by Gijs Van Laer
Hi Rob,
1) It is indeed both client and server that need to support a certain
ciphers. But if I set up an Apache server or a MongoDB server with the same
certificate, and connect using openssl s_client (without any specific
options), then it will connect using ECDHE to Apache and RSA to MongoDB.
Moreover, when specifying the cipher suite list "DHE:ECDHE" to the MongoDB
server, there will be no cipher suites available, therefore, it seems not
able to do DHE in the first place.
2) and 3) I have to admit that I didn't do tests on whether RSA or DHE is
faster, someone told me so, but you might be right that DHE is a little
slower. But as you suggest in your third point, maybe we shouldn't worry
about it indeed.
4) The relative security is indeed a difficult topic, I'm not suggesting
that the underlying mathematical RSA assumption is stronger than the DH
assumption. What experts do agree on, though, is the fact that using RSA
doesn't provide perfect forward secrecy [1]. Because RSA's private key is
stored, when a server gets compromised, previous captured communication can
be decrypted. This decreases long-term security significantly.
I'm not an expert on how to implement this, but a quick comparison between
the code for Apache and the code in MongoDB, it seems that for Apache they
added some specific code for DHE parameters generation. Unless I'm very
wrong about this, I think a code change is needed to provide these more
secure ciphers.
Kind regards,
Gijs
1: https://en.wikipedia.org/wiki/Forward_secrecy

Post by Robert Moore
Gijs -
A few of things.
1) It is really the client that determines the ciphersuite that is used
in a handshake with a MongoDB server. If you prefer the DHE cipher suites
then you can place them at the start of the cipher suite list your client
offers and the server will pick the first one that it finds to be
acceptable.
2) I am not sure where you heard that the DHE handshake is faster than
the RSA version. I could see that a DHE operation is faster than a RSA
operation but that is dependant on the size of the keys used for each.
Also the cipher suites that you posted all are using RSA authentication so
you are not avoiding the RSA computation and are adding a DHE computation
so I am very suspect that the handshake would be any faster and would
expect it to be slightly slower.
3) I would encourage you to NOT worry about the time it takes for the
handshake to occur. MongoDB uses long lasting persistent connections where
the overhead of the initial handshake is amortized over the life of the
connection. Since TLS is security related, doing it right is much more
important than doing it fast.
Lastly, judging the relative security of the different cipher suites is
not a simple topic and while there are probably recommendations that all of
the experts will agree with (e.g., avoid anything with EXPORT in the name
at all costs) those same experts will not all agree on the absolute
ordering of the cipher suites. Even then I can cripple a cipher suite by
using a small or badly chosen key.
Personally, I think MongoDB does the right thing and leaves the cipher
suite list up to the experts and by default
configuration. [1] You can modify that configuration for the server as you
see fit. [2]
Rob.
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L608
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L610

Post by Gijs Van Laer
Hi all,
I was trying to set up mongoDB with TLS. When I followed the
instructions in the documentation, the cipher that the server uses
is tls_rsa_with_aes_256_gcm_sha384. But for both performance reasons, as
well as security reasons it would be better to use a cipher using ephemeral
Diffie-Hellman key exchange. (DHE handshake is faster than the RSA version,
and it has forward secrecy) I thought it should automatically select one of
these ciphers, as they are more secure, but apparently the code should be
updated to use these ciphers. Any chance this is already on the backlog, or
does someone has any idea about this?
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Thank you,
Kind regards,
Gijs

[d***@gmail.com]

Hi, I'm trying to use new *opensslDiffieHellmanParameters* parameter with
official mongo docker image (v3.5.13), but it doesn't add ECDHE support.
The same set if certificates allows ECDHE in nodejs 8.9.1 (which is not
supports ECDH. That's why I'm searching for ECDHE mongo support)

Here is how I run configs, shards and mongos:

command: [
"mongos",
"--configdb", "cfgrs0/config-rs0:27019,config-rs1:27019,config-rs2:27019",
# for mongo 3.5+
"--bind_ip_all",
"--sslMode", "requireSSL",
"--sslAllowInvalidHostnames",
"--sslAllowInvalidCertificates",
"--clusterAuthMode", "x509",
"--sslCAFile", "/run/secrets/root-ca.pem",
"--sslPEMKeyFile", "/run/secrets/mongos0.pem",
"--sslPEMKeyPassword", "/run/secrets/signing-ca-passphrase",
"--sslClusterFile", "/run/secrets/mongos0.pem",
"--sslClusterPassword", "/run/secrets/signing-ca-passphrase",
# for mongo 3.5+
"--setParameter", "opensslDiffieHellmanParameters=/run/secrets/dhparams.pem"]

and here is test agains 'HIGH:!EXPORT:!***@STRENGTH' cipherlist:

mongos and server was tested. Results are similar:

Obtaining cipher list from OpenSSL 1.0.1t 3 May 2016.
Testing ECDHE-RSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing ECDHE-RSA-AES256-SHA384...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES256-SHA384...NO (ssl handshake failure)
Testing ECDHE-RSA-AES256-SHA...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES256-SHA...NO (ssl handshake failure)
Testing SRP-DSS-AES-256-CBC-SHA...NO (no ciphers available)
Testing SRP-RSA-AES-256-CBC-SHA...NO (no ciphers available)
Testing SRP-AES-256-CBC-SHA...NO (no ciphers available)
Testing DHE-DSS-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing DHE-RSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing DHE-RSA-AES256-SHA256...NO (ssl handshake failure)
Testing DHE-DSS-AES256-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES256-SHA...NO (ssl handshake failure)
Testing DHE-DSS-AES256-SHA...NO (ssl handshake failure)
Testing DHE-RSA-CAMELLIA256-SHA...NO (ssl handshake failure)
Testing DHE-DSS-CAMELLIA256-SHA...NO (ssl handshake failure)
Testing ECDH-RSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES256-GCM-SHA384...YES
Testing ECDH-RSA-AES256-SHA384...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES256-SHA384...YES
Testing ECDH-RSA-AES256-SHA...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES256-SHA...YES
Testing AES256-GCM-SHA384...NO (ssl handshake failure)
Testing AES256-SHA256...NO (ssl handshake failure)
Testing AES256-SHA...NO (ssl handshake failure)
Testing CAMELLIA256-SHA...NO (ssl handshake failure)
Testing PSK-AES256-CBC-SHA...NO (no ciphers available)
Testing ECDHE-RSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing ECDHE-RSA-AES128-SHA256...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES128-SHA256...NO (ssl handshake failure)
Testing ECDHE-RSA-AES128-SHA...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES128-SHA...NO (ssl handshake failure)
Testing SRP-DSS-AES-128-CBC-SHA...NO (no ciphers available)
Testing SRP-RSA-AES-128-CBC-SHA...NO (no ciphers available)
Testing SRP-AES-128-CBC-SHA...NO (no ciphers available)
Testing DHE-DSS-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES128-SHA256...NO (ssl handshake failure)
Testing DHE-DSS-AES128-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES128-SHA...NO (ssl handshake failure)
Testing DHE-DSS-AES128-SHA...NO (ssl handshake failure)
Testing DHE-RSA-CAMELLIA128-SHA...NO (ssl handshake failure)
Testing DHE-DSS-CAMELLIA128-SHA...NO (ssl handshake failure)
Testing ECDH-RSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES128-GCM-SHA256...YES
Testing ECDH-RSA-AES128-SHA256...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES128-SHA256...YES
Testing ECDH-RSA-AES128-SHA...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES128-SHA...YES
Testing AES128-GCM-SHA256...NO (ssl handshake failure)
Testing AES128-SHA256...NO (ssl handshake failure)
Testing AES128-SHA...NO (ssl handshake failure)
Testing CAMELLIA128-SHA...NO (ssl handshake failure)
Testing PSK-AES128-CBC-SHA...NO (no ciphers available)


Here https://github.com/docker-library/mongo/issues/214 my issue in docker
repo

Post by Spencer Jackson
Hi Gijs,
You're correct and some specific logic related to Diffie-Hellman parameter
selection needs to be added to our OpenSSL integration to enable this
functionality, because the library does not enable these ciphers by
default. We've discussed this internally, but it appears that I didn't file
a corresponding ticket. I've created
https://jira.mongodb.org/browse/SERVER-24897 to track this. Please feel
free to watch or comment on it. Thank you for bringing this up!
Spencer

Post by Gijs Van Laer
Hi Rob,
1) It is indeed both client and server that need to support a certain
ciphers. But if I set up an Apache server or a MongoDB server with the same
certificate, and connect using openssl s_client (without any specific
options), then it will connect using ECDHE to Apache and RSA to MongoDB.
Moreover, when specifying the cipher suite list "DHE:ECDHE" to the MongoDB
server, there will be no cipher suites available, therefore, it seems not
able to do DHE in the first place.
2) and 3) I have to admit that I didn't do tests on whether RSA or DHE is
faster, someone told me so, but you might be right that DHE is a little
slower. But as you suggest in your third point, maybe we shouldn't worry
about it indeed.
4) The relative security is indeed a difficult topic, I'm not suggesting
that the underlying mathematical RSA assumption is stronger than the DH
assumption. What experts do agree on, though, is the fact that using RSA
doesn't provide perfect forward secrecy [1]. Because RSA's private key is
stored, when a server gets compromised, previous captured communication can
be decrypted. This decreases long-term security significantly.
I'm not an expert on how to implement this, but a quick comparison
between the code for Apache and the code in MongoDB, it seems that for
Apache they added some specific code for DHE parameters generation. Unless
I'm very wrong about this, I think a code change is needed to provide these
more secure ciphers.
Kind regards,
Gijs
1: https://en.wikipedia.org/wiki/Forward_secrecy

Post by Robert Moore
Gijs -
A few of things.
1) It is really the client that determines the ciphersuite that is used
in a handshake with a MongoDB server. If you prefer the DHE cipher suites
then you can place them at the start of the cipher suite list your client
offers and the server will pick the first one that it finds to be
acceptable.
2) I am not sure where you heard that the DHE handshake is faster than
the RSA version. I could see that a DHE operation is faster than a RSA
operation but that is dependant on the size of the keys used for each.
Also the cipher suites that you posted all are using RSA authentication so
you are not avoiding the RSA computation and are adding a DHE computation
so I am very suspect that the handshake would be any faster and would
expect it to be slightly slower.
3) I would encourage you to NOT worry about the time it takes for the
handshake to occur. MongoDB uses long lasting persistent connections where
the overhead of the initial handshake is amortized over the life of the
connection. Since TLS is security related, doing it right is much more
important than doing it fast.
Lastly, judging the relative security of the different cipher suites is
not a simple topic and while there are probably recommendations that all of
the experts will agree with (e.g., avoid anything with EXPORT in the name
at all costs) those same experts will not all agree on the absolute
ordering of the cipher suites. Even then I can cripple a cipher suite by
using a small or badly chosen key.
Personally, I think MongoDB does the right thing and leaves the cipher
suite list up to the experts and by default
configuration. [1] You can modify that configuration for the server as you
see fit. [2]
Rob.
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L608
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L610

Post by Gijs Van Laer
Hi all,
I was trying to set up mongoDB with TLS. When I followed the
instructions in the documentation, the cipher that the server uses
is tls_rsa_with_aes_256_gcm_sha384. But for both performance reasons, as
well as security reasons it would be better to use a cipher using ephemeral
Diffie-Hellman key exchange. (DHE handshake is faster than the RSA version,
and it has forward secrecy) I thought it should automatically select one of
these ciphers, as they are more secure, but apparently the code should be
updated to use these ciphers. Any chance this is already on the backlog, or
does someone has any idea about this?
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Thank you,
Kind regards,
Gijs

['Spencer Jackson' via mongodb-dev]

Hi, thanks for trying out the new features! opensslDiffieHellmanParameters
sets the parameters which will be used for the classic DHE cipher suites.
This option won't have any effect on the ECDHE suites. MongoDB 3.5.12+ will
enable the ECDHE suites by default, and without any additional
configuration, if the server has been compiled and run against OpenSSL
version 1.0.2 or higher. From the logs you've provided, you're running
against OpenSSL 1.0.1t. If you want to use the ECDHE suites, you'll need to
upgrade your OpenSSL libraries and get server binaries which link against
them.

Cheers,
Spencer

Post by d***@gmail.com
Hi, I'm trying to use new *opensslDiffieHellmanParameters* parameter with
official mongo docker image (v3.5.13), but it doesn't add ECDHE support.
The same set if certificates allows ECDHE in nodejs 8.9.1 (which is not
supports ECDH. That's why I'm searching for ECDHE mongo support)
command: [
"mongos",
"--configdb", "cfgrs0/config-rs0:27019,config-rs1:27019,config-rs2:27019",
# for mongo 3.5+
"--bind_ip_all",
"--sslMode", "requireSSL",
"--sslAllowInvalidHostnames",
"--sslAllowInvalidCertificates",
"--clusterAuthMode", "x509",
"--sslCAFile", "/run/secrets/root-ca.pem",
"--sslPEMKeyFile", "/run/secrets/mongos0.pem",
"--sslPEMKeyPassword", "/run/secrets/signing-ca-passphrase",
"--sslClusterFile", "/run/secrets/mongos0.pem",
"--sslClusterPassword", "/run/secrets/signing-ca-passphrase",
# for mongo 3.5+
"--setParameter", "opensslDiffieHellmanParameters=/run/secrets/dhparams.pem"]
Obtaining cipher list from OpenSSL 1.0.1t 3 May 2016.
Testing ECDHE-RSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing ECDHE-RSA-AES256-SHA384...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES256-SHA384...NO (ssl handshake failure)
Testing ECDHE-RSA-AES256-SHA...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES256-SHA...NO (ssl handshake failure)
Testing SRP-DSS-AES-256-CBC-SHA...NO (no ciphers available)
Testing SRP-RSA-AES-256-CBC-SHA...NO (no ciphers available)
Testing SRP-AES-256-CBC-SHA...NO (no ciphers available)
Testing DHE-DSS-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing DHE-RSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing DHE-RSA-AES256-SHA256...NO (ssl handshake failure)
Testing DHE-DSS-AES256-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES256-SHA...NO (ssl handshake failure)
Testing DHE-DSS-AES256-SHA...NO (ssl handshake failure)
Testing DHE-RSA-CAMELLIA256-SHA...NO (ssl handshake failure)
Testing DHE-DSS-CAMELLIA256-SHA...NO (ssl handshake failure)
Testing ECDH-RSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES256-GCM-SHA384...YES
Testing ECDH-RSA-AES256-SHA384...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES256-SHA384...YES
Testing ECDH-RSA-AES256-SHA...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES256-SHA...YES
Testing AES256-GCM-SHA384...NO (ssl handshake failure)
Testing AES256-SHA256...NO (ssl handshake failure)
Testing AES256-SHA...NO (ssl handshake failure)
Testing CAMELLIA256-SHA...NO (ssl handshake failure)
Testing PSK-AES256-CBC-SHA...NO (no ciphers available)
Testing ECDHE-RSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing ECDHE-RSA-AES128-SHA256...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES128-SHA256...NO (ssl handshake failure)
Testing ECDHE-RSA-AES128-SHA...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES128-SHA...NO (ssl handshake failure)
Testing SRP-DSS-AES-128-CBC-SHA...NO (no ciphers available)
Testing SRP-RSA-AES-128-CBC-SHA...NO (no ciphers available)
Testing SRP-AES-128-CBC-SHA...NO (no ciphers available)
Testing DHE-DSS-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES128-SHA256...NO (ssl handshake failure)
Testing DHE-DSS-AES128-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES128-SHA...NO (ssl handshake failure)
Testing DHE-DSS-AES128-SHA...NO (ssl handshake failure)
Testing DHE-RSA-CAMELLIA128-SHA...NO (ssl handshake failure)
Testing DHE-DSS-CAMELLIA128-SHA...NO (ssl handshake failure)
Testing ECDH-RSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES128-GCM-SHA256...YES
Testing ECDH-RSA-AES128-SHA256...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES128-SHA256...YES
Testing ECDH-RSA-AES128-SHA...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES128-SHA...YES
Testing AES128-GCM-SHA256...NO (ssl handshake failure)
Testing AES128-SHA256...NO (ssl handshake failure)
Testing AES128-SHA...NO (ssl handshake failure)
Testing CAMELLIA128-SHA...NO (ssl handshake failure)
Testing PSK-AES128-CBC-SHA...NO (no ciphers available)
Here https://github.com/docker-library/mongo/issues/214 my issue in
docker repo

Post by Spencer Jackson
Hi Gijs,
You're correct and some specific logic related to Diffie-Hellman
parameter selection needs to be added to our OpenSSL integration to enable
this functionality, because the library does not enable these ciphers by
default. We've discussed this internally, but it appears that I didn't file
a corresponding ticket. I've created
https://jira.mongodb.org/browse/SERVER-24897 to track this. Please feel
free to watch or comment on it. Thank you for bringing this up!
Spencer

Post by Gijs Van Laer
Hi Rob,
1) It is indeed both client and server that need to support a certain
ciphers. But if I set up an Apache server or a MongoDB server with the same
certificate, and connect using openssl s_client (without any specific
options), then it will connect using ECDHE to Apache and RSA to MongoDB.
Moreover, when specifying the cipher suite list "DHE:ECDHE" to the MongoDB
server, there will be no cipher suites available, therefore, it seems not
able to do DHE in the first place.
2) and 3) I have to admit that I didn't do tests on whether RSA or DHE
is faster, someone told me so, but you might be right that DHE is a little
slower. But as you suggest in your third point, maybe we shouldn't worry
about it indeed.
4) The relative security is indeed a difficult topic, I'm not suggesting
that the underlying mathematical RSA assumption is stronger than the DH
assumption. What experts do agree on, though, is the fact that using RSA
doesn't provide perfect forward secrecy [1]. Because RSA's private key is
stored, when a server gets compromised, previous captured communication can
be decrypted. This decreases long-term security significantly.
I'm not an expert on how to implement this, but a quick comparison
between the code for Apache and the code in MongoDB, it seems that for
Apache they added some specific code for DHE parameters generation. Unless
I'm very wrong about this, I think a code change is needed to provide these
more secure ciphers.
Kind regards,
Gijs
1: https://en.wikipedia.org/wiki/Forward_secrecy

Post by Robert Moore
Gijs -
A few of things.
1) It is really the client that determines the ciphersuite that is used
in a handshake with a MongoDB server. If you prefer the DHE cipher suites
then you can place them at the start of the cipher suite list your client
offers and the server will pick the first one that it finds to be
acceptable.
2) I am not sure where you heard that the DHE handshake is faster than
the RSA version. I could see that a DHE operation is faster than a RSA
operation but that is dependant on the size of the keys used for each.
Also the cipher suites that you posted all are using RSA authentication so
you are not avoiding the RSA computation and are adding a DHE computation
so I am very suspect that the handshake would be any faster and would
expect it to be slightly slower.
3) I would encourage you to NOT worry about the time it takes for the
handshake to occur. MongoDB uses long lasting persistent connections where
the overhead of the initial handshake is amortized over the life of the
connection. Since TLS is security related, doing it right is much more
important than doing it fast.
Lastly, judging the relative security of the different cipher suites is
not a simple topic and while there are probably recommendations that all of
the experts will agree with (e.g., avoid anything with EXPORT in the name
at all costs) those same experts will not all agree on the absolute
ordering of the cipher suites. Even then I can cripple a cipher suite by
using a small or badly chosen key.
Personally, I think MongoDB does the right thing and leaves the cipher
suite list up to the experts and by default
configuration. [1] You can modify that configuration for the server as you
see fit. [2]
Rob.
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L608
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L610

Post by Gijs Van Laer
Hi all,
I was trying to set up mongoDB with TLS. When I followed the
instructions in the documentation, the cipher that the server uses
is tls_rsa_with_aes_256_gcm_sha384. But for both performance reasons, as
well as security reasons it would be better to use a cipher using ephemeral
Diffie-Hellman key exchange. (DHE handshake is faster than the RSA version,
and it has forward secrecy) I thought it should automatically select one of
these ciphers, as they are more secure, but apparently the code should be
updated to use these ciphers. Any chance this is already on the backlog, or
does someone has any idea about this?
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Thank you,
Kind regards,
Gijs

[d***@gmail.com]

Hi, Spencer. Thank you for reply.

среЎа, 29 МПября 2017 г., 2:28:46 UTC+7 пПльзПватель Spencer Jackson

Post by 'Spencer Jackson' via mongodb-dev
Hi, thanks for trying out the new features! opensslDiffieHellmanParameters
sets the parameters which will be used for the classic DHE cipher suites.
This option won't have any effect on the ECDHE suites. MongoDB 3.5.12+ will
enable the ECDHE suites by default, and without any additional
configuration, if the server has been compiled and run against OpenSSL
version 1.0.2 or higher. From the logs you've provided, you're running
against OpenSSL 1.0.1t. If you want to use the ECDHE suites, you'll need to
upgrade your OpenSSL libraries and get server binaries which link against
them.
Cheers,
Spencer

Post by d***@gmail.com
Hi, I'm trying to use new *opensslDiffieHellmanParameters* parameter
with official mongo docker image (v3.5.13), but it doesn't add ECDHE
support. The same set if certificates allows ECDHE in nodejs 8.9.1 (which
is not supports ECDH. That's why I'm searching for ECDHE mongo support)
command: [
"mongos",
"--configdb", "cfgrs0/config-rs0:27019,config-rs1:27019,config-rs2:27019",
# for mongo 3.5+
"--bind_ip_all",
"--sslMode", "requireSSL",
"--sslAllowInvalidHostnames",
"--sslAllowInvalidCertificates",
"--clusterAuthMode", "x509",
"--sslCAFile", "/run/secrets/root-ca.pem",
"--sslPEMKeyFile", "/run/secrets/mongos0.pem",
"--sslPEMKeyPassword", "/run/secrets/signing-ca-passphrase",
"--sslClusterFile", "/run/secrets/mongos0.pem",
"--sslClusterPassword", "/run/secrets/signing-ca-passphrase",
# for mongo 3.5+
"--setParameter", "opensslDiffieHellmanParameters=/run/secrets/dhparams.pem"]
Obtaining cipher list from OpenSSL 1.0.1t 3 May 2016.
Testing ECDHE-RSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing ECDHE-RSA-AES256-SHA384...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES256-SHA384...NO (ssl handshake failure)
Testing ECDHE-RSA-AES256-SHA...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES256-SHA...NO (ssl handshake failure)
Testing SRP-DSS-AES-256-CBC-SHA...NO (no ciphers available)
Testing SRP-RSA-AES-256-CBC-SHA...NO (no ciphers available)
Testing SRP-AES-256-CBC-SHA...NO (no ciphers available)
Testing DHE-DSS-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing DHE-RSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing DHE-RSA-AES256-SHA256...NO (ssl handshake failure)
Testing DHE-DSS-AES256-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES256-SHA...NO (ssl handshake failure)
Testing DHE-DSS-AES256-SHA...NO (ssl handshake failure)
Testing DHE-RSA-CAMELLIA256-SHA...NO (ssl handshake failure)
Testing DHE-DSS-CAMELLIA256-SHA...NO (ssl handshake failure)
Testing ECDH-RSA-AES256-GCM-SHA384...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES256-GCM-SHA384...YES
Testing ECDH-RSA-AES256-SHA384...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES256-SHA384...YES
Testing ECDH-RSA-AES256-SHA...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES256-SHA...YES
Testing AES256-GCM-SHA384...NO (ssl handshake failure)
Testing AES256-SHA256...NO (ssl handshake failure)
Testing AES256-SHA...NO (ssl handshake failure)
Testing CAMELLIA256-SHA...NO (ssl handshake failure)
Testing PSK-AES256-CBC-SHA...NO (no ciphers available)
Testing ECDHE-RSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing ECDHE-RSA-AES128-SHA256...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES128-SHA256...NO (ssl handshake failure)
Testing ECDHE-RSA-AES128-SHA...NO (ssl handshake failure)
Testing ECDHE-ECDSA-AES128-SHA...NO (ssl handshake failure)
Testing SRP-DSS-AES-128-CBC-SHA...NO (no ciphers available)
Testing SRP-RSA-AES-128-CBC-SHA...NO (no ciphers available)
Testing SRP-AES-128-CBC-SHA...NO (no ciphers available)
Testing DHE-DSS-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES128-SHA256...NO (ssl handshake failure)
Testing DHE-DSS-AES128-SHA256...NO (ssl handshake failure)
Testing DHE-RSA-AES128-SHA...NO (ssl handshake failure)
Testing DHE-DSS-AES128-SHA...NO (ssl handshake failure)
Testing DHE-RSA-CAMELLIA128-SHA...NO (ssl handshake failure)
Testing DHE-DSS-CAMELLIA128-SHA...NO (ssl handshake failure)
Testing ECDH-RSA-AES128-GCM-SHA256...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES128-GCM-SHA256...YES
Testing ECDH-RSA-AES128-SHA256...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES128-SHA256...YES
Testing ECDH-RSA-AES128-SHA...NO (ssl handshake failure)
Testing ECDH-ECDSA-AES128-SHA...YES
Testing AES128-GCM-SHA256...NO (ssl handshake failure)
Testing AES128-SHA256...NO (ssl handshake failure)
Testing AES128-SHA...NO (ssl handshake failure)
Testing CAMELLIA128-SHA...NO (ssl handshake failure)
Testing PSK-AES128-CBC-SHA...NO (no ciphers available)
Here https://github.com/docker-library/mongo/issues/214 my issue in
docker repo

Post by Spencer Jackson
Hi Gijs,
You're correct and some specific logic related to Diffie-Hellman
parameter selection needs to be added to our OpenSSL integration to enable
this functionality, because the library does not enable these ciphers by
default. We've discussed this internally, but it appears that I didn't file
a corresponding ticket. I've created
https://jira.mongodb.org/browse/SERVER-24897 to track this. Please feel
free to watch or comment on it. Thank you for bringing this up!
Spencer

Post by Gijs Van Laer
Hi Rob,
1) It is indeed both client and server that need to support a certain
ciphers. But if I set up an Apache server or a MongoDB server with the same
certificate, and connect using openssl s_client (without any specific
options), then it will connect using ECDHE to Apache and RSA to MongoDB.
Moreover, when specifying the cipher suite list "DHE:ECDHE" to the MongoDB
server, there will be no cipher suites available, therefore, it seems not
able to do DHE in the first place.
2) and 3) I have to admit that I didn't do tests on whether RSA or DHE
is faster, someone told me so, but you might be right that DHE is a little
slower. But as you suggest in your third point, maybe we shouldn't worry
about it indeed.
4) The relative security is indeed a difficult topic, I'm not
suggesting that the underlying mathematical RSA assumption is stronger than
the DH assumption. What experts do agree on, though, is the fact that using
RSA doesn't provide perfect forward secrecy [1]. Because RSA's private key
is stored, when a server gets compromised, previous captured communication
can be decrypted. This decreases long-term security significantly.
I'm not an expert on how to implement this, but a quick comparison
between the code for Apache and the code in MongoDB, it seems that for
Apache they added some specific code for DHE parameters generation. Unless
I'm very wrong about this, I think a code change is needed to provide these
more secure ciphers.
Kind regards,
Gijs
1: https://en.wikipedia.org/wiki/Forward_secrecy

Post by Robert Moore
Gijs -
A few of things.
1) It is really the client that determines the ciphersuite that is
used in a handshake with a MongoDB server. If you prefer the DHE cipher
suites then you can place them at the start of the cipher suite list your
client offers and the server will pick the first one that it finds to be
acceptable.
2) I am not sure where you heard that the DHE handshake is faster than
the RSA version. I could see that a DHE operation is faster than a RSA
operation but that is dependant on the size of the keys used for each.
Also the cipher suites that you posted all are using RSA authentication so
you are not avoiding the RSA computation and are adding a DHE computation
so I am very suspect that the handshake would be any faster and would
expect it to be slightly slower.
3) I would encourage you to NOT worry about the time it takes for the
handshake to occur. MongoDB uses long lasting persistent connections where
the overhead of the initial handshake is amortized over the life of the
connection. Since TLS is security related, doing it right is much more
important than doing it fast.
Lastly, judging the relative security of the different cipher suites
is not a simple topic and while there are probably recommendations that all
of the experts will agree with (e.g., avoid anything with EXPORT in the
name at all costs) those same experts will not all agree on the absolute
ordering of the cipher suites. Even then I can cripple a cipher suite by
using a small or badly chosen key.
Personally, I think MongoDB does the right thing and leaves the cipher
suite list up to the experts and by default
configuration. [1] You can modify that configuration for the server as you
see fit. [2]
Rob.
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L608
https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager.cpp#L610

Post by Gijs Van Laer
Hi all,
I was trying to set up mongoDB with TLS. When I followed the
instructions in the documentation, the cipher that the server uses
is tls_rsa_with_aes_256_gcm_sha384. But for both performance reasons, as
well as security reasons it would be better to use a cipher using ephemeral
Diffie-Hellman key exchange. (DHE handshake is faster than the RSA version,
and it has forward secrecy) I thought it should automatically select one of
these ciphers, as they are more secure, but apparently the code should be
updated to use these ciphers. Any chance this is already on the backlog, or
does someone has any idea about this?
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Thank you,
Kind regards,
Gijs