On Thu, Apr 2, 2015 at 6:19 AM, Joel Sing <js...@cvs.openbsd.org> wrote: > CVSROOT: /cvs > Module name: src > Changes by: js...@cvs.openbsd.org 2015/04/02 07:19:15 > > Modified files: > lib/libtls : tls.c tls_init.3 > > Log message: > Handle the case where multiple calls to SSL_shutdown() are required to > close the connection. Also correctly handle the error on failure.
Hmm, I'm not convinced this is the Right Thing. Waiting for the other side's close-notify is only necessary if you want to go back to cleartext communication on the socket, but in the common socket case, tls_close() also shuts down the socket. Worse, for many protocols where application-level framing prevents the truncation attacks that close-notify alerts were invented to prevent, the common behavior is for only one side to send a close-notify.If you send one and then wait for a reply, you may get EOF; if you receive one and then try to send one, you may get EPIPE as the other end tore down its end and will send RST packets for any new data. In either of those cases, the tls_close() will fail even though things are Just Fine. For example, after sending an SMTP QUIT, an SMTP server knows the client is done communicating and won't send more commands, so it can send the SMTP "221 Bye", then do the TLS close-notify and close the socket without waiting. The client reads the SMTP response (or not), but then it has no need to send a close-notify: it already told the server it's done (at the application layer), the TLS connection is useless that point, and it's just a waste of CPU and bandwidth to send one...and it'll just generate an error anyway! More thought is needed here, IMO... Philip Guenther
