Re:FTPS, SFTP, FTP over SSH, ...
on
R.I.P. FTP
·
· Score: 1
As you say, a lot of confusion - and you've just added to it.
FTPS doesn't have to do a full TLS handshake on the data port - it reuses the SSL session that was negotiated on the control channel.
There are better ways for FTPS to do data connections than PORT and PASV, and I'm in the middle of a series of notes on my blog http://msmvps.com/blogs/alunj that will culminate in describing the best way to handle data connections for modern FTP.
You have confused Implicit and explicit FTPS. Implicit SSL is where the SSL session is established immediately after making the connection; Explicit SSL is where a command is sent to elevate the connection to SSL. Having said that, the weakness you propose as a problem for Explicit SSL is not the problem you think it to be - FTP clients and servers that support FTPS generally have options to refuse to authenticate outside of an SSL session. Good thing too, because the AUTH TLS command forces a logout of any previously authenticated user session within the FTP connection.
Implicit SSL is deprecated in the FTPS standard.
Finally, a late addition to the FTPS standard was to add the CCC command, which keeps the user's session active, and closes the SSL session on the control connection, so that a NAT or other ALG can look for PORT and PASV commands to open up temporary firewall holes for data connections. I'm not sure that I think that's a great idea.
Re:Missing the point...
on
R.I.P. FTP
·
· Score: 1
FTP over SSL _does_ verify the authenticity of the host you are connecting to, in the same way that HTTPS does. Checks that the certificate is issued by a trusted root, and that its CN matches the domain name provided to the client. I agree with you that the bottom line is that companies must stop using unencrypted FTP - I disagree with your conclusion, that all FTP is therefore bad.
Re:SFTP support is still spotty ....
on
R.I.P. FTP
·
· Score: 1
Thanks for the plug for WFTPD (actually you have to get WFTPD Pro for FTPS support).
You might ask your bank why FTPS isn't a supported mechanism, given that it's possible to provide equivalent security through FTPS that they might get through SFTP, and it's a documented protocol, as opposed to SFTP, which has several incompatible versions and no documentation that allows for development of an SFTP implementation without having to refer to other people's source code in order to do so. This is the basic reason why there are so few SFTP implementations from established FTP developers - we don't want to build our implementations from other people's source code, and thus be subject to their licences.
Slashdot Mirror
FTPS doesn't have to do a full TLS handshake on the data port - it reuses the SSL session that was negotiated on the control channel.
There are better ways for FTPS to do data connections than PORT and PASV, and I'm in the middle of a series of notes on my blog http://msmvps.com/blogs/alunj that will culminate in describing the best way to handle data connections for modern FTP.
You have confused Implicit and explicit FTPS. Implicit SSL is where the SSL session is established immediately after making the connection; Explicit SSL is where a command is sent to elevate the connection to SSL. Having said that, the weakness you propose as a problem for Explicit SSL is not the problem you think it to be - FTP clients and servers that support FTPS generally have options to refuse to authenticate outside of an SSL session. Good thing too, because the AUTH TLS command forces a logout of any previously authenticated user session within the FTP connection.
Implicit SSL is deprecated in the FTPS standard.
Finally, a late addition to the FTPS standard was to add the CCC command, which keeps the user's session active, and closes the SSL session on the control connection, so that a NAT or other ALG can look for PORT and PASV commands to open up temporary firewall holes for data connections. I'm not sure that I think that's a great idea.
FTP over SSL _does_ verify the authenticity of the host you are connecting to, in the same way that HTTPS does. Checks that the certificate is issued by a trusted root, and that its CN matches the domain name provided to the client. I agree with you that the bottom line is that companies must stop using unencrypted FTP - I disagree with your conclusion, that all FTP is therefore bad.
Thanks for the plug for WFTPD (actually you have to get WFTPD Pro for FTPS support). You might ask your bank why FTPS isn't a supported mechanism, given that it's possible to provide equivalent security through FTPS that they might get through SFTP, and it's a documented protocol, as opposed to SFTP, which has several incompatible versions and no documentation that allows for development of an SFTP implementation without having to refer to other people's source code in order to do so. This is the basic reason why there are so few SFTP implementations from established FTP developers - we don't want to build our implementations from other people's source code, and thus be subject to their licences.