Re: [Chicken-hackers] tcp-shutdown

[Seth Alves]

Okay, so I'm basically trying to take advantage of a glitch in the
implementation.  Thanks for bearing with me.


On Thu, Jul 26, 2012 at 12:47 PM, Thomas Chust <address@hidden> wrote:
> 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.
>
>