Networking Secure Protocols -

Learn how TLS, SSH, and VPN can secure your network traffic.

TLS (Transport Layer Security)

TLS (Transport Layer Security) is a cryptographic protocol operating at the OSI transport
layer that ensures confidentiality and integrity of data transmitted over insecure
networks.

Before TLS, network traffic such as chats, emails, and passwords was often sent in
cleartext, making it easy for attackers in promiscuous mode to capture sensitive
information. TLS evolved from SSL, with Netscape releasing SSL 2.0 in 1995, the IETF
introducing TLS 1.0 in 1999 as an upgrade to SSL 3.0, and TLS 1.3 being released in
2018 with major security improvements. It is essential for secure online activities such as
banking, shopping, email, and messaging. Many protocols have been upgraded with TLS
for security, including HTTP becoming HTTPS, DNS becoming DoT, MQTT becoming
MQTTS, and SIP becoming SIPS.

To use TLS, servers or clients must obtain a signed TLS certificate from a trusted
Certificate Authority (CA), which verifies a Certificate Signing Request (CSR) before
issuing the certificate. Clients confirm the validity of these certificates using trusted CA
certificates pre-installed on their systems or browsers.

HTTPS
HTTP uses TCP on port 80 by default, and all its traffic is sent in cleartext, making it easy
for anyone to intercept and read. After resolving a domain name, the client first
establishes a TCP three-way handshake with the server, then communicates using the
HTTP protocol, such as sending a GET request. In Wireshark, you can see the TCP
handshake packets, followed by the HTTP request and response packets, and finally the
TCP connection termination packets.

HTTPS is simply HTTP running over TLS, typically using port 443. After DNS resolution,
the client establishes a TCP handshake, then sets up a TLS session through a handshake
and negotiation process, and finally sends encrypted HTTP data. In Wireshark, you will
see the TCP handshake packets first, the TLS negotiation packets next, and then
“Application Data,” which is encrypted traffic.

Without the encryption keys, HTTPS traffic appears as unreadable gibberish.

If the TLS keys are available, the HTTP requests and responses become visible inside the
encrypted session. TLS provides security for HTTP without altering TCP/IP or HTTP itself,
simply encrypting the data as it travels
 SMTPS, POP3S, and IMAPS
Adding TLS to SMTP, POP3, and IMAP is no different than adding TLS to HTTP. Similar to
how HTTP gets an appended S for Secure and becomes HTTPS, SMTP, POP3, and IMAP
become SMTPS, POP3S, and IMAPS, respectively. Using these protocols over TLS is no
different than using HTTP over TLS; therefore, almost all the points from the HTTPS
discussion apply to these protocols.

The insecure versions use the default TCP port numbers shown in the table below:

Protocol Default Port Number

HTTP 80
SMTP 25
POP3 110
IMAP 143

The secure versions, i.e., over TLS, use the following TCP port numbers by default:

Protocol Default Port Number

HTTPS 443
SMTPS 465 and 587
POP3S 995
IMAPS 993

TLS can be added to many other protocols; the reasoning and advantages would be
similar.

SSH (Secure Shell)

Telnet allows remote login and administration but sends all traffic in cleartext, making it
easy for attackers to capture credentials. To solve this problem, Tatu Ylönen developed
the Secure Shell (SSH) protocol, releasing SSH-1 in 1995 — the same year Netscape
released SSL 2.0. A more secure version, SSH-2, was introduced in 1996, and in 1999,
the OpenBSD team released OpenSSH, an open-source implementation. Today, most
SSH clients are based on OpenSSH libraries and source code.

OpenSSH offers several benefits. We will list a few key points:

 Secure authentication: Besides password-based authentication, SSH supports

public key and two-factor authentication.
 Confidentiality: OpenSSH provides end-to-end encryption, protecting against
eavesdropping. Furthermore, it notifies you of new server keys to protect against
man-in-the-middle attacks.
  Integrity: In addition to protecting the confidentiality of the exchanged data,
cryptography also protects the integrity of the traffic.
 Tunneling: SSH can create a secure “tunnel” to route other protocols through SSH.
This setup leads to a VPN-like connection.
 X11 Forwarding: If you connect to a Unix-like system with a graphical user
interface, SSH allows you to use the graphical application over the network.

While the TELNET server listens on port 23, the SSH server listens on port 22.

SFTP and FTPS

SFTP stands for SSH File Transfer Protocol and allows secure file transfer. It is part of the
SSH protocol suite and shares the same port number, 22. If enabled in the OpenSSH
server configuration, you can connect using a command such as sftp
username@hostname. Once logged in, you can issue commands such as get filename
and put filename to download and upload files, respectively. Generally speaking, SFTP
commands are Unix-like and can differ from FTP commands.

SFTP should not be confused with FTPS. You are right to think that FTPS stands for File
Transfer Protocol Secure. How is FTPS secured? Yes, you are correct to estimate that it is
secured using TLS, just like HTTPS. While FTP uses port 21, FTPS usually uses port 990. It
requires certificate setup, and it can be tricky to allow over strict firewalls as it uses
separate connections for control and data transfer.

Setting up an SFTP server is as easy as enabling an option within the OpenSSH server.
Like HTTPS, SMTPS, POP3S, IMAPS, and other protocols that rely on TLS for security, FTPS
requires a proper TLS certificate to run securely.

VPN
Consider a company with offices in different geographical locations. Can this company
connect all its offices and sites to the main branch so that any device can access the
shared resources as if physically located in the main branch? The answer is yes;
furthermore, the most economical solution would be setting up a virtual private network
(VPN) using the Internet infrastructure. The focus here is on the V for Virtual in VPN.

When the Internet was designed, the TCP/IP protocol suite focused on delivering packets.
For example, if a router gets out of service, the routing protocols can adapt and pick a
different route to send their packets. If a packet was not acknowledged, TCP has built-in
mechanisms to detect this situation and resend. However, no mechanisms are in place to
ensure that all data leaving or entering a computer is protected from disclosure and
alteration. A popular solution was the setup of a VPN connection. The focus here is on
the P for Private in VPN.
Almost all companies require “private” information exchange in their virtual network. So,
a VPN provides a very convenient and relatively inexpensive solution. The main
requirements are Internet connectivity and a VPN server and client.

Once a VPN tunnel is established, all our Internet traffic will usually be routed over the
VPN connection, i.e. via the VPN tunnel. Consequently, when we try to access an Internet
service or web application, they will not see our public IP address but the VPN server’s.
This is why some Internet users connect over VPN to circumvent geographical
restrictions. Furthermore, the local ISP will only see encrypted traffic, which limits its
ability to censor Internet access.

In other words, if a user connects to a VPN server in Japan, they will appear to the
servers they access as if located in Japan. These servers will customise their experience
accordingly, such as redirecting them to the Japanese version of the service.

Finally, although in many scenarios, one would establish a VPN connection to route all
the traffic over the VPN tunnel, some VPN connections don’t do this. The VPN server may
be configured to give you access to a private network but not to route your traffic.
Furthermore, some VPN servers leak your actual IP address, although they are expected
to route all your traffic over the VPN. Depending on why you are using a VPN connection,
you might need to run a few more tests, such as a DNS leak test.