Tunneling
From Linux 101, The beginner's guide to all things Linux.
Tunneling is one of the most powerful things you can do to a network connection to provide security. The concept is used in many large scale applications, such as with Virtual Private Networks, VPNs.
The concept is fairly straight-forward, though actually implementing it could sometimes be painful. It follows:
- Your normal computer program makes an unprotected network request (download a file, use a VoIP communication tool, anything)
- This network request is intercepted by some tunneling agent (SSH, VPN, etc)
- It is encrypted and sent across the network
- The tunneling agent on the other side of the network receives the encrypted transmission
- It is decrypted and then the tunneling agent makes the client program think the packet just arrived off the network.
- The client machine's program processes the normal network request
This process is repeated for each network packet you send out onto the network. The listing above best describes SSH tunneling. VPN is more cumbersome (deals with many applications, not one), but you can grab the jist of the basics.
[edit] How it works
For the unencrypted example, we will use a simple WWW transaction; lets say you want to read www.slashdot.org. Your computer will determine the IP address of www.slashdot.org with DNS. Once it has the IP address, it will send out a request to the server on port 80. In a TCP connection, there is always a destination port (80, here) and also a source port. Your computer will randomly pick a port between 1024 - 65536 for the source port. It will then send out the request to www.slashdot.org. When slashdot receives this request, it will then reply to you at your source port. Everything that happened transpired unencrypted.
For the encrypted example, let's say you want to tunnel VNC, your desktop sharing utility. This is something you would want encrypted, because if you're sharing your desktop, you could be doing a number of sensitive tasks, like viewing sensitive information, typing passwords, reading your email, or something like that. All of these are tasks that involve information you do not want to share with the world.
Your normal, unencrypted VNC session would follow the same pattern as before: make a random local port, and connect to a destination port of 5900 (5900 because that is just what the protocol uses). After the connection is established, it'd share passwords and settings to authenticate yourself, then the server would start transmitting the desktop to you.
However, now we're going to add in our SSH tunnel agent. Here's what will happen:
Instead of connecting to the remotehost at port 5900, you will connect to localhost at port 5900. SSH will be there listening for incoming connections. When it receives your request, it will encrypt it and send it to the remosthost's port 22 (22 because all SSH traffic happens on port 22; that is the protocol's standard). At the remotehost's port 22 normal SSH will be listening. It will pick up the connection and authenticate you. Then your SSH tunnel will tell the remotehost's SSH that it has tunnel traffic for remotehost's port 5900. The remotehost's SSH will then decrypt the information, and send it to remotehost's port 5900. At port 5900, the VNC server will be waiting for the traffic.
The VNC client and VNC server were never aware that the data it was sending was being encrypted. Thus, you can use or even write very many network programs, but use SSH to encrypt them.
[edit] Restrictions to Tunneling
The restriction to SSH tunneling is that the remotehost's computer must be running SSH, and you must have permission to access the system. You cannot just SSH tunnel all of your internet traffic, unless you only talk to machines you have access to.
The restriction to encryption is speed. If you are running encryption, then you may notice you use more bandwidth to secure your transmission. It will also take processor time to perform the encryption/decryption itself, which now-a-days is rarely an overwhelming issue.
