[openssl-dev] [openssl.org #2749] SSL_shutdown() doesn't need to ever return 0
It could return zero, even if now it doesn't and I'm not sure that's true. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2749 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl.org #2749] SSL_shutdown() doesn't need to ever return 0
John Gardiner Myers via RT wrote: However my point of view is: Actually there is. It is important for OpenSSL to convey back to the application when it has successfully carried out all the following tasks: * to encode SSL control packet (with the way OpenSSL is imlemented this actually means to have flushed all outstanding application payload data down) * to enqueue SSL control packet * to push SSL control packet into BIO / kernel layers In reference to the data that makes up the SSL control packet indicating end-of-encrypted-stream. Any one of these operations might fail due to network conditions. Knowing this state has occurred is important if you want to call TCP shutdown(fd, SHUT_WR) on the underlying socket. Which is a TCP level end-of-write-stream indicator. The current documentation does not permit the caller to infer that it is safe to do a TCP shutdown(SHUT_WR) from a 0 return value. Neither does the implementation--it will return a 0 before the output BIO has been completely flushed. You are correct on the documentation, the only issue there is that it has not been updated since it took some years to get the patch to support -1/WANT_WRITE and -1/WANT_READ into the main tree. But non the less the documentation can be updated to explain this subtle point. With regards to the Neither does the implementation - Show me your test case proving this claim as I have a testcase that proves it has worked in at least the usage case tested in the matter I described. If you search this mailing list you should find a version of it posted in the past. If you are found to be correct then this would be a bug from my point-of-view in that it should be maintaining a -1/WANT_WRITE soft-error state everytime SSL_shutdown() is called while the BIO can not be successfully flushed (due to IO blockage on the write side). As for your other comments I have not responded as the most important thing you can do now is prove your claim so the bug can be understood and fixed. Thanks Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2749] SSL_shutdown() doesn't need to ever return 0
John Gardiner Myers via RT wrote: There's no good reason for SSL_shutdown() to ever return a value of 0. The attached patch simplifies things. One point of view is: Maybe so. But this is how it has always worked and is documented as such. Your patch does not attempt to update the documentation which talks of the return value 0 which now won't exist. However my point of view is: Actually there is. It is important for OpenSSL to convey back to the application when it has successfully carried out all the following tasks: * to encode SSL control packet (with the way OpenSSL is imlemented this actually means to have flushed all outstanding application payload data down) * to enqueue SSL control packet * to push SSL control packet into BIO / kernel layers In reference to the data that makes up the SSL control packet indicating end-of-encrypted-stream. Any one of these operations might fail due to network conditions. Knowing this state has occurred is important if you want to call TCP shutdown(fd, SHUT_WR) on the underlying socket. Which is a TCP level end-of-write-stream indicator. A single return value of 1 can not indicate both points in the proceedings. * The point the SEND shutdown control packet has been push into BIO / kernel layers. * The point in the proceedings when both the SEND and the RECEIVE end-of-encrypted-stream control packet have been fully processed. So maybe for you it seems like a simplification as you have a simpler mental model of what is going on :) If there was a chance to start over I think a much better interface would be to return the state of the SSL_RECEIVED_SHUTDOWN and SSL_SENT_SHUTDOWN flags, i.e. just like SSL_get_shutdown() would instead of 0 or 1 scenarios that currently exist. Regards, Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2749] SSL_shutdown() doesn't need to ever return 0
John Gardiner Myers via RT wrote: There's no good reason for SSL_shutdown() to ever return a value of 0. The attached patch simplifies things. One point of view is: Maybe so. But this is how it has always worked and is documented as such. Your patch does not attempt to update the documentation which talks of the return value 0 which now won't exist. However my point of view is: Actually there is. It is important for OpenSSL to convey back to the application when it has successfully carried out all the following tasks: * to encode SSL control packet (with the way OpenSSL is imlemented this actually means to have flushed all outstanding application payload data down) * to enqueue SSL control packet * to push SSL control packet into BIO / kernel layers In reference to the data that makes up the SSL control packet indicating end-of-encrypted-stream. Any one of these operations might fail due to network conditions. Knowing this state has occurred is important if you want to call TCP shutdown(fd, SHUT_WR) on the underlying socket. Which is a TCP level end-of-write-stream indicator. A single return value of 1 can not indicate both points in the proceedings. * The point the SEND shutdown control packet has been push into BIO / kernel layers. * The point in the proceedings when both the SEND and the RECEIVE end-of-encrypted-stream control packet have been fully processed. So maybe for you it seems like a simplification as you have a simpler mental model of what is going on :) If there was a chance to start over I think a much better interface would be to return the state of the SSL_RECEIVED_SHUTDOWN and SSL_SENT_SHUTDOWN flags, i.e. just like SSL_get_shutdown() would instead of 0 or 1 scenarios that currently exist. Regards, Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2749] SSL_shutdown() doesn't need to ever return 0
On 4/25/2012 1:21 AM, Darryl Miles via RT wrote: John Gardiner Myers via RT wrote: There's no good reason for SSL_shutdown() to ever return a value of 0. The attached patch simplifies things. One point of view is: Maybe so. But this is how it has always worked and is documented as such. Your patch does not attempt to update the documentation which talks of the return value 0 which now won't exist. That was deliberate. The patched implementation conforms to the interface contract of the existing documentation. If the corresponding change were made to the documentation, then callers written to the new documentation would fail when run against downrev/existing versions of the library. Put another way, the implementation change is appropriate for a minor release. The obvious corresponding documentation change is only appropriate for a major release. However my point of view is: Actually there is. It is important for OpenSSL to convey back to the application when it has successfully carried out all the following tasks: * to encode SSL control packet (with the way OpenSSL is imlemented this actually means to have flushed all outstanding application payload data down) * to enqueue SSL control packet * to push SSL control packet into BIO / kernel layers In reference to the data that makes up the SSL control packet indicating end-of-encrypted-stream. Any one of these operations might fail due to network conditions. Knowing this state has occurred is important if you want to call TCP shutdown(fd, SHUT_WR) on the underlying socket. Which is a TCP level end-of-write-stream indicator. The current documentation does not permit the caller to infer that it is safe to do a TCP shutdown(SHUT_WR) from a 0 return value. Neither does the implementation--it will return a 0 before the output BIO has been completely flushed. A single return value of 1 can not indicate both points in the proceedings. * The point the SEND shutdown control packet has been push into BIO / kernel layers. * The point in the proceedings when both the SEND and the RECEIVE end-of-encrypted-stream control packet have been fully processed. So maybe for you it seems like a simplification as you have a simpler mental model of what is going on :) As I mentioned above, neither does the existing return value of 0 indicate this. If one wants to encode assumptions about the actual behavior of the existing TLS protocol and that one is not currently doing a handshake, one could use a return value of -1 plus a SSL_get_error() of SSL_ERROR_WANT_READ to indicate this. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2749] SSL_shutdown() doesn't need to ever return 0
There's no good reason for SSL_shutdown() to ever return a value of 0.
The attached patch simplifies things.
--- openssl-1.0.1-beta3-0orig/ssl/s3_lib.c 2012-02-10 12:08:49.0
-0800
+++ openssl-1.0.1-beta3/ssl/s3_lib.c2012-03-02 11:19:53.847954000 -0800
@@ -4112,7 +4112,7 @@
if (s-s3-alert_dispatch)
return(-1); /* return WANT_WRITE */
}
- else if (s-s3-alert_dispatch)
+ if (s-s3-alert_dispatch)
{
/* resend it if not sent */
#if 1
@@ -4127,7 +4127,7 @@
}
#endif
}
- else if (!(s-shutdown SSL_RECEIVED_SHUTDOWN))
+ if (!(s-shutdown SSL_RECEIVED_SHUTDOWN))
{
/* If we are waiting for a close from our peer, we are closed */
s-method-ssl_read_bytes(s,0,NULL,0,0);
@@ -4137,11 +4137,7 @@
}
}
- if ((s-shutdown == (SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN))
- !s-s3-alert_dispatch)
- return(1);
- else
- return(0);
+ return(1);
}
int ssl3_write(SSL *s, const void *buf, int len)
