ssl: read pending close notify alert before closing the connection #7095
This avoids a TCP reset (RST) if the server initiates a connection
For SSL connections, usually the server announces that it will close the
See RFC 1122, section 188.8.131.52
If curl reads the close notify alert, the TCP connection is closed
The new code is similar to existing code in the "SSL shutdown" function:
This avoids a TCP reset (RST) if the server initiates a connection shutdown by sending an SSL close notify alert and then closes the TCP connection. For SSL connections, usually the server announces that it will close the connection with an SSL close notify alert. curl should read this alert. If curl does not read this alert and just closes the connection, some operating systems close the TCP connection with an RST flag. See RFC 1122, section 184.108.40.206 If curl reads the close notify alert, the TCP connection is closed normally with a FIN flag. The new code is similar to existing code in the "SSL shutdown" function: try to read an alert (non-blocking), and ignore any read errors.
This pull request implements a fix for:
I am not sure whether a fix is also needed for:
Probably no fix is needed, because
How to test (on Linux, with the openssl TLS backend)
The Apache HTTP server will send a close notify alert and close the connection after the response because of the header "Connection: close".
Without the fix:
With the fix:
The RST/FIN TCP flags can be observed with Wireshark.
It's fine to use buf and probably safer. This still has the issue there is a race condition where the alert may be received after the read call. I think the only way to deal with this correctly is a non-blocking SSL shutdown state that times out after xx seconds. See also #6149. Though this appears to be an improvement.
The documentation of OpenSSL does not say anything about passing
Thank you for the link to #6149. A non-blocking SSL shutdown state would be difficult to implement. I hope that this improvement is "good enough".