[openssl-users] Peer closing connection with a FIN without first sending a close_notify

[Jason Schultz]

Greetings.
We am seeing the following situation and are not quite sure the proper way to handle it, so I thought I'd solicit the mailing list. Our application is an FTP server using OpenSSL. The peer is a non-OpenSSL FTP client in active mode.
The problem comes in with how the FTP client handles closing the data connection after doing a put and transferring a file from client to our server. Instead of sending a close_notify, it closes the connection with a TCP FIN. On our server, calls to SSL_read() and SSL_get_error() indicate an SSL_ERROR_SYSCALL, which we treat as a protocol violation and abort the connection. When the FTP implementation sees the abort, it tears down the connection and throws the file away.
Regarding SSL_ERROR_SYSCALL, the OpenSSL documentation says this:
"Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error (for socket I/O on Unix systems, consult errno for details)."
>From this information, we determined we were seeing the case where ERR_get_error() returns 0, meaning an EOF was observed that violates the protocol; the FIN being sent without being preceded by a close_notify. If we change our server to look for this specific case, and indicate a close to the FTP application instead of an abort, the FTP transfer completes successfully.
This is where our questions arise. First of all, the FTP client's close without being preceded by a close_notify seems to be a violation of the protocol, and OpenSSL handles it as such. Does changing the way it's handled open up our application to truncation attacks?
We have also read that this particular behavior is not unheard of in SSL implementations, and treating the TCP FIN as a proper way to close the connection as described above is OK.
Given the conflicting information we have seen, what is the opinion of the OpenSSL team?
Thanks in advance.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150420/215ab150/attachment-0001.html>