Security protocols
TLS: the layer that proves the server’s identity with a certificate, agrees on fresh keys and then encrypts and integrity-checks every byte for the protocol above it.
How they work
TLS sits between a reliable transport and the application. In TLS 1.3 the client’s first message already carries its key share; the server answers with its own, and everything after that, the server’s certificate included, is encrypted. The client checks that the certificate is valid for the host it asked for, and both sides derive keys that protect every record against reading and tampering. A full handshake costs one round trip; a returning client can send early (0-RTT) data, which an attacker could replay.
The same TLS protects HTTPS, FTPS and mail, and QUIC builds it into its own handshake. Versions matter: SSL 3.0 must not be used (RFC 7568), TLS 1.0 and 1.1 were deprecated in 2021 (RFC 8996), and TLS 1.3 removed static RSA key exchange, so every public-key key exchange now has forward secrecy.
SSH, which carries SFTP, solves the same problem with its own transport protocol rather than TLS: it authenticates the server, encrypts and checks integrity, then runs user login and channels on top.
Technologies
What all network protocols have in common →Sources
- RFC 9846: TLS 1.3 (Jul 2026, obsoletes RFC 8446)
- RFC 8446: TLS 1.3 (Aug 2018)
- RFC 9110, section 4.3.4: https certificate verification
- RFC 7568: Deprecating SSL 3.0 (Jun 2015)
- RFC 8996: Deprecating TLS 1.0 and TLS 1.1 (Mar 2021)
- RFC 4217: Securing FTP with TLS (modelled on TLS for SMTP and HTTP)
- RFC 9001: Using TLS to secure QUIC (May 2021)
- RFC 4251: The SSH protocol architecture (Jan 2006)