SSH vs SSL vs TLS: What Each Actually Protects

The short version

• SSH — Secure Shell; remote login and command execution. Runs on port 22.
• SSL — Secure Sockets Layer. Deprecated. All versions have known vulnerabilities.
• TLS — Transport Layer Security. SSL's successor; secures HTTPS, SMTP, IMAP, LDAP, and more.

Side-by-side

	SSH	SSL (deprecated)	TLS
Primary purpose	Remote shell + tunneling	Generic transport security (historical)	Generic transport security (current)
Default port	22	443 (HTTPS)	443 (HTTPS), others
Auth model	Public keys or password	Certificates	Certificates
Current version	SSHv2	SSL 3.0 (deprecated 2015)	TLS 1.3 (2018)
Typical use	Admin, Git, SCP, port forwarding	Don't use	HTTPS, APIs, email, VPNs
Mutual auth typical?	No (but possible)	No	No (but mTLS is a thing)

Why SSL is dead

Every version of SSL has known, exploitable vulnerabilities. SSL 2.0 and 3.0 were deprecated years ago. When people say "SSL certificate" today, they almost always mean a TLS certificate — the term stuck around because "install an SSL certificate" has become a familiar phrase. If you see a tool advertising "SSL 3.0 support," avoid it.

What TLS actually does

TLS runs on top of TCP and provides three properties:

1. Encryption — no one on the network can read the content
2. Integrity — no one can modify content in transit without being detected
3. Authentication — the server is who its certificate claims (via a chain to a trusted CA)

What SSH actually does

SSH is purpose-built for shell access, with a few extras that make it uniquely useful:

• Remote command execution — run commands on another machine as if local
• Port forwarding — tunnel arbitrary TCP connections through the encrypted link (local, remote, and dynamic)
• SCP / SFTP — copy files over the same authenticated channel
• Key-based auth — public/private keypair eliminates password guessing
• Agent forwarding — use your local SSH keys from a remote session

Which to use for what

• Webbrowser → server — TLS (via HTTPS). Nothing else.
• API clients → API — TLS.
• Email submission / retrieval — TLS (via SMTPS, IMAPS, POP3S).
• Developer → Linux/macOS server — SSH. On port 22.
• Developer → GitHub/GitLab — SSH for Git operations (or HTTPS + personal access token; same security).
• Encrypted tunnel for a non-HTTPS service — SSH port forwarding is usually simplest.

Common misconceptions

• "SSH uses SSL" — No. SSH is a separate protocol with its own cryptographic handshake.
• "TLS is just SSL 4" — TLS 1.0 was derived from SSL 3.1; TLS 1.2 and 1.3 are substantially different and more secure.
• "HTTPS uses SSL" — HTTPS now uses TLS exclusively. The "S" in HTTPS historically meant SSL; now it means TLS.
• "I need an SSH certificate" — SSH uses keys, not certificates (though cert-based SSH auth exists, it's rarer).

Related security tools

Generating SSH keypairs and strong passwords: password generator. Hashing (for integrity checks on downloaded TLS tools): hash generator. Base64 encoding (JWT auth, Basic auth headers): Base64.