We'll analyze the FTPS setup activities first.
I'm skipping the basic TCP port 21 setup chatter for brevity.
First, the client sends the FEAT command,
requesting a list of capabilities supported by the server.
The server replies with many capabilities, three of which are relevant to FTPS.
I'll briefly recap them.
The AUTH TLS capability is the server saying I
support TLS for security via FTPS.
The PBSZ capability is somewhat vestigial and is used to
specify the protection buffer size, which is not relevant for TLS-based privacy.
The PROT capability,
not to be confused with the FTP active mode PORT command allows the client to
choose different security levels for the FTP data channel.
There are four options, and we will see two of them in this module.
The client then requests authentication via TLS,
utilizing the explicit FTPS design option.
Interestingly, if you look back at the unsecure FTP captures,
this AUTH TLS request happened there too,
but the server replied with, send me your username instead.
Back then, the server didn't support TLS, but the client asked anyway.
This time, the server replies with a 234 message,
instructing the client to use FTPS.
What follows is generally unreadable.
The FTP client and server go through a lengthy exchange of encryption methods,
key exchanges, and the like.
Some of this is the plain text TLS exchange,
which isn't a secret,
and some includes encrypted FTP signaling commands and responses.
I want to point out that this is still regular TCP port 21 FTP traffic,
as FTPS encrypts only the FTP signaling and data payloads.
After all, we saw the feature exchange in plain text just moments ago.
If you look hard enough, you may see a bit of plain text in the payload,
such as the FTP server's IP address of 10.2 .5 .5,
but this wasn't a secret anyway.
My main point is that the data is protected and we don't need to
rehash all the basic FTP operations at this point.
We will analyze an FTPS active mode download operation first.
Just like regular FTP active mode,
the server initiates a session to the client source from port 20.
Where did the destination port 48163 come from?
Pause the video if you need a moment.
Within the secure communications channel,
the client used the PORT command to tell the server to use
PORT 48163 when establishing a session.
One weakness of FTPS is that even though the payloads are encrypted,
attackers can still determine whether a client is using active or
passive mode just by looking at the ports in use.
After the TCP setup, we see FTP data transferred from client to server.
FTPS requires additional chatter in the data channel that FTP did not.
However,
the download does eventually occur in FTP data packets from server to client.
I'm showing the byte data because it is no longer ASCII text,
easily readable in Wireshark. The data has been encrypted successfully.