[openssl-users] What is the best practise for shutdown SSL connections?
Serj
What is the best practise for shutdown SSL connections? When client and server both not mine. For example, http client or server.
I have read:
https://www.openssl.org/docs/ssl/SSL_shutdown.html
https://www.openssl.org/docs/ssl/SSL_set_shutdown.html
I use non-blocking sockets and create sockets manually, then with BIO_new_socket() and SSL_set_bio() associate them with SSL object.
I have 3 themes and corresponding questions:
1. Return values for SSL_shutdown()
I never get 2 as a return value! Only 1 as successful then SSL_SENT_SHUTDOWN and SSL_RECEIVED_SHUTDOWN are both set. Maybe something wrong at the documentation?
2. What is the best practise for shutdown SSL connections for CLIENT?
As I understand unidirectional shutdown for client is more suitable, doesn't require special work for waiting "close_notify". But we must be sure that server got a "close_notify" - this is the question! So, the code for CLIENT:
------------------------------------------------
//all data were obtained from the server
SSL_shutdown(ssl);
//here we must be sure that "close_notify" alert is gotten by server
//...
closesocket(s);
------------------------------------------------
How to do this check: server got the "close_notify" alert? What is the best practise?
I see that SSL_get_shutdown() returns SSL_SENT_SHUTDOWN immediatly after we have called SSL_shutdown() first time, so it only sets the flag after sending "close_notify" but doesn't wait.
3. What is the best practise for shutdown SSL connections for SERVER?
As I understand SERVER must get "close_notify" from client otherwise it will not be able to save a session, am i right? And the session will be invalid in this case.
So, for server the code is:
------------------------------------------------
//all data has been sent to the client
SSL_shutdown(ssl); //will not be superfluous
//here we must wait a "close_notify" alert from client
//we can do this by examine flag SSL_RECEIVED_SHUTDOWN with SSL_get_shutdown()
//...
//and only after this we can safely close the connection
closesocket(s);
------------------------------------------------
I will be very glad if these 3 themes and corresponding questions will not go unanswered!
--
Best Regards,
Serj
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Viktor Dukhovni
> 1. Return values for SSL_shutdown()
the peer.
> I never get 2 as a return value!
lists in the on-line documentation. Instead of showing item labels,
item numbers are showing up instead. ] The nroff manpage says:
RETURN VALUES
The following return values can occur:
0 The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional
shutdown shall be performed. The output of SSL_get_error(3) may be misleading, as an erroneous
SSL_ERROR_SYSCALL may be flagged even though no error occurred.
1 The shutdown was successfully completed. The "close notify" alert was sent and the peer's "close
notify" alert was received.
-1 The shutdown was not successful because a fatal error occurred either at the protocol level or a
connection failure occurred. It can also occur if action is need to continue the operation for
non-blocking BIOs. Call SSL_get_error(3) with the return value ret to find out the reason.
> 2. What is the best practise for shutdown SSL connections for CLIENT?
WANT_READ/WANT_WRITE as required.
--
Viktor.
Serj
Hi, Viktor.
01.02.2015, 23:50, "Viktor Dukhovni" <openss...@dukhovni.org>:
> On Sun, Feb 01, 2015 at 11:36:20PM +0300, Serj wrote:
>> 1. Return values for SSL_shutdown()
>
> 0 initially if shutdown alert sent, but not yet received from
> the peer.
>> I never get 2 as a return value!
>
> Why do you expect "2"? [ Note, something is screwing up itemized
> lists in the on-line documentation. Instead of showing item labels,
> item numbers are showing up instead. ]
Here: https://www.openssl.org/docs/ssl/SSL_shutdown.html I see only this:
-----------------------------------------------------
RETURN VALUES
The following return values can occur:
1. The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.
2. The shutdown was successfully completed. The "close notify" alert was sent and the peer's "close notify" alert was received.
<0
The shutdown was not successful because a fatal error occurred either at the protocol level or a connection failure occurred. It can also occur if action is need to continue the operation for non-blocking BIOs. Call SSL_get_error with the return value ret to find out the reason.
-----------------------------------------------------
> The nroff manpage says:
> RETURN VALUES
> The following return values can occur:
>
> 0 The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional
> shutdown shall be performed. The output of SSL_get_error(3) may be misleading, as an erroneous
> SSL_ERROR_SYSCALL may be flagged even though no error occurred.
>
> 1 The shutdown was successfully completed. The "close notify" alert was sent and the peer's "close
> notify" alert was received.
>
> -1 The shutdown was not successful because a fatal error occurred either at the protocol level or a
> connection failure occurred. It can also occur if action is need to continue the operation for
> non-blocking BIOs. Call SSL_get_error(3) with the return value ret to find out the reason.
Seems to be this is right.
This is exactly what I wanted to see here: https://www.openssl.org/docs/ssl/SSL_shutdown.html
>> 2. What is the best practise for shutdown SSL connections for CLIENT?
>
> Call ssl_shutdown() and if it returns 0, call it again processing
> WANT_READ/WANT_WRITE as required.
I use non-blocking sockets. That's why I got -1 as return value after first ssl_shutdown().
I process WANT_READ/WANT_WRITE. But some servers don't send "close_notify", so we never got a 1 as a return value.
We must be sure that server got a "close_notify" - this is the question! What is the best practise for that?
--
Best Regards,
Serj
Viktor Dukhovni
> > Why do you expect "2"? ?[ Note, something is screwing up itemized
> > lists in the on-line documentation. ?Instead of showing item labels,
>
> Here: https://www.openssl.org/docs/ssl/SSL_shutdown.html I see only this:
> -----------------------------------------------------
> RETURN VALUES
>
> The following return values can occur:
>
> 1. The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.
>
> 2. The shutdown was successfully completed. The "close notify" alert was sent and the peer's "close notify" alert was received.
>
> <0
--
Viktor.
Serj
02.02.2015, 01:13, "Viktor Dukhovni" <openss...@dukhovni.org>:
But what about the best practise for shutdown of connection on the client side?
Server can don't send "close notify" alert.
And what about the best practise for shutdown of connection on the server side? Is it mandatory to wait "close_notify" from client to be able to save valid session for this client or not? If server close the connection after all data has been sent to the client and don't receive "close_notify", will be the session kept?
--
Best Regards,
Serj
Viktor Dukhovni
> But what about the best practice for shutdown of connection on the client side?
http://tools.ietf.org/html/rfc5246#section-7.2.1
> And what about the best practice for shutdown of connection on the server
> save valid session for this client or not? If server close the connection
> after all data has been sent to the client and don't receive "close_notify",
> will be the session kept?
--
Viktor.
Serj
02.02.2015, 02:08, "Viktor Dukhovni" <openss...@dukhovni.org>:
> On Mon, Feb 02, 2015 at 01:32:42AM +0300, Serj wrote:
>> But what about the best practice for shutdown of connection on the client side?
>
> http://tools.ietf.org/html/rfc5246#section-7.2.1
I read RFC. Have read "7.2.1. Closure Alerts" once again.
But this is the normative document. I ask: what in practise in terms of OpenSSL API?
As I already said some servers don't send "close_notify" and just close the connection.
So I think the shutdown algorithm for SSL client must be the following:
-------------------------------------------------------------------------
//...
//all data was obtained from the server
if (SSL_shutdown(ssl)==1)
{
closesocket(s)
goto l_shutdown_complete;
}
shutdown(s,SD_SEND);
//set timeout for getting "close_notify" from SERVER
//in the cycle... waiting events from socket or timeout (which comes first):
//
//1. process SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE (in this case only SSL_ERROR_WANT_READ because seems to be SSL_shutdown() send "close_notify" alert to SERVER), call SSL_shutdown() once again and examine it's return value for 1 OR examine SSL_get_shutdown() for (SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN)
//
//2. Wait FD_CLOSE
//
//3. Timeout
//if one of three happens closesocket(s)
-------------------------------------------------------------------------
>> And what about the best practice for shutdown of connection on the server
>> side? Is it mandatory to wait "close_notify" from client to be able to
>> save valid session for this client or not? If server close the connection
>> after all data has been sent to the client and don't receive "close_notify",
>> will be the session kept?
>
> http://tools.ietf.org/html/rfc5246#section-7.2.1
I ask: what in practise in terms of OpenSSL API?
If SERVER close the connection after all data has been sent to the client and will not wait for "close_notify" alert from CLIENT, will be the session kept and valid in OpenSLL API?
I mean, can CLIENT then reuse this session, if it doesn't send "close_notify" alert? Or this session will be invalid?
--
Best Regards,
Serj
Viktor Dukhovni
> > http://tools.ietf.org/html/rfc5246#section-7.2.1
>
> I read RFC. Have read "7.2.1. Closure Alerts" once again.
> But this is the normative document. I ask: what in practise in terms of OpenSSL API?
>
> As I already said some servers don't send "close_notify" and just close the connection.
end-of-data indication. For example, with SMTP client sends
"QUIT<CRLF>" and server sends "221 Goodbye", there's no need to
explicitly perform an SSL_shutdown(). However, Postfix does it
by the book per TLSv1.0:
if (SSL_shutdown() == 0)
SSL_shutdown()
with appropriate handling of WANT_READ/WANT_WRITE, timeouts, ...
> >> And what about the best practice for shutdown of connection on the server
> >> side? Is it mandatory to wait "close_notify" from client to be able to
> >> save valid session for this client or not? If server close the connection
> >> after all data has been sent to the client and don't receive "close_notify",
> >> will be the session kept?
> >
> > http://tools.ietf.org/html/rfc5246#section-7.2.1
>
> I ask: what in practise in terms of OpenSSL API?
> If SERVER close the connection after all data has been sent to the client and will not wait for "close_notify" alert from CLIENT, will be the session kept and valid in OpenSLL API?
without waiting for a client response. If the server destroys the
SSL connection without calling SSL_shutdown() I am not sure whether
the session remains cached.
> I mean, can CLIENT then reuse this session, if it doesn't send "close_notify" alert? Or this session will be invalid?
to the reuse the session, worst-case the server will perform a full
handshake anyway.
--
Viktor.
Serj Rakitov
It should be sufficient for the server to send its close notify
without waiting for a client response. If the server destroys the
SSL connection without calling SSL_shutdown() I am not sure whether
the session remains cached.I mean, can CLIENT then reuse this session, if it doesn't send "close_notify" alert? Or this session will be invalid?Try it, see what happens. The client is certainly free to *try*
to the reuse the session, worst-case the server will perform a full
handshake anyway.