SSH and SSL/TLS are two widely used cryptographic protocols for establishing secure connections and ensuring secure communication between two parties over an unsecured network. While both protocols offer the same benefits—authentication, encryption, and data integrity—they are designed for different use cases and have distinct features. Here is a deep dive into how they work, what they are used for, and how they differ from each other.

What is SSL/TLS Used for?

SSL stands for Secure Sockets Layer, and TLS stands for Transport Layer Security. SSL is the older version of the protocol and was deprecated in 2015. Most modern browsers don’t support it anymore. TLS is the current, updated version of the SSL. However, SSL continues to be used interchangeably with TLS out of habit.

SSL/TLS is a PKI-based security protocol used to secure web traffic between a client and a server. It provides a mechanism to authenticate a server and establish a secure line of communication between clients and servers.

SSL/TLS, commonly associated with HTTPS, is primarily designed to secure browser-server communications, where the browser refers to the client and the server refers to the web server hosting the website users want to visit. SSL/TLS enables the web browser to authenticate the web server. Authenticating the web server assures end users that the connection between them and the website is secure. SSL/TLS also helps encrypt the data in transit, ensuring that the data shared between users and the website remains confidential and unaltered.

Today, all legitimate websites are expected to be secured with an SSL/TLS certificate. These digital certificates are signed by a trusted Certificate Authority (CA) to prove the legitimacy of the website to the user. Leading browsers discourage users from accessing websites without a valid SSL/TLS certificate through security warnings.

While SSL/TLS is largely used to secure browser-server communication, it is also used to secure other forms of web communication, such as emails and VoIP calls.

How Does SSL/TLS Work?

SSL/TLS works on the client-server model. For a client to establish a secure connection with a server, the two parties first perform a process called the “TLS handshake.” Let us consider a browser-server connection as an example to understand how the TLS handshake using the RSA algorithm works.

1. Client Hello: The browser connects to port 443 and initiates a TLS handshake with the server by sending a “Client Hello” message. This message contains information such as the TLS versions and cipher suites that the client supports and a 32-byte random number generated by the client (called the Client Random).
2. Server Hello: The server listens for new connections on port 443 and responds to the “Client Hello” with a “Server Hello” message. The server selects a TLS version and cipher from the browser’s list, generates another 32-byte random number (called the Server Random) and sends it back to the browser along with the server’s SSL certificate, which contains its public key.
3. Server Authentication: The browser then uses the SSL/TLS certificate to verify the server’s identity. It checks if the certificate is signed by a Certificate Authority (CA) that it trusts and the certificate has not expired or revoked. In that case, the browser confirms that the server is the legitimate owner of the website and proceeds with the connection. Otherwise, it prompts the user to terminate the connection with a warning.
4. Client Key Exchange: In the next step, the browser verifies if the server has the private key corresponding to the public key shared in its SSL/TLS certificate. The browser generates a pre-master secret, a 48-byte random number, encrypts it with the server’s public key obtained from the server’s certificate, and sends it back to the server. If the server is legitimate, it can decrypt the pre-master secret with its private key (known only to it). Now, both the browser and the server have the pre-master secret.
5. Session Key Generation: Using the pre-master secret, Client Random, and Server Random, both the browser and the server calculate a master secret called the session key. This symmetric key will be used to encrypt and decrypt all messages exchanged in that particular session. The session key is discarded after the session terminates.
6. Session Key Verification: Once the session key is generated on both ends, the browser sends a “Finished” message to the server, encrypted with the session key. If the server has generated the same session key, it can decrypt that message. The server then verifies if the browser has the correct session key by sending another “Finished” message encrypted with the session key to the browser.
7. Handshake Completion: At this point, the handshake process is completed, and a secure connection is established. The browser and server begin their communication.

What is SSH Used for?

SSH stands for Secure Shell. It is a cryptographic network protocol used for secure remote access to systems and servers over an untrusted network. SSH provides a mechanism for mutual authentication between a client (local machine) and a server (remote host) and establishes an encrypted channel of communication between them.

SSH is designed to secure a wide variety of use cases. It enables information security specialists, developers, and system administrators to:

• Remotely log into other systems on the network
• Execute commands on remote systems
• Deliver software updates remotely
• Transfer files
• Manage critical network infrastructure systems such as routers, firewalls, servers, and Operating Systems

How Does SSH Work?

