Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forcing ciphers on server side causing handshake failure on openssl 1.1.1 compiled with enable_tls1_3 #5057

Closed
EmericBr opened this issue Jan 11, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@EmericBr
Copy link
Contributor

commented Jan 11, 2018

openssl-master is compiled using latest a41a612 and enabling tls_1_3
openssl-1.0.2 is compiled using stable 1.0.2g

Handshake is ok with negociated ECDHE-RSA-AES256-GCM-SHA384:
./openssl-master s_server -cert crt.pem -key key.pem -port 4443
./openssl-1.0.2 s_client -connect 127.0.0.1:4443

Handshake failed forcing the cipher:
./openssl-master s_server -cert crt.pem -key key.pem -port 4443 -cipher ECDHE-RSA-AES256-GCM-SHA384
./openssl-1.0.2 s_client -connect 127.0.0.1:4443
....
CONNECTED(00000003)
140008127227544:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:

Handshake is ok forcing -no_tls1_3 on server side:
./openssl-master s_server -cert crt.pem -key key.pem -port 4443 -cipher ECDHE-RSA-AES256-GCM-SHA384 -no_tls1_3
./openssl-1.0.2 s_client -connect 127.0.0.1:4443

@kaduk

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2018

Your s_server's log should have something like:

ERROR
140442013566720:error:141FC0B5:SSL routines:tls_setup_handshake:no ciphers available:ssl/statem/statem_lib.c:117:No ciphers enabled for max supported SSL/TLS version
shutting down SSL
CONNECTION CLOSED

which is hopefully self-explanatory. All connections will fail so that you quickly notice that the cipherspec does not include any ciphers permitted by TLS 1.3, which is a bug in your invocation.

@kaduk kaduk closed this Jan 11, 2018

@EmericBr

This comment has been minimized.

Copy link
Contributor Author

commented Jan 12, 2018

But why the handshake is also failing in tls1.2 ?

It seems that the handshake fails even if the client does not support tls1.3. You should consider this as a bug. If there is no server available for tls1.3 you should dynamically disable the tls1.3 and fallback on "only" lower protocol version.

Please have in mind that a lot of servers specify cipher list and upgrading to openssl-1.1.1 with tls 1.3
enabled will result to production failures due to broken handshake for tls1.2.

@EmericBr

This comment has been minimized.

Copy link
Contributor Author

commented Jan 12, 2018

I'm creating a new bug for this

@richsalz

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2018

No, it's not a bug, it is working as designed. If you enable TLS 1.3 and you don't allow any TLS 1.3 ciphers, that is a configuration error and things will fail. This was done on purpose.

@EmericBr

This comment has been minimized.

Copy link
Contributor Author

commented Jan 12, 2018

I agree with that but it brokes also TLSv1.2 handshake and the application should show an error at startup and not at run time in this case.

I suppose you will implicitly enable tlsv1.3 in the next version and it would break a lot of existing configuration.

@kaduk

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2018

Setting the min/max TLS version and setting the cipher list can be done in either order; the handshake is basically the first time that the library can know that the application is claiming that the configuration is supposed to work/be self-consistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.