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

[Jason Schultz]

Thanks for your response, Viktor. You views fall in line with our opinions on how the situation should be handled.
Any other opinions?

> Date: Mon, 20 Apr 2015 16:26:43 +0000
> From: openssl-users at dukhovni.org
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Peer closing connection with a FIN without first sending a close_notify
> 
> 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.
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150421/d95b7928/attachment-0001.html>