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. _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
