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

[Viktor Dukhovni]

On Mon, Apr 20, 2015 at 03:03:37PM +0000, Jason Schultz wrote:

> 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. 

That's wrong.  This client snatches defeat from the jaws of victory,
by failing to take advantage of the TLS shutdown facility to securely
signal end of data.  Without SSL shutdown the data transfer is
vulnerable to truncation attacks.
> 
> 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.

That's sensible default behaviour I think, but you may need
work-arounds for broken clients.

> 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.

Apply this work-around to as few clients as possible.

> 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.

Correct.

> Does changing the way it's handled open up our application to truncation
> attacks?

Yes.

> 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.

Only when the application-level protocol contains sufficient framing,
to make additional framing in TLS redundant.  This is not the case
in FTP in stream mode.  FTP in block mode can signal end of file via
the block headers, and then TLS shutdown is not needed.  (I've never
seen FTP used in block mode).

> Given the conflicting information we have seen, what is the opinion of
> the OpenSSL team?

I don't speak for the team.  My opinion is that the client is broken
unless it is using FTP in some manner that provides in-band file
integrity.

So any work-around may require client-specific configuration so as
not to downgrade all clients.

-- 
	Viktor.