<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Thanks for your response, Viktor. You views fall in line with our opinions on how the situation should be handled.<div><br></div><div>Any other opinions?</div><div><br><br><div>> Date: Mon, 20 Apr 2015 16:26:43 +0000<br>> From: openssl-users@dukhovni.org<br>> To: openssl-users@openssl.org<br>> Subject: Re: [openssl-users] Peer closing connection with a FIN without first sending a close_notify<br>> <br>> On Mon, Apr 20, 2015 at 03:03:37PM +0000, Jason Schultz wrote:<br>> <br>> > We am seeing the following situation and are not quite sure the proper<br>> > way to handle it, so I thought I'd solicit the mailing list. Our application<br>> > is an FTP server using OpenSSL. The peer is a non-OpenSSL FTP client in<br>> > active mode. The problem comes in with how the FTP client handles closing<br>> > the data connection after doing a put and transferring a file from client<br>> > to our server. Instead of sending a close_notify, it closes the connection<br>> > with a TCP FIN. <br>> <br>> That's wrong. This client snatches defeat from the jaws of victory,<br>> by failing to take advantage of the TLS shutdown facility to securely<br>> signal end of data. Without SSL shutdown the data transfer is<br>> vulnerable to truncation attacks.<br>> > <br>> > On our server, calls to SSL_read() and SSL_get_error() indicate an<br>> > SSL_ERROR_SYSCALL, which we treat as a protocol violation and abort the<br>> > connection. When the FTP implementation sees the abort, it tears down<br>> > the connection and throws the file away.<br>> <br>> That's sensible default behaviour I think, but you may need<br>> work-arounds for broken clients.<br>> <br>> > If we change our server to look for this specific case, and indicate a<br>> > close to the FTP application instead of an abort, the FTP transfer completes<br>> > successfully.<br>> <br>> Apply this work-around to as few clients as possible.<br>> <br>> > This is where our questions arise. First of all, the FTP client's close<br>> > without being preceded by a close_notify seems to be a violation of the<br>> > protocol, and OpenSSL handles it as such.<br>> <br>> Correct.<br>> <br>> > Does changing the way it's handled open up our application to truncation<br>> > attacks?<br>> <br>> Yes.<br>> <br>> > We have also read that this particular behavior is not unheard of in SSL<br>> > implementations, and treating the TCP FIN as a proper way to close the<br>> > connection as described above is OK.<br>> <br>> Only when the application-level protocol contains sufficient framing,<br>> to make additional framing in TLS redundant. This is not the case<br>> in FTP in stream mode. FTP in block mode can signal end of file via<br>> the block headers, and then TLS shutdown is not needed. (I've never<br>> seen FTP used in block mode).<br>> <br>> > Given the conflicting information we have seen, what is the opinion of<br>> > the OpenSSL team?<br>> <br>> I don't speak for the team. My opinion is that the client is broken<br>> unless it is using FTP in some manner that provides in-band file<br>> integrity.<br>> <br>> So any work-around may require client-specific configuration so as<br>> not to downgrade all clients.<br>> <br>> -- <br>> Viktor.<br>> _______________________________________________<br>> openssl-users mailing list<br>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users<br></div></div> </div></body>
</html>