Similar to SSL/TLS, SSH also works on the client-server model. But in the case of SSH, the “SSH client” is a piece of software on the user’s system that can communicate with the remote host, and the “SSH server” is the remote host that provides access via a secure SSH connection.

The SSH handshake process is as follows:

1. Server Verification:

• The client initiates an SSH handshake with the server, which listens to port 22 by default for SSH connections. During this process, the client and server negotiate parameters for the connection, including encryption algorithms and protocols.
• If the client is accessing the server for the first time, the client is prompted to authenticate the server by verifying the server’s public key. The server then presents its public key to prove its identity to the client. Once the key is verified, the server is added to the “known_hosts file” on the client machine for future verifications.
• If the client is not accessing the server for the first time, the server’s identity is verified against the information in the known_hosts file.

2. Session Key Generation:

After server verification, both parties mutually generate a session key using the Diffie-Hellman algorithm. The session key is a symmetric key that will be used to encrypt and decrypt the data exchanged during the session.

3. Client Authentication:

• In the last step, the server authenticates the client, either by means of receiving an encrypted password or via SSH keys. Since passwords are less secure than SSH keys due to their vulnerability to brute-force attacks, the use of the latter is recommended.
• The SSH key-based authentication begins with the client sending the server the public key (from the key pair) it would like to authenticate itself with. In this case, the server should have a pre-exchanged copy of the client’s public key, meanwhile the client has the corresponding private key.
• The server verifies the existence of the client’s public key in its database. The server then uses the client’s public key to encrypt a message with a random number and sends it back to the client.
• If the client has the corresponding private key, it can decrypt the message and access the random number.
• The client then uses the random number and the shared session key to create a new hash value and sends it back to the server.
• The server receives this hash value and then creates its own hash value (using the original random number and the shared session key). If both hash values match, the server takes it as proof that the client is the owner of the private key and grants it authentication.
• Once authentication is complete, both parties open up an encrypted channel to communicate with each other.

SSL/TLS and SSH: Key Differences

• Application and the Level of Security: SSH is best suited for highly secure remote access to servers and devices. On the other hand, SSL/TLS is effective in securing internet communications such as web browsing, email, and online transactions. To achieve the level of functionality SSH offers, SSL/TLS authentication would have to be deployed alongside other protocols like FTP (File Transfer Protocol). This is an expected limitation since SSL/TLS provides security for extremely high traffic volumes, which usually do not require such specialized functionality (for instance, visitors on a shopping website), while SSH keys are used only within or between IT/security teams of organizations.
• Authentication Process: SSH implements mutual authentication. It involves both the client and server mutually authenticating each other with their public and private key pairs, respectively. But in the case of an SSL/TLS connection, most often, only the server needs to authenticate itself to the client using its public and private key pair. The client does not have to prove its authenticity to the server. Simply put, SSH users are privileged users authorized to access remote systems and must prove their authenticity to the server to get access. With SSL, website users don’t have to authenticate themselves to the web server.
• Authentication Methods: SSH supports various authentication methods, including passwords, SSH keys, and SSH certificates, whereas SSL/TLS relies only on the digital certificate that is issued by a trusted CA for authentication. Without a certificate accompanying the public key, SSL/TLS cannot be safely used over the Internet. In the case of SSH keys, the use of SSH keys is not governed or regulated by a central body. They are generated, distributed, and used strictly by the transacting parties involved.
• Port Forwarding: SSH supports port forwarding, also known as SSH tunneling. This feature allows users to securely route network traffic from one network port on a client machine to another network port on a remote server or vice versa. This helps redirect network traffic to a particular port/IP address so that a remote server is made directly accessible by applications on the client machine. SSL does not provide native support for port forwarding.
• Implementation: SSL is relatively easy to use and does not require much configuration. SSH, on the other hand, can be complex to configure and use.

Both SSL/TLS and SSH machine identities (certificates and keys) are utilized extensively by organizations to ensure secure communication and access control across their networks. As organizations shift to identity-first security strategies, managing these identities becomes paramount. The AppViewX platform helps organizations efficiently discover, manage, automate, and govern SSL/TLS and SSH identities at scale. Contact us to see a demo or learn more!

*** This is a Security Bloggers Network syndicated blog from Blogs Archive - AppViewX authored by Krupa Patil. Read the original post at: https://www.appviewx.com/blogs/ssh-vs-ssl-tls-whats-the-difference/