Transport layer security (TLS)

Transport layer security (TLS) is a cryptographic protocol that protects data during transfer. It delivers authentication, encryption and integrity for information in motion. TLS replaced the older SSL protocol, which is now obsolete. It is a core standard for securing transfers such as HTTPS, SMTP and FTPS.

TLS relies on public-key cryptography to verify a server for the client. This step prevents spoofing attempts. After verification, the two sides create symmetric keys that keep traffic private. Integrity checks run during the session to confirm that files remain unchanged.

File transfer servers most often use TLS through FTPS. FTPS offers two security modes. Explicit FTPS begins with a client request for encryption. Implicit FTPS denies all unencrypted sessions. Both modes protect legacy file exchanges without redesigning them.

TLS versions and features

TLS 1.3, released in 2018, is the protocol’s most recent version. The protocol was originally defined in 1999, with each version introducing updates to encryption algorithms, handshake procedures and session handling to improve both performance and protection during file transfers.

Version 1.3’s features include:

• Certificate validation that confirms server identity and helps prevent impersonation attacks
• Forward secrecy that uses ephemeral keys to prevent decryption of past sessions
• Reduced handshake latency
• The removal of insecure algorithms, such as RSA key exchange

TLS 1.2 and 1.3 are now considered the baseline for secure file transfer protocols that must pass modern compliance checks.

What TLS does — and doesn’t do

TLS plays a key role in securing file transfers, but it does not provide complete protection on its own. It only operates during transit and depends on other systems and configurations to secure the broader file exchange process.

Here’s what TLS does in the context of managed file transfer (MFT) or file transfer protocol (FTP):

• Authenticates endpoints using digital certificates and public key infrastructure
• Encrypts data in transit to prevent eavesdropping or man-in-the-middle attacks
• Maintains session integrity to detect tampering or packet injection

TLS does not: 

• Control user access or permissions, which requires server-side policy enforcement
• Encrypt data at rest, which must be handled separately

TLS must be combined with access controls, logging, automation and storage protections to meet end-to-end security and compliance requirements.

Enabling and managing TLS

Managing TLS connections requires you to configure the correct certificates, ports and protocol values on your web-facing servers (such as your file transfer server). 

These configuration aspects include:

• Allowing TLS 1.2 or TLS 1.3 only on your web servers
• Applying cipher suites that satisfy policy and compliance goals
• Creating an SSL/TLS certificate to authenticate your servers
• Enabling ports 21, 990 and 989 for FTPS transfers, or port 443 for HTTPS 
• Selecting explicit or implicit TLS modes to meet client needs
• Tracking handshake errors and certificate expiry through logs and alerts

TLS handshake: How a secure connection is made

A TLS handshake starts the secure connection between the client and server. It sets rules for ciphers, checks identity and prepares the path for private data. No user data moves until this phase ends.

The steps in a TLS handshake are:

• Client hello: The client lists supported TLS versions, cipher suites and a fresh random number for entropy.
• Server hello: The server chooses one version, selects one suite and sends its leaf certificate to the client to verify its identity.
• Key exchange: Both hosts derive a shared secret through an ephemeral Diffie‑Hellman method.
• Certificate verification: The client validates the certificate chain against trusted roots inside its store.
• Session confirmation: Each side returns a finished record that proves they share the same secret keys.

After the handshake finishes, traffic shifts to symmetric ciphers such as AES‑GCM to keep packets fast and private.

TLS encryption: Two types working together

TLS encryption uses both asymmetric and symmetric cryptography during a file transfer session. Each method serves a distinct purpose in establishing and maintaining secure communication between systems.

Asymmetric (public key)

Asymmetric encryption, also known as public key encryption, is used during the TLS handshake. The client uses the server’s public key to encrypt a shared secret, which only the server can decrypt with its private key. This process allows both parties to agree on encryption parameters without prior contact.

Symmetric (session key)

Once the handshake is complete, TLS shifts to symmetric encryption using a session key. This key is used for all subsequent communication to enable faster encryption and decryption. Both parties use the same key, which keeps the session confidential and efficient.

Together, these two methods allow TLS to combine secure key exchange with high-performance encryption. This layered approach protects both the setup phase and the file transfer itself.

 

 

Transport layer security FAQs