In FTP SSL closure is supposed to work as follows:
- The client sends an I-want-to-close message to the server.
- The client waits for the server's reply.
- Once the server receives the message it replies with its own I-want-to-close message and shuts down the connection.
- Once the client receives the server's reply it closes the connection.
Keep in mind that FTP uses multiple connections for each session - one for sending commands (the control channel) and one for
each file transfer (the data channels).
The SSL closure-related flags in SSLFTPClient may be explained as follows:
- DISABLE_CONTROL_WAIT_ON_CLOSE stops the client from waiting for the server's reply when closing the control channel. In other words, it sends the I-want-to-close message but then just closes the connection straight afterwards.
- DISABLE_CONTROL_SSL_CLOSURE stops the client from sending the I-want-to-close message on the control channel - it simply closes the control channel without warning.
- DISABLE_DATA_WAIT_ON_CLOSE stops the client from waiting for the server's reply when closing a data channel.
- DISABLE_DATA_SSL_CLOSURE stops the client from sending the I-want-to-close message on a data channel
- DISABLE_WAIT_ON_CLOSE stops the client from waiting for the server's reply when closing all channels - control and data.
- DISABLE_SSL_CLOSURE turns off SSL closure altogether for all channels - control and data.
It's actually quite safe to disable SSL closure on the control channel since the server and client have already agreed to close by means of the standard QUIT command.
The data channels are a different matter since the means of determining the end of a transfer is in fact the closure of the data channel. In other words, when the client uploads a file, the server only knows that the client has finished when it detects that the client has closed that data channel. This makes it vulnerable to 'truncation attacks', which are attacks where the channel is closed before a transfer is complete. In standard FTP, the server has no way of knowing that such an attack has occurred. SSL closure prevents this happening in FTPS since both parties must agree that they're going to close the channel before they do so. So if the channel is closed without an SSL closure being completed then the receiving end should assume that there's been a truncation attack and therefore discard the data that it's just received.
Unfortunately compliance is poor in this area. Our experience is that a lot of servers don't perform an SSL closure exchange (they simply close the connection abruptly) and are therefore vulnerable to truncation attacks. It's not a major problem though since truncation attacks are quite difficult to carry out (requiring perfect timing and a high level of access) and are often not a great risk in terms of loss.
Anyway, it is for this reason that we've had to introduce these flags.
What does this mean for you?
- DISABLE_DATA_SSL_CLOSURE should be off if possible in order to reduce truncation attacks. Having said that, I've never heard of a server that will reject an upload, as it should, if there was no SSL closure, which really makes it rather pointless. If you're concerned about truncation attacks when downloading then you should keep it off, otherwise you may turn it on in order to increase compatibility.
- DISABLE_CONTROL_SSL_CLOSURE is safe to turn on since the client and server effectively go through their own closure exchange using the standard FTP QUIT command and reply. And again, I've never heard of a server providing the option to abandoning an entire session if the control channel was not closed using an SSL closure.
- The XXX_WAIT_ON_CLOSE flags should prevent hanging, but since they stop the client from confirming that the SSL closure exchange was completed they do weaken security slightly.
Is that clear? I'm afraid I've rambled on a bit here, but it is a rather complex topic.
- Hans (EnterpriseDT)
