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>
