RE: How do I correctly handle SSL_shutdown?
Hi, If I understand it correctly the close_notify alert is only there to prevent a truncation attack. If your higher level protocol can check that all expected data is present then it is OK just to close the socket. To be safe it would be better to call SSL_shutdown() in the client when it is complete. In the server you can call SSL_get_shutdown() when you expect the client may disconnect. In the server it should be fine to call SSL_shutdown() anyway. I don't think the SSL specification defines whether the server must send a close_notify. I hope this helps, Mark. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: How do I correctly handle SSL_shutdown?
AFAIK, if a close notify is not sent, the the ssl connection termination is considered premature and the session cannot be reused. The specification does not define it as a MUST, rather it is defined as a SHOULD. If session reuse is not a necessary criteria (if your willing to compromise performance) then server need not send the close notify. Thanks --Gayathri Hi, If I understand it correctly the close_notify alert is only there to prevent a truncation attack. If your higher level protocol can check that all expected data is present then it is OK just to close the socket. To be safe it would be better to call SSL_shutdown() in the client when it is complete. In the server you can call SSL_get_shutdown() when you expect the client may disconnect. In the server it should be fine to call SSL_shutdown() anyway. I don't think the SSL specification defines whether the server must send a close_notify. I hope this helps, Mark. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How do I correctly handle SSL_shutdown?
I think I understand but I still seem to have an issue with my code.
1). Server opens an SSL port for a client to connect to
2). Client connects to this port and SSL_read and Write stuff.
3). Client Calls SSL_shutdown( sslSocket );
4). Server Calls SSL_get_shutdown( sslSocket ), If shutdown is equal to
SSL_RECEIVED_SHUTDOWN the server will
then call SSL_shutdown( sslSocket );
So if the above is correct? I am doing the following to close the
connection and my server does not seem to ever see SSL_RECEIVED_SHUTDOWN
? Could some one please tell me what I am doing wrong?
( Blocking IO )
1). Client sends shutdown
/* Client code to close SSL connection */
if( (SSL *)NULL != sslSocket )
{
if( SSL_ST_OK == SSL_state( sslSocket ) )
{
status = SSL_shutdown( sslSocket );
if( status == 0 )
{
status = SSL_shutdown( sslSocket );
}
}
fd = SSL_get_fd( sslSocket );
close( fd );
SSL_free( sslSocket );
sslSocket = (SSL *)NULL;
}
2). Server checks for shutdown and sends shutdown if SSL_RECEIVED_SHUTDOWN is
returned.
/* Server code to close SSL connection */
if( (SSL *)NULL != sslSocket )
{
if( SSL_RECEIVED_SHUTDOWN == SSL_get_shutdown( sslSocket ) )
{
SSL_shutdown( sslSocket );
}
fd = SSL_get_fd( sslSocket );
close( fd );
SSL_free( sslSocket );
sslSocket = (SSL *)NULL;
}
Thanks,
Perry
Gayathri Sundar wrote:
Hi.,
I think that depends on the mode of SSL meaning blocking/non blocking,
If its the latter then you need to select again before calling the
2nd ssl shutdown and check whether the close notify from the peer is
received by checking the ssl_received_shutdown flag. If this flag is not
set, then you should cleanup or select for a timeout.
This code snippet is true for blocking sockets.
Thanks
--Gayathri
I am confused.
If SSL_shutdown returns 0 then I need to call SSL_shutdown again? So
would I do something like this on the client side?
/* Client code to close SSL connection */
if( (SSL *)NULL != *sslSocket )
{
if( SSL_ST_OK == SSL_state( *sslSocket ) )
{
status = SSL_shutdown( *sslSocket );
if( status == 0 )
{
status = SSL_shutdown( *sslSocket );
}
}
SSL_free( *sslSocket );
*sslSocket = (SSL *)NULL;
}
--
If this is the case what do I do on the server side do I need to uses
SSL_state to check for some shutdown state?
Thanks,
Perry
Victor Duchovni wrote:
On Mon, Dec 19, 2005 at 11:22:11AM -0500, Perry L. Jones wrote:
I have some questions about shutting down an SSL connection.
The correct use of SSL_shutdown() is described in the SSL_shutdown
manpage. Read the whole thing, and pay specific attention to:
When the application is the first party to send the close notify
alert, SSL_shutdown() will only send the alert and the set the
SSL_SENT_SHUTDOWN flag (so that the session is considered good and
will
be kept in cache). SSL_shutdown() will then return with 0. If a
unidi-
rectional shutdown is enough (the underlying connection shall be
closed
anyway), this first call to SSL_shutdown() is sufficient. In order to
complete the bidirectional shutdown handshake, SSL_shutdown() must be
called again. The second call will make SSL_shutdown() wait for the
peer's close notify shutdown alert. On success, the second call to
SSL_shutdown() will return with 1.
If the peer already sent the close notify alert and it was already
processed implicitly inside another function (SSL_read(3)), the
SSL_RECEIVED_SHUTDOWN flag is set. SSL_shutdown() will send the
close
notify alert, set the SSL_SENT_SHUTDOWN flag and will immediately
return with 1. Whether SSL_RECEIVED_SHUTDOWN is already set can be
checked using the SSL_get_shutdown() (see also SSL_set_shutdown(3)
call.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: How do I correctly handle SSL_shutdown?
If the server is unable to see the SSL_RECEIVED_SHUTDOWN, then probably
the close notify did not go on the wire, i.e client failed sending it?
Can you check the wire to see if it actually went out?
Try calling ssl_get_error to see the status on the error queue.
Also by any chance have you set the quiet shutdown mode in ur ctx?
if that is set, then the alert will not be sent on the wire..
This is what I get from man SSL_shutdown
SSL_shutdown() tries to send the close notify shutdown alert to the
peer. Whether the operation succeeds or not, the SSL_SENT_SHUTDOWN
flag is set and a currently open session is considered closed and good
and will be kept in the session cache for further reuse.
I think I understand but I still seem to have an issue with my code.
1). Server opens an SSL port for a client to connect to
2). Client connects to this port and SSL_read and Write stuff.
3). Client Calls SSL_shutdown( sslSocket );
4). Server Calls SSL_get_shutdown( sslSocket ), If shutdown is equal to
SSL_RECEIVED_SHUTDOWN the server will
then call SSL_shutdown( sslSocket );
So if the above is correct? I am doing the following to close the
connection and my server does not seem to ever see SSL_RECEIVED_SHUTDOWN
? Could some one please tell me what I am doing wrong?
( Blocking IO )
1). Client sends shutdown
/* Client code to close SSL connection */
if( (SSL *)NULL != sslSocket )
{
if( SSL_ST_OK == SSL_state( sslSocket ) )
{
status = SSL_shutdown( sslSocket );
if( status == 0 )
{
status = SSL_shutdown( sslSocket );
}
}
fd = SSL_get_fd( sslSocket );
close( fd );
SSL_free( sslSocket );
sslSocket = (SSL *)NULL;
}
2). Server checks for shutdown and sends shutdown if SSL_RECEIVED_SHUTDOWN
is returned.
/* Server code to close SSL connection */
if( (SSL *)NULL != sslSocket )
{
if( SSL_RECEIVED_SHUTDOWN == SSL_get_shutdown( sslSocket ) )
{
SSL_shutdown( sslSocket );
}
fd = SSL_get_fd( sslSocket );
close( fd );
SSL_free( sslSocket );
sslSocket = (SSL *)NULL;
}
Thanks,
Perry
Gayathri Sundar wrote:
Hi.,
I think that depends on the mode of SSL meaning blocking/non blocking,
If its the latter then you need to select again before calling the
2nd ssl shutdown and check whether the close notify from the peer is
received by checking the ssl_received_shutdown flag. If this flag is not
set, then you should cleanup or select for a timeout.
This code snippet is true for blocking sockets.
Thanks
--Gayathri
I am confused.
If SSL_shutdown returns 0 then I need to call SSL_shutdown again? So
would I do something like this on the client side?
/* Client code to close SSL connection */
if( (SSL *)NULL != *sslSocket )
{
if( SSL_ST_OK == SSL_state( *sslSocket ) )
{
status = SSL_shutdown( *sslSocket );
if( status == 0 )
{
status = SSL_shutdown( *sslSocket );
}
}
SSL_free( *sslSocket );
*sslSocket = (SSL *)NULL;
}
--
If this is the case what do I do on the server side do I need to uses
SSL_state to check for some shutdown state?
Thanks,
Perry
Victor Duchovni wrote:
On Mon, Dec 19, 2005 at 11:22:11AM -0500, Perry L. Jones wrote:
I have some questions about shutting down an SSL connection.
The correct use of SSL_shutdown() is described in the SSL_shutdown
manpage. Read the whole thing, and pay specific attention to:
When the application is the first party to send the close notify
alert, SSL_shutdown() will only send the alert and the set the
SSL_SENT_SHUTDOWN flag (so that the session is considered good and
will
be kept in cache). SSL_shutdown() will then return with 0. If a
unidi-
rectional shutdown is enough (the underlying connection shall be
closed
anyway), this first call to SSL_shutdown() is sufficient. In order to
complete the bidirectional shutdown handshake, SSL_shutdown() must be
called again. The second call will make SSL_shutdown() wait for the
peer's close notify shutdown alert. On success, the second call to
SSL_shutdown() will return with 1.
If the peer already sent the close notify alert and it was already
processed implicitly inside another function (SSL_read(3)), the
SSL_RECEIVED_SHUTDOWN flag is set. SSL_shutdown() will send the
close
notify alert, set the SSL_SENT_SHUTDOWN flag and will immediately
return with 1. Whether SSL_RECEIVED_SHUTDOWN is already set can be
checked using the SSL_get_shutdown() (see also SSL_set_shutdown(3)
call.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: How do I correctly handle SSL_shutdown?
On Mon, Dec 19, 2005 at 11:22:11AM -0500, Perry L. Jones wrote: I have some questions about shutting down an SSL connection. The correct use of SSL_shutdown() is described in the SSL_shutdown manpage. Read the whole thing, and pay specific attention to: When the application is the first party to send the close notify alert, SSL_shutdown() will only send the alert and the set the SSL_SENT_SHUTDOWN flag (so that the session is considered good and will be kept in cache). SSL_shutdown() will then return with 0. If a unidi- rectional shutdown is enough (the underlying connection shall be closed anyway), this first call to SSL_shutdown() is sufficient. In order to complete the bidirectional shutdown handshake, SSL_shutdown() must be called again. The second call will make SSL_shutdown() wait for the peer's close notify shutdown alert. On success, the second call to SSL_shutdown() will return with 1. If the peer already sent the close notify alert and it was already processed implicitly inside another function (SSL_read(3)), the SSL_RECEIVED_SHUTDOWN flag is set. SSL_shutdown() will send the close notify alert, set the SSL_SENT_SHUTDOWN flag and will immediately return with 1. Whether SSL_RECEIVED_SHUTDOWN is already set can be checked using the SSL_get_shutdown() (see also SSL_set_shutdown(3) call. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How do I correctly handle SSL_shutdown?
I am confused.
If SSL_shutdown returns 0 then I need to call SSL_shutdown again? So
would I do something like this on the client side?
/* Client code to close SSL connection */
if( (SSL *)NULL != *sslSocket )
{
if( SSL_ST_OK == SSL_state( *sslSocket ) )
{
status = SSL_shutdown( *sslSocket );
if( status == 0 )
{
status = SSL_shutdown( *sslSocket );
}
}
SSL_free( *sslSocket );
*sslSocket = (SSL *)NULL;
}
--
If this is the case what do I do on the server side do I need to uses
SSL_state to check for some shutdown state?
Thanks,
Perry
Victor Duchovni wrote:
On Mon, Dec 19, 2005 at 11:22:11AM -0500, Perry L. Jones wrote:
I have some questions about shutting down an SSL connection.
The correct use of SSL_shutdown() is described in the SSL_shutdown
manpage. Read the whole thing, and pay specific attention to:
When the application is the first party to send the close notify
alert, SSL_shutdown() will only send the alert and the set the
SSL_SENT_SHUTDOWN flag (so that the session is considered good and will
be kept in cache). SSL_shutdown() will then return with 0. If a unidi-
rectional shutdown is enough (the underlying connection shall be closed
anyway), this first call to SSL_shutdown() is sufficient. In order to
complete the bidirectional shutdown handshake, SSL_shutdown() must be
called again. The second call will make SSL_shutdown() wait for the
peer's close notify shutdown alert. On success, the second call to
SSL_shutdown() will return with 1.
If the peer already sent the close notify alert and it was already
processed implicitly inside another function (SSL_read(3)), the
SSL_RECEIVED_SHUTDOWN flag is set. SSL_shutdown() will send the close
notify alert, set the SSL_SENT_SHUTDOWN flag and will immediately
return with 1. Whether SSL_RECEIVED_SHUTDOWN is already set can be
checked using the SSL_get_shutdown() (see also SSL_set_shutdown(3)
call.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: How do I correctly handle SSL_shutdown?
Hi.,
I think that depends on the mode of SSL meaning blocking/non blocking,
If its the latter then you need to select again before calling the
2nd ssl shutdown and check whether the close notify from the peer is
received by checking the ssl_received_shutdown flag. If this flag is not
set, then you should cleanup or select for a timeout.
This code snippet is true for blocking sockets.
Thanks
--Gayathri
I am confused.
If SSL_shutdown returns 0 then I need to call SSL_shutdown again? So
would I do something like this on the client side?
/* Client code to close SSL connection */
if( (SSL *)NULL != *sslSocket )
{
if( SSL_ST_OK == SSL_state( *sslSocket ) )
{
status = SSL_shutdown( *sslSocket );
if( status == 0 )
{
status = SSL_shutdown( *sslSocket );
}
}
SSL_free( *sslSocket );
*sslSocket = (SSL *)NULL;
}
--
If this is the case what do I do on the server side do I need to uses
SSL_state to check for some shutdown state?
Thanks,
Perry
Victor Duchovni wrote:
On Mon, Dec 19, 2005 at 11:22:11AM -0500, Perry L. Jones wrote:
I have some questions about shutting down an SSL connection.
The correct use of SSL_shutdown() is described in the SSL_shutdown
manpage. Read the whole thing, and pay specific attention to:
When the application is the first party to send the close notify
alert, SSL_shutdown() will only send the alert and the set the
SSL_SENT_SHUTDOWN flag (so that the session is considered good and
will
be kept in cache). SSL_shutdown() will then return with 0. If a
unidi-
rectional shutdown is enough (the underlying connection shall be
closed
anyway), this first call to SSL_shutdown() is sufficient. In order to
complete the bidirectional shutdown handshake, SSL_shutdown() must be
called again. The second call will make SSL_shutdown() wait for the
peer's close notify shutdown alert. On success, the second call to
SSL_shutdown() will return with 1.
If the peer already sent the close notify alert and it was already
processed implicitly inside another function (SSL_read(3)), the
SSL_RECEIVED_SHUTDOWN flag is set. SSL_shutdown() will send the
close
notify alert, set the SSL_SENT_SHUTDOWN flag and will immediately
return with 1. Whether SSL_RECEIVED_SHUTDOWN is already set can be
checked using the SSL_get_shutdown() (see also SSL_set_shutdown(3)
call.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
