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
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
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
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
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
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 =
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
