Security Protocols

• HTTPS

  • Hypertext Transfer Protocol Secure (HTTPS) is a client-server protocol; responsible for securely sending data between a web server (website) and a web browser (client side). It is an encrypted variant of HTTP which sends data in an unencrypted format.
• HTTPS

  • HTTP would be enough to browse a website to learn about a company product; however, HTTPS is a must if you want to provide your credit card details to place an online order. HTTPS was developed to securely share sensitive information, including passwords, contact information and financial information, between web browsers and websites. Without HTTPS, secure online banking and online payment wouldn’t have been possible.
• Workflow - HTTPS

  • HTTPS uses its unencrypted counterpart, i.e., HTTP, and adds a layer of encryption. In this case, it is SSL/TLS (Secure Sockets Layer/Transport Layer Security); the rest of the workflow remains the same.
• Request and Response - HTTP

  • An HTTP request is made by a user agent (a browser or any other application sending requests through a web API (Application Programming Interface)). It is vice versa in the case of response. This request aims to access some resources on the remote web server, which is then responded to by the web server. The figure below shows a web browser sending an HTTP request to a web server, listening at TCP port 80.

  
• The request might be GET to request a web page, an image, or a file. Other HTTP requests include PUT and POST, which send data to the web server, such as a value or a file.

  • If an attacker can capture the network packets between the client and the server communicating over HTTP, they will be able to read their content as it is sent in cleartext.

  
• Request and Response - HTTPS

  • After our quick review of the HTTP request and response workflow, it is convenient to learn about HTTPS. Remember that the “S” in HTTPS is for the extra SSL/TLS layer of encryption added over HTTP.
  • Even if an attacker can capture the network packets between the client and the server communicating over HTTPS, they will fail to read the contents of the TCP data due to encryption.

  
• Encryption Mechanism of HTTPS

  • As already mentioned, SSL/TLS provides the encryption layer of HTTPS. It relies on asymmetric encryption (public key cryptography) and symmetric encryption. Asymmetric encryption uses two keys, i.e., public key and private key; its rule is to negotiate the symmetric encryption algorithm and the secret key. The default port of HTTPS is 443. Encryption protects against interception and alteration of data, maintaining the confidentiality and integrity of exchanged traffic.
• FTPS

  • File Transfer Protocol Secure (FTPS) is a communication protocol which is a refined and secure version of File Transfer Protocol (FTP). Initially, FTP was developed in 1971 and published as RFC 114. Additional improvements and various changes were published in RFC 765 and RFC 959.
• FTPS

  • FTP was designed as a client-server model; separate control/command and data connections between a client and a server are used, along with a username and password. In FTP, both authentication and data transfer take place in an unencrypted form between the client and the server; however, in FTPS, an encrypted channel is established.
• Workflow

  • FTPS is an extension of FTP, which adds TLS security to commands and data connections. It is necessary to get an overview of FTP to understand FTPS.
• Request and Response - FTP

  • As described earlier, FTP is based on the client-server model. It utilizes the following two communication channels between the client and the server.
  • Control Connection: In this connection, an FTP client (such as Filezilla and CuteFTP) sends a connection request (authentication) to the remote FTP server at the default FTP port, TCP port 21. As the name implies, a control connection is used for sending and receiving commands and responses.
  • Data Connection: After authentication, this connection is used for transferring data (files and folders).
• FTP Connection Types

  FTP has two modes:

  1. Active modes
  2. Passive mode
• FTP Active Mode

  • In active connection mode, the client establishes the control connection to send commands/authentication parameters to the server. After authentication and upon the client’s request to initiate data transfer, the server establishes the data connection to the client to transfer the data. In brief:

  1. The FTP client connects to the FTP server at TCP port 21 to establish a command connection.
  2. The FTP server connects to the FTP client at TCP port 20 to establish a data connection.
• FTP Active Mode:

  
• FTP Passive Mode

  • In passive connection mode, the client establishes the control and data connections. The client sends the PASV command to the server over the command channel; the server sends a random port to the client. As soon as the client receives the port number, the client establishes a connection to the provided port number so that the server can initiate the data transfer to the client.
  • This type of connection works well when the client is behind the firewall.

  
• FTP Data Types

  When data exchange between client and server takes place, the following type of data types are used:

  • ASCII/Type A: This is the default type and is used for text file transfers. If necessary, data is converted into 8-bit ASCII before transmission and then converted back upon reception.
  • Image/Type I: This is commonly referred to as the binary mode. It uses byte-by-byte transmission. The recipient stores the received bytes upon reception.
  • EBCDIC/Type E: It is suitable for text communication using the EBCDIC character set.
