> -----Original Message-----
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Donald J.
> Sent: Friday, 08 August, 2014 15:34
> To: openssl-users@openssl.org
> Subject: RST after close_notify
>
> I have an issue with an FTP client issuing a DIR command to a Windows
> FTP server.
> A normal packet trace is shown in sequence 1 below. An "Ack Fin" is
> received
> from the Windows FTP server and the DIR command completes successfully.
Both of your traces below show an RST in the final packet, not a FIN.
> In the 2nd sequence, each side exchanges close_notify, but no "Fin"
> flags are set.
> Windows FTP server ends with an "Ack Rst". After receiving the Reset
> packet,
> the FTP client issues a "connection reset' message" and sets an error
> code.
> Is that the correct thing to do?
Are you questioning the server's behavior, or the client's?
Probably what happened is the server sent its close_notify and then closed its
end of the connection without waiting for the client's close_notify response.
See Eric Rescorla's /SSL and TLS/ book, 8.10, for further discussion. This is
unfriendly behavior by the server, in my opinion, but common enough for
Rescorla to discuss it.
It's also possible the server did an abortive close, which would be the Wrong
Thing to do, but the former case is more likely. And in any event, your client
couldn't distinguish between the two. (And what would you do about it anyway?
If someone else's server behaves badly, you have to deal with it in some
fashion.)
How the client handles receiving a RST (generally manifests as a return code of
-1 from send or recv, with errno set to ECONNRESET [1]; with OpenSSL you should
get SSL_ERROR_SYSCALL and check errno) is a matter of taste. Often you do want
to report that the connection was reset. In this case, though, since a reset is
not unexpected AND you know you've received all the data from the server - you
got its close_notify - it's better to silently ignore it.
In short, the logic should be something like this:
if RST-received
if we were trying to send data
check for a close_notify from the peer
end-if
if close_notify not already recevied from peer
treat as failure
end-if
close socket and clean up
end-if
[1] This assumes the application, if it's running in a POSIX environment, has
set the disposition of the SIGPIPE signal to "ignore". SIGPIPE is a kluge for
applications that don't check the result of the write/send family of system
calls. Any well-written application should ignore it.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
