In the second part of this series of articles on internet protocols, we shall delve into the journey from unsecure protocols to secure protocols, with a focus on securing the transport and application layers in the OSI model.

The Transmission Control Protocol (TCP) is a transport protocol, as it dictates the way data is sent and received. Before transmitting data, TCP opens a connection with the recipient and ensures that all packets arrive in order once the transmission begins. It is via TCP that the recipient acknowledges receiving each packet that arrives. Missing packets are sent again if receipt is not acknowledged. Hence this is a reliable protocol, but not fast.

TCP and IP were originally designed to be used together, and these are often referred to as the TCP/IP suite. However, other transport protocols can be used with IP. The TCP header has a default size of 20 bytes. Up to 40 bytes of options can be added.

TCP flow

Step 1: Establish the connection

TCP needs a valid connection as a prerequisite. To establish a connection, it follows a three-way handshake method.

• First, the requesting client sends the server a SYN packet including SEQ.
  • SYN: SYN stands for synchronise.
  • SEQ: SEQ is a unique, random number that ensures full transmission in the correct order and without duplicates.
• Once the server has received the packet, it agrees to the connection by returning a SYN-ACK packet. The ACK includes the client’s sequence number plus 1. The client will send some random SEQ number.
  • ACK: ACK stands for acknowledging its own sequence number to the client.
• Finally, the client acknowledges the receipt by sending its own ACK packet, which in this case contains the server’s sequence number plus 1. The client can now begin transferring data to the server.

  

Step 2: Transmit the packets

After the communication gets established, the TCP data is sent. Each packet transferred with data requires acknowledgement; hence the data and sequence are sent. The receiver sends the acknowledgement by increasing the acknowledgment number by the size of the packet received. The sequence and acknowledgement packet make sure the data is received without loss and prevent duplicates.

To avoid lost packets, the sender starts the timer after sending the packet and puts it in the retransmission queue. If the timer runs out and the sender doesn’t receive the acknowledgement, the packet is resent. Here, even if the receiver gets multiple packets due to the slow speed, it will discard the duplicates.

The receiver waits for the packets and assembles them based on the sequence number. Checksum is calculated on both the sending and receiving computer to make sure data integrity is maintained and see if the packet received is indeed the same as the packet that was sent.

Step 3: Connection termination

The session uses a four-way termination sequence by using an additional flag — the FINISHED (FIN) flag. Figure 3 explains the communication, although this happens only with a graceful connection release.

The protocols supported by TCP are:

• File Transfer Protocol (FTP)
• Hypertext Transfer Protocol (HTTP)
• Secure Shell (SSH)

UDP

The User Datagram Protocol, or UDP, is another widely used transport protocol. It’s faster than TCP but is also less reliable. UDP does not make sure all packets are delivered and in order, and it doesn’t establish a connection before beginning or receiving transmissions. UDP is a connectionless protocol, and the packet header size is also smaller than TCP.

Protocols supported by UDP are:

• Dynamic Host Transfer Protocol (DHCP)
• Domain Name System (DNS)
• Trivial File Transfer Protocol (TFTP)
• Voice over Internet Protocol (VoIP)

SSL/TLS

So far we have seen how communication happens in the transportation layer. But the challenge here is data security. The sniffed packets can be easily read. To overcome this, we have SSL/TLS to secure the data in the transport layer.

SSL stands for Secure Socket Layer, and ensures the data is encrypted. TLS stands for Transport Layer Security. It is the advanced version of SSL, but mostly still referred to as SSL. SSL 3.0 was deprecated by IETF in 2015.

SSL and TLS transport protocols are similar but not entirely interoperable. Here are some terms you should get familiar with in connection with these protocols.

Cipher suite: This is a set of algorithms used for securing communications and generally performs the following:

• Key exchange
• Encryption
• Authentication

Digital certificates: These are issued by a trusted certification authority or CA.

Encryption: This makes sure data is encoded in a way it can’t be understood by the eavesdropping middleman. 256-bit encryption keys are now the minimum accepted level of secure connectivity for online banking or electronic commerce transactions.

Asymmetric keys: A public key can encrypt and a private key is used for decryption and signature verification. The common algorithm is RSA (Rivest Shamir Adleman).

Symmetric keys: These use single or shared keys for encryption and decryption.

Asymmetric encryption is not used for bulk data encryption as it is slower; it is used to transfer the symmetric key between two parties, which is quicker and more efficient for encrypting data.

TLS uses strong encryption methods, such as AES. It can work without encryption altogether if only authentication is needed.

TLS 1.3 only supports the modified version of the Diffie-Hellman public-key cryptography algorithm to share a symmetric key between a client and the server. It no longer has the support of the RSA algorithm for the key exchange.

