[Home]

Summary:ASTERISK-26606: tcptls: Incorrect OpenSSL function call leads to misleading error report
Reporter:Bob Ham (rah)Labels:
Date Opened:2016-11-15 17:40:26.000-0600Date Closed:2017-05-11 10:47:41
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:13.8.0 GIT Frequency of
Occurrence
Constant
Related
Issues:
Environment:Attachments:
Description:In the function [handle_tcptls_connection() in tcptls.c|https://github.com/asterisk/asterisk/blob/a6e5bae3ef9fe498927e0b5f9318a64c9ff101a9/main/tcptls.c#L633], a call is made to SSL_connect() or SSL_accept() and the return value is checked with ERR_get_error().  However, [the man page|https://linux.die.net/man/3/ssl_get_error] for both these functions specify that SSL_get_error() should be used.

While trying to diagnose an error, I was getting the message

{{Problem setting up ssl connection: error:00000000:lib(0):func(0):reason(0)}}

Modifying the code to use SSL_get_error() instead of ERR_get_error() gives the correct (although no more helpful) message:

{{Problem setting up ssl connection: error:00000005:lib(0):func(0):reason(5)}}

In fact, the return value from SSL_get_error() should be checked explicitly.  The test code that I added was as follows:

{code}
               if ((ret = ssl_setup(tcptls_session->ssl)) <= 0) {
                       int sslerr = SSL_get_error(tcptls_session->ssl, ret);
                       const char *msg;
                       ast_log(LOG_ERROR, "Problem setting up ssl connection: %s\n",
                               ERR_error_string(sslerr, err));
                       switch (sslerr) {
                       case SSL_ERROR_NONE: msg = "None"; break;
                       case SSL_ERROR_ZERO_RETURN: msg = "Zero return"; break;
                       case SSL_ERROR_WANT_READ: msg = "Want read"; break;
                       case SSL_ERROR_WANT_WRITE: msg = "Want write"; break;
                       case SSL_ERROR_WANT_CONNECT: msg = "Want connect"; break;
                       case SSL_ERROR_WANT_ACCEPT: msg = "Want accept"; break;
                       case SSL_ERROR_WANT_X509_LOOKUP: msg = "Want X509 lookup"; break;
                       case SSL_ERROR_SYSCALL:
                               if (ret == 0) {
                                       msg = "Syscall EOF";
                               } else if (ret == -1) {
                                       ast_log(LOG_ERROR, "Underlying BIO error: %s\n",
                                               strerror(errno));
                                       msg = "Syscall underlying BIO error (see above)";
                               } else {
                                       msg = "Syscall other";
                               }
                               break;
                       case SSL_ERROR_SSL: msg = "SSL"; break;
                       default: msg = "[Unknown]"; break;
                       }
                       ast_log(LOG_ERROR, "Error from ssl_setup: %s\n", msg);
{code}

Which produces the following output:

{code}
[Nov 15 23:29:49] ERROR[2672]: tcptls.c:611 handle_tcptls_connection: Problem setting up ssl connection: error:00000005:lib(0):func(0):reason(5)
[Nov 15 23:29:49] ERROR[2672]: tcptls.c:625 handle_tcptls_connection: Underlying BIO error: Connection reset by peer
[Nov 15 23:29:49] ERROR[2672]: tcptls.c:635 handle_tcptls_connection: Error from ssl_setup: Syscall underlying BIO error (see above)
{code}

Obviously my switch statement is a hack but it would be good to have proper checking of the return value of SSL_get_error(), as directed by the man page documentation, in some wrapper function.
Comments:By: Asterisk Team (asteriskteam) 2016-11-15 17:40:27.577-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Friendly Automation (friendly-automation) 2017-05-11 10:47:42.320-0500

Change 5615 merged by Jenkins2:
tcptls: Improve error messages for TLS connections.

[https://gerrit.asterisk.org/5615|https://gerrit.asterisk.org/5615]

By: Friendly Automation (friendly-automation) 2017-05-11 10:50:30.059-0500

Change 5614 merged by Jenkins2:
tcptls: Improve error messages for TLS connections.

[https://gerrit.asterisk.org/5614|https://gerrit.asterisk.org/5614]

By: Friendly Automation (friendly-automation) 2017-05-11 11:01:39.461-0500

Change 5616 merged by Jenkins2:
tcptls: Improve error messages for TLS connections.

[https://gerrit.asterisk.org/5616|https://gerrit.asterisk.org/5616]

By: Friendly Automation (friendly-automation) 2017-09-18 17:53:02.342-0500

Change 6526 merged by Jenkins2:
tcptls: Fixed a white space error.

[https://gerrit.asterisk.org/6526|https://gerrit.asterisk.org/6526]

By: Friendly Automation (friendly-automation) 2017-09-18 18:12:58.265-0500

Change 6527 merged by Joshua Colp:
tcptls: Fixed a white space error.

[https://gerrit.asterisk.org/6527|https://gerrit.asterisk.org/6527]