SSL_connect and SSL_ERROR_SYSCALL

Question

Does SSL_connect() support ssl v3? The reason I am asking this is, while accessing the site :

https://secure53.onlineaccess1.com

I get a return value for SSL_connect(ssl) as <0 and SSL_get_error() as 5 and ERR_get_error() as 0. So the end result is I found out that since SSL_get_error() is 5,

SSL_ERROR_SYSCALL

Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error (for socket I/O on Unix systems, consult errno for details).

And since ERR_get_error() returns 0, it means an EOF was observed that violates the protocol.

But does that mean it doesnot support sslv3?

I tried the url in command line using curl and I had to force v3 to get it to work like this :

curl -3 -v https://secure53.onlineaccess1.com

And is there a way to fix this error?

Solution 1

I was using SSLv23_method() to start the connection. But my best guess is the server doesn't understand sslv2. Since this method will send out SSLv2 client hello messages and will indicate that it also understands SSLv3 and TLSv1, the server did not understand what I wanted and closed the connection with an EOF.

So I tried using SSLv3_method() to connect to this server and it worked. So what I am doing now is try to connect with SSLv23_method() and if it fails with a SSL_ERROR_SYSCALL for SSL_get_error() and a 0 for ERR_get_error(), I just reset the connection and start over again with SSLv3_method(). Not the best way, I know. But it works.

Solution 2

As found in the man page:

SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)

A TLS/SSL connection established with these methods will understand the SSLv2, SSLv3, and TLSv1
protocol. 
A client will send out SSLv2 client hello messages and will indicate that it also understands     
SSLv3 and TLSv1. 
A server will understand SSLv2, SSLv3, and TLSv1 client hello messages. 
This is the best choice when compatibility is a concern.

So, depending on your openSSL version in use, when using SSLv23_client_method(), the client will try to negotiate the highest protocol layer he can find in common with the server.

It's more likely your server doesn't support TLSv1.0 or higher. I would try the following:

SSL_CTX *sslCTX = SSL_CTX_new(SSLv23_client_method());
SSL_CTX_set_options(sslCTX, SSL_OP_ALL | SSL_OP_NO_TLSv1_2 | SSL_OP_NO_TLSv1_1 | SSL_OP_NO_TLSv1);

effectively trying to negotiate with SSLv3 and with possible fallback to SSLv2

Solution 3

And since ERR_get_error() returns 0, it means an EOF was observed that violates the protocol.

No. It says in that case you should consult ret (emphasis mine):

SSL_ERROR_SYSCALL

Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error (for socket I/O on Unix systems, consult errno for details).

ret was passed in to SSL_get_error() so ret is the return code from your original SSL_connect() call. You stated you got a return value <0 from SSL_connect(). If it is -1 and you're on a unix system, you should be consulting errno to find out what happened (emphasis mine):

SSL_ERROR_SYSCALL

Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error (for socket I/O on Unix systems, consult errno for details).