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