Re: [Chicken-hackers] tcp-shutdown

[Thomas Chust]

Seth Alves wrote:
> [...]
> Maybe the library changed at some point?  The docs say this:
> 
>   http://www.openssl.org/docs/ssl/SSL_shutdown.html
> 
>     When the application is the first party to
>     send the "close notify" alert,
>     SSL_shutdown() will only send the alert and
>     then 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.
>     ...
>     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.
> [...]

Hello Seth,

sending the close notify alert still means that you are closing the
entire SSL session, transmitting and receiving end alike. In fact it is
even explicitly allowed by the protocol to close the transport
underlying the SSL session immediately after sending the alert without
waiting for any reply from the other endpoint of the connection.

Therefore it would be perfectly reasonable behaviour for the other
communication endpoint that receives the close notification to abort any
data transmission in progress, to try to reply with a close notification
of its own and then to close the underlying transport as quickly as
possible, too.

The fact that the OpenSSL library doesn't disable data transfer
functions in the connection shutdown state does not mean it is an
especially clever idea to use them. You can send data through a
connection in shutdown state just as well as you can receive data
through that connection, there is just no guarantee whatsoever what will
happen to this data.

There is simply no way in the SSL protocol to say "I'm going to stop
sending data to you, but you may still send data to me using this SSL
session" or to say "I'm no longer reading data from this SSL session but
I will still send data to you". The only thing you can signal is "I'm
not going to use this SSL session any longer at all".

This kind of logic should therefore be handled at higher protocol
levels. In the case of HTTP, for example, a request that is not expected
to be followed by others should carry a connection control header
requesting the connection to be closed and should specify an explicit
content length or use a content transfer encoding that allows precise
determination of the end of the request body.

Ciao,
Thomas


-- 
When C++ is your hammer, every problem looks like your thumb.