• Request and Response - FTPS

  As the name implies, FTPS is an extension of FTP. It adds an encryption layer to transmit command and data channels between client and server securely. The following two methods are used to invoke security:

  • Implicit Connection: In this connection, FTPS client and server establish a link in which both command and data channels are secured automatically with SSL encryption.
• Request and Response - FTPS

  • Explicit Connection: The FTP client explicitly requests the server to invoke an SSL/TLS secured session on port 21 and then continue data transfer based on a mutually agreed authentication mechanism. With explicit connection, you can choose which channel to encrypt by choosing among three modes of communication for control and data channel, i.e., control only encrypted, data only encrypted and both control and data encrypted.
• • The standard port for FTP and Explicit FTPS is 21, whereas it is 990 in the case of Implicit FTPS. Adding FTPS protects against sniffing attacks against login information and data.
• SMTPS

  • Simple Mail Transfer Protocol Secure (SMTPS) is an extension of SMTP, which is used for email communication. We should not confuse SMTP with POP3. Although both are used for email communication, SMTP is an “Email Push Protocol” used to transfer email messages from the client to the server. In contrast, POP3 is used to download email messages from the server to the client. SMTPS is an extension of SMTP; it uses TLS/SSL to provide authentication, integrity, and confidentiality for transferred data. First, let’s review the SMTP protocol.
• SMTP Protocol

  SMTP is implemented in the following two models:

  • SMTP End-to-End: This model is used for email communication between organizations. In this model, the sender-side SMTP client initiates an SMTP connection to the recipient’s SMTP server.
  • SMTP Store-and-Forward: This model is used for email communication within an organization. In this model, the SMTP server will maintain the copy of the mail within itself (i.e., store) until the copy is forwarded to the receiver.
• SMTP Components

  To understand the workflow of SMTP, we will study the following essential components of SMTP:

  • User Agent (UA): UA is responsible for creating the email message and sending it to the Mail Transfer Agent (MTA). 
  • Mail Transfer Agent (MTA): MTA will transfer the email from the UA to the recipient MTA across the Internet (often, the MTA and Mail Delivery Agent are hosted on the same server).

  
• TLS Process in SMTPS

  • SMTPS is not a proprietary protocol; instead, it wraps SMTP inside TLS. You can say that SMTPS is similar to SMTP on the application layer, with an extension of TLS encryption at the transport layer. For encryption, the STARTTLS command is used between the email client and the email server.
• TLS Process in SMTPS

  • Port 587 and 465 are both frequently used for SMTPS traffic. Mails transmitted using SMTP are not encrypted, so they are prone to sniffing attacks. Therefore, SMTPS is used to encrypt emails through TLS before transmission. In addition, SMTPS also forbid attackers from sending spam messages from compromised/vulnerable domains, exfiltration sensitive information, and conducting phishing attacks.
• POP3S

  • Post Office Protocol Secure (POP3S) is an extension of the POP3 protocol; it is used for the encrypted retrieval of email messages from the email server to the email client. So first, let’s review the POP3 protocol.

  POP3 Protocol

  • In the previous section, we explored how SMTPS is used for secure email transmission. SMTP is not responsible for retrieving email messages; here, POP3 comes into play. POP3 is the latest POP version; it retrieves email messages from a Mail Delivery Agent (MDA) to a Mail User Agent (MUA).
• POP3 Components and Workflow

  • Like SMTP, POP3 has two components: client (MUA) and server (MDA). The steps are the following:

  1. The email client establishes a connection to the email server.
  2. The email client downloads all the queued emails from the email server. (This is a default option; however, the client can select only particular email messages to download.)
  3. All emails are saved on the device that initiated the connection.
  4. The email server deletes the email copy. (This is a default option; a client can choose not to download an email after it is retrieved.)
• Limitations of POP3

  • Emails are Processed Locally: No synchronization of email messages across multiple devices. Protocol downloads the emails on the currently logged-in device and usually deletes them from the server.
  • Transmission in clear text: The username and password, along with the email messages, are sent in cleartext, which makes them vulnerable to sniffing attacks.
