Re: [openssl-users] What is the best practise for shutdown SSL connections?
Hi, Viktor. 02.02.2015, 18:04, "Viktor Dukhovni" openssl-us...@dukhovni.org:It should be sufficient for the server to send its close notifywithout waiting for a client response. If the server destroys theSSL connection without calling SSL_shutdown() I am not sure whetherthe 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 fullhandshake anyway. Thank you for answers. I will try. --Best Regards, Serj Rakitov ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
On Mon, Feb 02, 2015 at 09:23:19AM +0300, Serj wrote: 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. If you close first, that's OK. Also OK, if there's an application-level end-of-data indication. For example, with SMTP client sends QUITCRLF 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? 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. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
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. ] 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? Call ssl_shutdown() and if it returns 0, call it again processing WANT_READ/WANT_WRITE as required. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] What is the best practise for shutdown SSL connections?
Hello, 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
Re: [openssl-users] What is the best practise for shutdown SSL connections?
On Mon, Feb 02, 2015 at 12:28:12AM +0300, Serj wrote: 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 formatting of itemized lists in the on-line HTML is broken. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
Hi, Viktor. 01.02.2015, 23:50, Viktor Dukhovni openssl-us...@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 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
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 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 -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
02.02.2015, 01:13, Viktor Dukhovni openssl-us...@dukhovni.org: The formatting of itemized lists in the on-line HTML is broken. Ok. 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 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
Hi, Viktor.
02.02.2015, 02:08, Viktor Dukhovni openssl-us...@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
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
