SSL_Read() returns SSL_ERROR_ZERO_RETURN but ERR_get_error() is 0 - c++

Question

I am writing a non-blocking Websocket client and using OpenSSL for the TLS layer. I am able to connect to the remote server, complete the TLS handshake, send an Upgrade request, get an upgrade confirmed response, and get an actual websocket response afterwards before the TLS layer disconnects with a SSL_ERROR_ZERO_RETURN.
SSL_get_error(...) returns: 6 // SSL_ERROR_ZERO_RETURN
ERR_error_string(ERR_get_error(), nullptr) returns: error:00000000:lib(0):func(0):reason(0)
From my understanding, ERR_get_error() should pop off and return the first error on the error queue, and SSL_get_error() returns the last error of a SSL_* function. I do not understand why SSL_get_error() would return an error value but ERR_get_error() does not. According to this previous Stack Overflow Question, SSL_get_error() does NOT call ERR_get_error().
Following code gets called repeatedly (since it is a non-blocking socket) :
ERR_clear_error();
int ret = SSL_read(...);
if (ret > 0) {
// read bytes from socket
} else {
int err_code = SSL_get_error(ssl_session_, ret);
if (err_code == SSL_ERROR_ZERO_RETURN || err_code == SSL_ERROR_SYSCALL || err_code == SSL_ERROR_SSL) {
sprintf("Disconnected: %d %s", err_code, ERR_error_string(ERR_get_error(), nullptr));
// Disconnect Code
}
}
I have two questions:
Why am I not getting an error value for ERR_get_error()?
Why am I getting disconnected so quickly after establishing a TLS and Websocket session?
EDIT 1
I used wireshark to capture the packets between the client and the server. I confirmed that the TLS handshake, the websocket upgrade, and an initial server response are successful. I noticed after the initial server response, my client gets an Encrypted Alert 21 from the server which I believe is a fatal error and explains why the TLS session terminates immediately and my SSL error queue is empty (while it is probably a client side issue, I don't think it's the result of a recent action), and kind of explains the SSL_ERROR_ZERO_RETURN value I am getting after the SSL_Read.
I am not sure what the Encrypted Alert 21 entails. It might be the cert I am using (self signed). Need to investigate further.

Answer 1

Alright, the root cause of the issue has been determined but a lot of hoops were jumped through and time wasted to get there. I was able to decrypt the SSL traffic by grabbing the master key using the OpenSSL method, SSL_SESSION_get_master_key(), and the Client Hello's Random value with wireshark.
Relevant Code to output master key after SSL_Connect:
ERR_clear_error();
int ret = SSL_connect(ssl_ptr);
if (ret > 0) {
SSL_SESSION * ssl_session = SSL_get_session(ssl_ptr);
if(ssl_session != NULL) {
unsigned char master_key_buf[256];
size_t outlen = sizeof(master_key_buf);
size_t buf_size = SSL_SESSION_get_master_key(ssl_session, master_key_buf, outlen);
if(outlen > 0) {
char hex_encoded_master_buf[513];
// hex encode the master key
for(size_t i = 0; i < buf_size; ++i) {
sprintf(&hex_encoded_master_buf[2*i], "%02x", master_key_buf[i]);
}
hex_encoded_master_buf[(2*buf_size)] = '\0';
// log out the hex-encoded master key in master buf here
}
}
}
Using the NSS Key Log CLIENT_RANDOM format in wireshark to decrypt the captured SSL Traffic, I was able to examine the aforementioned Encrypted Alert 21 which ended up just being a WebSocket FIN and close_notify.
It turns out, the underlying reason was that during the handshake, my WSS Upgrade Request message did indeed containing the right headers, but I was actually sending a garbage payload with it. It was a case of setting the size using sizeof of the message buffer instead of strlen when sending the message. The server would have parsed the Upgrade message just fine and completed the handshake successfully, but the next time it checked its socket, it would read in garbage when it was expecting a WSS message. This caused the abrupt closure of the websocket connection.
In Summary, to answer my original two questions:
Why am I not getting an error value for ERR_get_error()?
The connection is being terminated on the server side, and the error queue would contain errors on the client side, which there are not any, at least on the SSL/TLS layer.
Why am I getting disconnected so quickly after establishing a TLS and Websocket session?
My Initial Upgrade request contained a valid Websocket Upgrade Request with Garbage Data following it. The Server parsed the Websocket Upgrade Request and confirmed the upgrade, and started sending back data. The next time the server checked its socket, it still had the garbage values that was sent with the original Websocket Upgrade Request. Since the server did not recognize it as a valid Websocket message, or anything else for that matter, it decided to terminate the connection with a close_notify.