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 List openssl-users@openssl.org
>Automated List Manager [EMAIL PROTECTED]
>
>
>
>______________________________________________________________________
>OpenSSL Project http://www.openssl.org
>User Support Mailing List openssl-users@openssl.org
>Automated List Manager [EMAIL PROTECTED]
>
>
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
