Understanding the Difference: SSL Tunnel vs SSH Tunnel

Secure communication comes in many forms — from browsers to servers to applications and various other services. A lot of communication across the internet occurs behinds the scenes. In a sense, most/all of it does. This is where an SSL tunnel or SSH tunnel comes into play.

We need to ensure that some communication is really secure as it’s used for remote purposes or joining networks together to exchange/share services or it may secure functionality over users’ data or control what websites actually do.

The term tunneling can be interchangeable with connection/communication. It’s a “techy” term we (us IT people) use all of the time. When we talk about an SSL tunnel, we may mean something specific like a virtual private network (VPN) tunnel. But it really can mean just a connection to a remote server in general. There is a proxy, or intermediary, between the user client and endpoint. Proxy server (and network) configuration would be needed to listen for the connection and have a route to get to the end service.

Now, an SSL tunnel is different than an SSH tunnel. SSH, or what’s known as secure shell, calls for a service to be running on the endpoint, often a server, and client machine to call to it over the SSH protocol, with proper authentication to the server in order to get to a shell and take command of the server. It doesn’t explicitly call for the transfer of files, unless a transfer protocol is invoked, such as FTP, SFTP or SCP (which is actually done over the SSH protocol) but rather commands and such to control the PC as if you were in front of it.

While SSL tunneling and SSH tunneling sound very similar, there are key differences. This is why we’ll now cover the similarities and differences between SSL and SSH for tunneling.

An SSL Tunnel: How It Works

Within SSL tunneling, when the connect request is made from client to server, the DNS will have routed it to the proxy server. The client’s connect request is made over the specified port, SSL/TLS is port 443 by default, but they could actually utilize a different port, if specified, to connect to the client to the proxy server.

From there, the proxy server would also send a request to connect to the end machine (server) on behalf of the client. It may use the same port, or it may use a different port. It’s also possible for the proxy server to have a persistent connection to the server side, which would often be utilized for higher amounts of traffic (frequency) and all requests from clients would be encapsulated by that tunnel. This minimizes the overhead “cost” of building the connection and then tearing it down for each transaction. It’s all dependent on how the system is set up: who is making the requests, whether client requests are limited to a set of users, etc.

At that point, the proxy would be just that — a mediator between the client and the server. It’s a passthrough. The client and server would be encrypting/decrypting to each other with the proxy, as it would be designed, only acting as the mediator without accessibility to the unencrypted data. It’s basically another layer of security to prevent a variety of attacks that range from code injection to distributed denial of service (DDoS) to the server (which may be serving many clients).

An SSH Tunnel: How It Differs from an SSL Tunnel

SSH tunneling is the orange to the SSL tunneling’s apple; as in, they are both fruit, but the intention and usage is kind of different. The analogies are mixed, but, hopefully, you understand the reference.

SSH is a sort of reworking of the simple Telnet, which is used to create a session to a remote machine — often a server — to control, make changes, etc. Telnet, which sends everything in plaintext, should have been long deprecated as SSH is a far more secure and utilized option. Telnet may be okay for use within private networks but even still — SSH is simple enough to provide the same functionality without creating additional risk.

How SSL Tunneling Works

SSH is a pretty simple to set up:

• A remote machine must have SSH service running;
• It must allow (via firewall rules or other security protocol/implementation) a client machine to come in; and
• The client machine must have proper credentials from the remote machine with the applicable permissions (or ability to invoke the correct permissions via sudo or root access) to perform whatever operations it intends to do. The authentication can also be certificate based, which has its own set of pros and cons with it.

Depending on how the remote machine is set up, the client machine should be able to connect via SSH through a public-facing connection (public IP) or a private IP (LAN connection or a VPN may be required).

Once the connection is made, the client machine is in the remote machine’s shell, which can range from bash, ksh, csh, etc. While it’s not a hard-and-fast rule, most people are SSHing into a Linux-based machine though you are able to shell to Windows machines. Most people would just remote, RDP, RealVNC, TeamViewer, etc. into a Windows machine and then just PowerShell/DOS from there.

Now, one would be able to set up a proxy for SSH that would work very similarly to the previous section. At that point, you’d kind of have your “apprange”/”oranpple” — an apple and orange hybrid — where those two functions would be kind of next to each other. And, when utilizing SSH with proper port forwarding, it would be possible to encrypt a connection between a client and a server/service that may have otherwise gone unencrypted.

Final Thoughts

While the similarities are there for an SSH/SSL tunneling — and in a sense, I would say that SSH tunneling is a type of SSL tunneling — they are still two separate processes and are used for different purposes. However, they both have their place:

• SSH is, again, a highly utilized protocol, used very often across the internet; and
• SSL tunneling has its place, often in VPN (though IPSec is also utilized).

Secure tunneling continues to pick up the pace as data breaches, malicious code, people and privatization continue to come to the forefront of data traversing across the internet. Stay safe, weigh all options, and go for best and safest practices — even if this process calls for extra work.