Let's reconfigure our FTP server for FTPS and use
active mode to download a file.
Before this demo,
I used OpenSSL to generate a self-signed certificate and private key,
which are required on the FTPS server.
In a real design,
you'd follow the certificate signing request process to
request a certificate from a real CA and import the
resulting certificate from the CA instead.
I'd like to focus on the configuration changes rather than the cert generation.
I'll quickly explain each of the six new lines.
I recommend disabling anonymous FTP connections when FTPS is used.
This improves security.
The next two commands force the client to use SSL.
This means unsecure FTP simply isn't supported.
Setting these to no might be a good choice during an FTP-to-FTPS migration,
but otherwise, answering yes is more secure.
The next three lines are the minimum configuration required.
You must specify where your certificate and private key files are stored.
These were the outputs from the self-signed certificate generation process,
and I put them in the directories specified.
If you are not using Ubuntu, the paths might be different,
so be sure to consult the manual for your specific operating system.
Finally, we must toggle FTPS to be enabled.
If you ever need to do a quick test with unsecure FTP,
you can simply change this to no without needing to
delete the previous five lines.
Just for good measure, I'll restart the vsftpd service.
This is required anytime you change the configuration file.
Let's check out the lftp script to perform an FTP active
mode download with SSL protection.
The nice thing about FTPS is that it is very similar to unsecure FTP,
both in protocol operation and user interface.
The only change to the LFTP script is an option I've enabled not
to verify the self-signed SSL certificate.
This is normally a bad idea,
since without this trust the connection isn't truly secure.
I felt this was the simplest way to demonstrate some lftp options
and also not spend too much time focusing on SSL.
Let's run the script and evaluate the results.
After the initial TCP connection on port 21 and the feature exchange,
the client responds with the AUTH TLS command.
This notifies the server that the client wants to use FTPS explicitly,
so the server directs the client to proceed.
In the packet capture,
everything that follows is encrypted and generally unreadable,
which makes lftp a handy tool for visualizing the flow details.
Notice the warning about SSL certificate trust issues.
We've manually overridden the trust process,
which for the purpose of learning FTPS is acceptable.
Let's skip the login details and other basic FTP chatter.
We see the PBSZ 0 command sent.
The protection buffer size is only relevant when using
non-TLS protection at the application level,
and it is not relevant here.
The PROT command toggles between four different protection options.
I'll show them all in orange, but only C and P are used in this exchange.
Basically, P means secure data channel and C means unsecure data channel.
Reference RFC 4219 section 9 for more details.
After enabling privacy with PROT P,
the PORT command is sent and the regular FTP active mode process occurs.
As we already know, each individual command gets its own data session,
even actions like listing the directory contents.
Let's get past that.
One thing worth noticing is that lftp changes back
to clear text mode using PROT C, but only until the next download occurs.
At that point,
the server sends a 522 message instructing the client
to enter private mode using PROT P.
Everything that follows is classic FTP active mode, as FTPS doesn't change the process.