TLS has two layers of operation:

• TLS Record Protocol: This allows the client and server to communicate using some form of encryption algorithm (or without encryption, if desired).
• TLS Handshake Protocol: This allows the client and server to authenticate one another and exchange the encryption keys to be used during the session.

Figure 4 shows how TLS works. You must first establish the TCP/UDP connection and then use the TLS handshake to make a secure connection.

• DH parameter: The Diffie-Hellman (DH) algorithm uses exponential calculations to arrive at the same premaster secret. The server and client each provide a parameter for the calculation, and when combined they result in a different calculation on each side, with results that are equal.
• Client hello: The client sends a hello message with the protocol version, the client random, and a list of cipher suites.
• Server hello: The server replies with its SSL certificate, its selected cipher suite, and the server random.
• Authentication: The client verifies the server’s SSL certificate with the certificate authority that issued it. This confirms that the server is what it says it is, and that the client is interacting with the actual owner of the domain.
• Server’s digital signature: The server uses its private key to encrypt the client random, the server random, and its DH parameter. This encrypted data functions as the server’s digital signature, establishing that the server has the private key that matches with the public key from the SSL certificate matched before.
• Digital signature confirmed: The client decrypts the server’s digital signature with the public key.
• Client DH parameter: The client sends its DH parameter to the server, using the server’s public key.
• Client and server calculate the premaster secret: The client and server use the DH parameters they exchanged to calculate a matching premaster secret separately.
• Session keys created: Now, the client and server calculate session keys from the premaster secret, client random, and server random.
• Client is ready: The client sends a “finished” message that is encrypted with a session key.
• Server is ready: The server sends a “finished” message encrypted with a session key.
• Secure symmetric encryption achieved: The handshake is complete, and communication continues using the session keys.

Using this symmetric key further communication is encrypted and shared. You can find more detailed description about keyless SSL at https://www.cloudflare.com/en-in/learning/ssl/keyless-ssl/.

QUIC

QUIC (Quick UDP Internet Connections) is a new, encrypted by default internet transport protocol that has the best qualities of TCP and TLS built on UDP to enhance security with speed. The intended goal is to eventually replace TCL and TLS on the web.

After years of experimentation, the original protocol designed by Google engineers several years ago has now been adopted by the IETF (Internet Engineering Task Force) for standardisation.

We can see the difference between the handshake time it takes when the connection gets established with normal TCP and TLS vs QUIC in Figure 5.

In the TCP layer we can see a minimum of three round trips, whereas in QUIC it’s just one. This is because UDP is connected less and QUIC runs on top of it, making it more secure and faster. UDP is used since it is already established in all the kernels and acts as the thin layer that supports rapid adoption of QUIC.

In QUIC the initial handshake happens directly with the TLS 1.3 handshake.

Application layer

Telnet vs SSH

Telnet (Teletype network) and SSH (Secure Shell) are protocols used to connect and access the remote system. We can use them to connect to the remote system to perform actions like executing commands, file changes, file copy and move, and so on.

Telnet doesn’t provide authentication and the data is transferred in plain text. SSH is similar to Telnet but is more secure. It consists of three distinct layers.

• Authentication layer: Authenticates the user.
• Connection layer: Manages the communication between the two endpoints after the authentication succeeds, such as opening and closing of communication channels, allowing multiple channels for multiple sessions, and so on.
• Transport layer: After the channel is established for communication, the data encryption, decryption and integrity are taken care of in this layer.

SSH flow: The client contacts the server to initiate a connection. The server responds by sending the client a public cryptography key. The server negotiates parameters and opens a secure channel for the client. The server and client perform asymmetrically to exchange symmetric keys. The user authentication occurs using password and SSH keys. After authentication succeeds, the user, through their client, logs into the server.

SSH uses hashing to make sure the data doesn’t lose its integrity. It uses algorithms for data encryption such as IDEA, Blowfish, DES, 3DES, etc.

FTP vs FTPS/SFTP

FTP or File Transfer Protocol is used for file transfer over the network. It passes the data along with user name and password in plain text, which is pretty risky. FTPS was implemented to overcome this challenge, providing secure connections using SSL/TLS in the transport layer. SFTP or SSH File Transfer Protocol was also implemented to provide security, and uses SSH to transfer the files. Both FTPS and SFTP provide similar functionality using different protocols.

DNS vs DNSSEC

Domain Name System (DNS) was originally designed as an open protocol. DNS servers are organised in a hierarchy. At the top level of the hierarchy, root servers store the complete database of the internet domain names and their corresponding IP addresses.

Different types of DNS servers exist, of which two are common.

