search

aws / s2n-tls

An implementation of the TLS/SSL protocols
https://aws.github.io/s2n-tls/usage-guide/
Apache License 2.0
4.52k stars 705 forks source link

Any info callback API for ssl handshake? #4647

Open Mavis-Dong opened 3 months ago

Mavis-Dong commented 3 months ago

Hello! I'm using s2n-tls and beast lib to implement WSS transport. I'm looking into a ssl handshake error. The s2n_negotiate returns -1 and with "connection is closed" as error message. The strange thing is that when I use "curl -connect host:port", I can get successful ssl handshake. I know that openssl provides an API: ssl_set_info_callback to print the detailed ssl handshake logs. Do we have the similar APIs in s2n-tls? That will be very helpful for debugging. Thanks!

lrstewart commented 3 months ago

We don't have something like ssl_set_info_callback. Can you get a packet capture of the connection instead? "connection is closed" suggests that the peer is closing the connection without an alert.

Mavis-Dong commented 3 months ago

Finally I found that the reason is I set the s2n_cert_auth_type to "Optional". After changing to "None", it works. With "Optional", when I use the chrome to visit websocket port with "wss", the connection will be closed even the client certificate is "Optional" from server's perspective. What's worthy noting is that with "https", chrome browser can handle this "Optional" TLS contract and won't close the connection. But I'm not familiar with the details how the "Optional" mechanism works when client and server negotiate whether TLS or mTLS should be used, so not sure why websocket met such issue. It's highly appreciated if any comment about the issue with "Optional" setting.

lrstewart commented 3 months ago

The API docs describe the optional behavior: https://github.com/aws/s2n-tls/blob/main/api/s2n.h#L2348-L2360 The primary difference between "optional" and "none" is whether or not the server sends the "CertificateRequest" TLS message.

It's odd that it works for "https" but not "wss", when I assume both are configuring s2n-tls the same way. Could your "wss" layer be requiring the client certificate in some way? Is the client or the server closing the connection?