TLS handshake error : No shared cipher (SSL error 40)

[Francis GASCHET]

Hello,

We use openSSL in OFTP2 implementation. The OFTP2 working group decided
to strongly recommend to use preferably the cipher suites including PFS
(ephemeral Diffie Hellman).
So in our iplementation (linked against openssl 1.0.1g) I limited the
list of offered ciphers (client) and prefered ciphers (server) to :
"DHE-RSA-AES256-SHA:EDH-RSA-DES-CBC3-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-RSA-AES128-SHA:"
using SSL_CTX_set_cipher_list.

On this "restricted" binary it looks fine : only these ciphers are
presented in the client hello:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

But on the legacy software side (linked against openSSL V0.9.8c), the
server rejects the connection with the "No shared cipher" error.
On this site, the command "openssl ciphers" says that DHE-RSA-AES128-SHA
and EDH-RSA-DES-CBC3-SHA are supported(among others).
So 2 ciphersuites are shared...
BTW: In this version of the software, the default list is in use
(SSL_CTX_set_cipher_list is not called).

It is the same when I reverse the roles : the legacy binary becomes the
client.In that case, wireshark shows TLS_DHE_RSA_WITH_AES_256_CBC_SHA
and TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHAin the offered list of cipher
suites (among others).
But the "restricted" binary rejects the connection with the same error.
On this side, the same list of ciphers (listed above) are specified
before accepting the connection (server)than before calling out (client).

So I'm lost !

Thank you in advance for help.

[Viktor Dukhovni]

We use openSSL in OFTP2 implementation. The OFTP2 working group decided to
strongly recommend to use preferably the cipher suites including PFS
(ephemeral Diffie Hellman).

Preferably, does not mean exclusively. You should probably not
exclude non-PFS cipher suites for interoperability reasons.

So in our implementation (linked against openssl 1.0.1g) I limited the list
DHE-RSA-AES256-SHA,
EDH-RSA-DES-CBC3-SHA
DHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-DES-CBC3-SHA
ECDHE-RSA-AES128-SHA,
using SSL_CTX_set_cipher_list.
But on the legacy software side (linked against openSSL V0.9.8c),

Which does not support ECDHE, and probably is not configured with
DHE parameters, and hence does not support any of these.

the server rejects the connection with the "No shared cipher" error.

As expected.

On this site, the command "openssl ciphers" says that DHE-RSA-AES128-SHA and
EDH-RSA-DES-CBC3-SHA are supported(among others).

These require configuration of server-side temp DH parameters.

It is the same when I reverse the roles : the legacy binary becomes the
client.In that case, wireshark shows TLS_DHE_RSA_WITH_AES_256_CBC_SHA and
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA in the offered list of cipher suites (among
others).
But the "restricted" binary rejects the connection with the same error.
On this side, the same list of ciphers (listed above) are specified before
accepting the connection (server)than before calling out (client).

Once again to use DHE, the server must set temp DH parameters, and
to use ECDHE must select a temp ECDH curve.

[Dave Thompson]

Sent: Wednesday, September 17, 2014 13:35
We use openSSL in OFTP2 implementation. The OFTP2 working group decided
to strongly recommend to use preferably the cipher suites including PFS
(ephemeral Diffie Hellman).

<snip>

To date*, in order to agree a DH-ephemeral or ECDH-ephemeral suite,
the server must be configured with "temporary" DH/ECDH parameters:
https://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
tmp_ecdh* is similar but has no manpage. Is it?

For ECDHE, the temporary parameters must be a curve allowed by the
client's list of supported curves. For openssl clients (except RedHat)
all standard "named" curves are allowed, but other clients may differ.
P-256 and P-384, and maybe P-521, seem to be most widely supported,
and therefore probably the best choices in general.

* 1.0.2 is expected to have some more convenient options in this area.



______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Francis GASCHET]

Hello,

Thank to both of you.

Best regards,
--
Francis

Post by Dave Thompson

Sent: Wednesday, September 17, 2014 13:35
We use openSSL in OFTP2 implementation. The OFTP2 working group decided
to strongly recommend to use preferably the cipher suites including PFS
(ephemeral Diffie Hellman).

<snip>
To date*, in order to agree a DH-ephemeral or ECDH-ephemeral suite,
https://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
tmp_ecdh* is similar but has no manpage. Is it?
For ECDHE, the temporary parameters must be a curve allowed by the
client's list of supported curves. For openssl clients (except RedHat)
all standard "named" curves are allowed, but other clients may differ.
P-256 and P-384, and maybe P-521, seem to be most widely supported,
and therefore probably the best choices in general.
* 1.0.2 is expected to have some more convenient options in this area.
______________________________________________________________________
OpenSSL Project http://www.openssl.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org