Authoritative servers: These servers are definitive for particular domains and provide information about only those domains. An authoritative-only name server returns answers to queries about the domain names that have been specifically configured.

Caching or recursive servers: These servers use recursion to resolve a given name, from the DNS root through to the authoritative name servers of the queried domain.

DNS does not check for credentials before accepting an answer, and attackers exploit this basic vulnerability. An attacker can cause DNS poisoning by delegating a false name to the domain server and providing a false address for the server.

To prevent this from happening, the Domain Name System Security Extensions (DNSSEC) protocol was developed. DNSSEC protects against such attacks by providing a validation path for records. With DNSSEC, validation is done using a key and a signature.

To properly validate the path, DNSSEC must be implemented at each domain level.

The higher organisation level signs the key of the lower domain level. For example, with the domain www.example.com, the root level signs the .com key and the .com level signs the example.com key.

DNSSEC follows the chain of trust from the lowest-level domain to the top-level domain, validating the keys at each level along the way. It was developed to strengthen DNS through digital certificates, public keys and private key encryption.

HTTP vs HTTPS/SHTTP

HTTP is used for basic web connectivity; it occurs on port 80 and uses TCP in the transport layer. No security is provided by using HTTP, as the data is transmitted in plain text.

Security is enabled in the transport layer using SSL/TLS. The HTTPS protocol occurs on port 443. It is the same HTTP protocol but with security in the transport layer itself; a different port number is used to differentiate it from HTTP.

The URL used for HTTP is http://<servername> and for HTTPS it is https://<servername>.

SHTTP or Secure HyperText Transfer Protocol is an alternative to HTTPS, but as it has not been adopted by many web browsers it’s less common than HTTPS. Figure 5 explains the handshake between server and client.

MIME, POP, IMAP vs S/MIME, POP3S, IMAPS

• SMTP or Simple Mail Transfer Protocol was developed to send emails over port 25.
• MIME or Multipurpose Internet Mail Extension Protocol was introduced to allow transfer of non-textual data such as videos, images, audio, and so on.
• S/MIME or Secure/Multipurpose Internet Mail Extension Protocol was developed to enhance communication security, using underlying SSL principles.
• POP or Post Office Protocol and IMAP or Internet Message Access Protocol were developed for receiving email. Here the login credentials are transferred over a plain text network for incoming emails.
• POP3S – port 995 and IMAPS – port 993 were implemented allowing SSL/TLS in the transport layer.

LDAP vs LDAPS

LDAP or Lightweight Directory Access Protocol is a directory service used for fetching user and host information quickly. By default, LDAP is not secure, leading to the development of a secure version called LDAPS.

LDAPS uses SSL/TLS in the transport layer. This is how it works. The LDAP session starts between a client and the LDAP server, commonly referred to as the Directory System Agent (DSA), on default port 636. The server sends a client operation request response — there are various requests a client can make such as bind, search, and entry editing.

The DSA or LDAP server is the database that stores information hierarchically for easy retrieval.

RTP vs SRTP

The RTP protocol is used to transfer audio and video communications. As it transfers data in raw format, it is vulnerable. The SRTP protocol was developed as an extension to provide security by implementing SSL/TLS in the transport layer.

SNMP vs SNMPv3

SNMP or Simple Network Management Protocol is used to collect statistics of devices in the network. This protocol helps to monitor the health of systems, but is not secure.

SNMP version 3 or SNMPv3 was built to overcome these challenges. It was preceded by SNMPv1 and SNMPv2 but these were built primarily for performance and not security.

NTP vs NTS

NTP or Network Time Protocol is used to synchronise time within the devices with the network time server. It has the same weakness as other non-secure protocols. To overcome this, NTS has been developed with a similar mechanism by including SSL/TLS in the transport layer.

Insecure protocols	Secure protocols	Transport layer	Use cases
TCP or UDP	SSL/TLS	Transport layer
IP	IPSec – AH/ESP and Tunnel/ Transport	Network layer
FTP	SFTP / FTPS	TCP	File transfer protocol
Telnet	SSH	TCP	Remote access
DNS	DNSSEC	TCP/UDP	Domain name resolution
HTTP	HTTPS/SHTTP	TCP	Web
NTP	NTS	TCP	Time synchronisation
SNMP	SNMPv3	TCP	Network monitoring
RTP	RTPS	UDP (mostly)	Voice and video
LDAP	LDAPS	TCP	Directory services
MIME, POP, IMAP	S/MIME, POP3S, IMAPS	TCP	Email subscription services

The table above summarises the secure and insecure protocols we have briefly touched upon so far.

We have now learnt about the secure transfer of data and how it is sent to the intended recipient. As a key takeaway, it is essential to use secure protocols at every possible layer to ensure maximum security. Stay safe and secure!