• POP3S

  • As we conclude, POP3 is considered weak from a security point of view. This requires an added layer of security; hence, POP3S comes into play. POP3S is an extension of POP3, which wraps the communications related to email messages within TLS. For this purpose, the client and server initiate the STARTTLS command, as shown in the figure below. After the EHLO, the POP3S server will trigger the switch to TLS. Note that EHLO stands for Extended HELO, where HELO is the command used to identify to the server.

  
• The POP3S Protocol uses port 995, while POP3 uses port 110. In the next task, we will learn a few other secure protocols at the Application layer.
• DNSSEC

  • As you would already know, DNS stands for Domain Name System. The DNS protocol is responsible mainly for resolving domain names. Instead of remembering the IP address, you need to focus on the domain name. For instance, at the time of this writing, example.com resolves to 93.184.216.34; it is clear which one is easier for the human mind to remember.
• DNSSEC

  • DNS works by sending a DNS query. For instance, when browsing the web, your web browser might send a query for DNS record type A or AAAA, i.e., IPv4 or IPv6 addresses. In the following console output, we can see the host with IP address 192.168.0.102 sending two DNS queries to the DNS server 1.0.0.1 regarding the domain name example.com. We can see the responses for the A and AAAA queries.

  
• DNSSEC:

  • This name-to-IP address resolution is very convenient; however, anyone on the network could have responded with a forged response. Furthermore, the host that sent the query would have accepted “any” response. In other words, the host would connect to a rogue server. One way to avoid such a situation would be by using DNSSEC.
• DNSSEC makes it possible to ensure that the DNS response we receive is from the domain owner. To achieve this, DNSSEC requires two main things:

  1. The DNS zone owner should sign all DNS records using their private key.
  2. The DNS zone publishes its public key so users can check the validity of the DNS records signatures.

  In other words, the data to our DNS query is signed to ensure its integrity and authenticity; moreover, we can efficiently check the signature.
• With signed records, DNSSEC provides the following:

  • Authenticity: You can confirm that a certain DNS owner has authored and sent the record. Authenticity is possible because the received record is signed by the DNS owner’s private key.
  • Integrity: You can ensure that no changes have been made to the record on its way. Any changes to the record will render its signature invalid.
• OpenPGP

  • When the first email was sent in 1971, we had a different cyber security landscape. Email protocols such as SMTP and POP3 are designed to send emails in cleartext. The same applies to IMAP, which allows synchronizing your mailbox with that on the server. All these protocols make your email no different than an exposed postcard open for everyone to see as it is handed from one server to another.
• OpenPGP

  • The image below shows a simplified example where a user uses an email client to send their email over SMTP and receive new email messages over POP3 or IMAP. The mail server uses SMTP to deliver the user’s email messages to the intended recipient. Since all these protocols use clear text, an intruder can read the email messages as they travel across the Internet.

  
• With the increased popularity of web-based email, users started to connect to a web server to read and compose their email messages. The image below shows an email message as it is written using a web browser. The web server, in turn, uses a mail server to send composed email messages and receive incoming ones. The connection was over HTTP, which meant that the same security issues related to confidentiality and integrity persisted.

  
• However, as service providers realized the need for SSL/TLS to secure web traffic, HTTPS became the new standard. Consequently, most web-based email systems migrated to HTTPS, causing the traffic between the web browser and the web server to be encrypted. However, the email traffic is not necessarily encrypted between the web server and the mail server(s). The web server and mail servers can read the contents of the messages; moreover, mail servers might use SMTP to transfer the messages, which means that email messages will traverse the Internet in cleartext.

  
• Eventually, SSL/TLS started to find their way into all email protocols. SMTP, POP3, and IMAP became SMTPS, POP3S, and IMAPS, respectively. The “S” added to the protocol name refers to secure, indicating the addition of SSL/TLS on top of the existing protocol.

  The image below shows a simplified example where a mail client uses SMTPS to send an email and uses POP3S or IMAPS to receive an email. The result is that email is sent encrypted between the client and the server; however, the mail server can read the email message contents.

  
• OpenPGP:

  • The addition of SSL/TLS has dramatically enhanced the security of email messages. However, we must still trust the mail servers across the way. If this is not something you are comfortable with, you need to consider a standard such as OpenPGP. PGP (Pretty Good Privacy) is an encryption program created by Phil Zimmerman. OpenPGP is an open standard for signing and encrypting files and email messages and is detailed in RFC 4880. GnuPG (Gnu Privacy Guard), or simply GPG, is a free and open-source implementation of the OpenPGP standard.