Implicit vs Explicit TLS in FTPS

The secure extension of FTP otherwise known as FTPS take its root from 1997 with RFC959 and was later refined in 2001 before taking its latest form in 2005 with RFC4217. Those RFCs have defined various modes for FTPS known as Implicit and Explicit TLS.

Before we dive in, the gist of Explicit vs Implicit lies in the name, with explicit, the FTP client need to request the usage of a secure communication exlicitly whereas in implicit mode it is already assumed the connection to the server must happen through TLS like you would do on your browser when visiting an HTTPS website.

Recap on TLS

In TLS we need to go through a serie of steps to initiate the secure connection, first of we need to get through a TCP Handshake to establish the connection between the client and the server. When the connection is established we must initiate a TLS Handshake which starts with the client sending a “Client Hello” message.

That’s all we need to know about TLS to fully grasp the difference between Explicit and Implicit TLS but if you want to dig deeper and enter the wonderfull world of TLS1.3, RSA, Diffie Hellman, you can checkout this introduction video on TLS:

Implicit TLS

When you visit an HTTPS website, your browser choose by default to implicitly use port 443 and the entire connection is made from there. That’s exactly the same with FTPS with Implicit TLS except it’s not port 443 that was registered to the IANA but port 990.

By the moment the TCP handshake completes and the connection is established, the TLS handshake must start with the client sending a TLS Hello to the server. In the case where such message isn’t received, the server will drop the connection:

~ # telnet 990
Connected to
Escape character is '^]'.
Connection closed by foreign host.

Effectively, Implicit TLS prevents client from using an insecure connection either by mistake or lazyness as the connecting client must understand TLS to be able to do anything on that server:

~ # openssl s_client -connect
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN =
verify return:1
Certificate chain
0 s:CN =
i:C = US, O = Let's Encrypt, CN = R3
a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA256
v:NotBefore: Nov 26 09:47:16 2023 GMT; NotAfter: Feb 24 09:47:15 2024 GMT
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
Server certificate
subject=CN =
issuer=C = US, O = Let's Encrypt, CN = R3
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
SSL handshake has read 3385 bytes and written 400 bytes
Verification: OK
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 3072 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
220 Rebex FTP Server ready.

In practice, Implicit TLS is the lesser use TLS mode when it comes to FTPS as the IETF did deprecate it: “This approach is not favoured by the IETF and should not be used for new FTP-TLS implementations.”

Explicit TLS

This mode doesn’t have a dual in the HTTPS world. The idea behind explicit is you start connecting to your FTPS server like you would do on your FTP server, typically on port 21 and then ask the server to switch to a secure connection using the AUTH command.

~ # telnet 21
Connected to
Escape character is '^]'.
220 Rebex FTP Server ready.
234 Switching to TLS.

It’s only from that point onward that client can initiate the TLS handshake by sending the TLS Hello. AUTH TLS isn’t the only available security mechanism, it’s the most popular but they were some other ones like “AUTH SSL” which got deprecated in 2001 and GSSAPI which is defined in RFC2228