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.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
