Networking Secure Protocols: HTTPS, SSH, Email Security, and VPNs

Introduction

Welcome to my walkthrough of the room Networking Secure Protocols!

In my previous article, Networking Core Protocols, we explored how fundamental Application Layer protocols like HTTP, FTP, SMTP, POP3, and IMAP function under the hood. While these traditional protocols successfully transmit data across networks, they were inherently designed without built-in security, leaving plaintext communications vulnerable to eavesdropping, interception, and tampering.

In this room, we examine the cryptographic protocols and secure mechanisms designed to protect data in transit, including Transport Layer Security (TLS), Secure Shell (SSH), Secure FTP variants, and Virtual Private Networks (VPNs).

If you missed the previous entry in this series, you can catch up on my walkthrough for Networking Core Protocols below.

What we will cover

• Key cryptographic concepts and TLS evolution
• Securing legacy plaintext protocols (HTTPS, SMTPS, POP3S, IMAPS)
• Remote management and secure tunneling via SSH and SFTP
• Network-level protection and routing using VPNs
• Answers to all room questions and practical exercises

Room Information

Before we dive into the tasks, here is a quick overview of the room details.

• Room Name: Networking Secure Protocols
• Path: Cyber Security
• Module: Networking
• Topic: Encrypted Application & Transport Layer Protocols
• Difficulty: Easy
• Room Link: TryHackMe — Networking Secure Protocols

Task 1: Introduction

In the Networking Core Protocols room, we learned about the protocols used to browse the web and access email, among others. These protocols work great; however, they cannot protect the confidentiality, integrity, or authenticity of the data transferred. In simpler terms, when we say that confidentiality is not protected, it means that someone watching the packets can read your password or credit card information when sent over HTTP. Similarly, they can access your private documents when sent via email. As for not protecting the integrity of the data, it means that an adversary can change the contents of the transferred data; in other words, if you authorise the payment of one hundred pounds, they can easily change it to another value, such as eight hundred pounds. Authenticity means ensuring we are talking with the correct server, not a fake one. Important online transactions are risky without ensuring confidentiality, integrity, and authenticity.

Transport Layer Security (TLS) is added to existing protocols to protect communication confidentiality, integrity, and authenticity. Consequently, HTTP, POP3, SMTP, and IMAP become HTTPS, POP3S, SMTPS, and IMAPS, where the appended "S" stands for Secure. We will examine these protocols and the benefits we reaped from TLS. Similarly, it is deemed insecure to remotely access a system using the TELNET protocol, leading to the creation of Secure Shell (SSH) to provide a secure way to access remote systems while offering added security features for other protocols.

Task 2: TLS

Historically, legacy network adapters operating in promiscuous mode could intercept cleartext credentials across shared physical networks. To combat widespread sniffing, Netscape Communications introduced Secure Sockets Layer (SSL 2.0) in 1995. The Internet Engineering Task Force (IETF) subsequently standardized and upgraded SSL into Transport Layer Security (TLS 1.0) in 1999, culminating in the modern TLS 1.3 standard released in 2018.

Operating at the Transport Layer of the OSI model, TLS provides cryptographic encapsulation that protects application data against eavesdropping and modification over untrusted networks.

Certificates and Trust Infrastructure

To establish authenticity, servers present a digital TLS Certificate during connection negotiation:

1. A server administrator creates a Certificate Signing Request (CSR) and submits it to a trusted Certificate Authority (CA).
2. The CA validates host ownership and issues a signed digital certificate.
3. Client machines verify server certificates against a pre-installed store of trusted Root CA certificates.

Organizations can obtain free, automated public certificates via providers like Let's Encrypt. Conversely, self-signed certificates generated locally lack third-party endorsement and cannot prove server authenticity, triggering browser warnings when encountered.

Questions and Answers

What is the protocol name that TLS upgraded and built upon?

Answer:

SSL

SSL

Which type of certificates should not be used to confirm the authenticity of a server?

Answer:

self-signed certificate

self-signed certificate

Task 3: HTTPS

Standard HTTP Protocol Mechanics

As explored in the Networking Core Protocols room, standard HTTP relies on TCP and listens on port 80 by default. Plaintext HTTP traffic can be easily intercepted, monitored, and read by an adversary positioning themselves on the network path.

Before a web browser can request a web page over standard HTTP, it resolves the target domain name to an IP address and establishes a TCP three-way handshake with the destination server. Once established, the client sends unencrypted HTTP protocol commands, such as GET / HTTP/1.1, across the stream before terminating the connection.

Encrypting HTTP Over TLS

HTTPS stands for Hypertext Transfer Protocol Secure, which effectively wraps standard HTTP inside an encrypted TLS session on TCP port 443. Connecting to an HTTPS endpoint requires establishing a TCP three-way handshake, negotiating a secure TLS session, and then exchanging encrypted HTTP application data.

Inspecting the encrypted HTTPS packet capture shows three distinct phases. Packets 1 through 3 complete the initial TCP handshake, followed by 5 packets dedicated to establishing and negotiating the TLS session. Once negotiation completes, packets 9 through 20 exchange encrypted HTTP data, which Wireshark labels generally as Application Data because payload encryption masks the underlying application protocol structure. Following stream content without decryption keys yields indecipherable ciphertext.

Decrypting HTTPS Session Traffic

Accessing session decryption keys allows protocol analyzers like Wireshark to decrypt the TLS record layer and inspect the underlying HTTP request structures.

Once the decryption key is applied, section 3 transforms from generic Application Data into readable HTTP/2 protocol frames. Inspecting the capture reveals that packet 10 contains the decrypted request headers, explicitly showing the client issuing GET /login to the web server.

Adding TLS secures HTTP communications entirely without modifying lower-layer protocols like TCP and IP or higher-layer HTTP syntax.

Questions and Answers

How many packets did the TLS negotiation and establishment take in the Wireshark HTTPS screenshots above?

Answer:

8

8

What is the number of the packet that contain the GET /login when accessing the website over HTTPS?

Answer:

10

10

Task 4: SMTPS, POP3S, and IMAPS

Adding TLS to SMTP, POP3, and IMAP follows the exact same process as securing HTTP. Just as HTTP appends an "S" for Secure to become HTTPS, SMTP, POP3, and IMAP become SMTPS, POP3S, and IMAPS, respectively. Using these mail protocols over TLS operates identically to using HTTP over TLS, meaning that all principles of encryption, confidentiality, and integrity discussed in HTTPS apply here as well.

The insecure versions of these protocols rely on default TCP ports: HTTP uses port 80, SMTP operates on port 25, POP3 listens on port 110, and IMAP uses port 143. Transitioning to secure versions over TLS assigns distinct default TCP port numbers: HTTPS runs on port 443, SMTPS uses ports 465 and 587, POP3S operates on port 995, and IMAPS listens on port 993.

TLS can be applied to many other application protocols, providing identical cryptographic advantages across diverse services.

Questions and Answers

If you capture network traffic, in which of the following protocols can you extract login credentials: SMTPS, POP3S, or IMAP?

Answer:

IMAP

IMAP

Task 5: SSH

The Secure Shell (SSH) protocol was developed to replace insecure, cleartext administration protocols like TELNET. While TELNET transmits credentials and commands in plain text on TCP port 23, SSH operates on TCP port 22 and provides end-to-end encryption to protect confidentiality and data integrity across remote administration sessions. Most modern SSH clients rely on OpenSSH, an open-source implementation released by OpenBSD developers.

Beyond interactive command-line management initiated via ssh username@hostname, OpenSSH supports key-based and two-factor authentication, traffic tunneling for other network protocols, and X11 forwarding using the -X flag to run remote graphical applications.

Questions and Answers

What is the name of the open-source implementation of the SSH protocol?

Answer:

OpenSSH

OpenSSH

Task 6: SFTP and FTPS

Transferring files securely relies on two primary protocol implementations: SFTP and FTPS. The SSH File Transfer Protocol (SFTP) belongs to the SSH protocol suite and operates natively over TCP port 22, leveraging existing SSH keys and security configurations. Connecting via sftp username@hostname grants access to interactive file commands such as get for downloading and put for uploading.

Conversely, File Transfer Protocol Secure (FTPS) layers TLS encryption over standard FTP. While traditional FTP uses port 21, FTPS typically operates over TCP port 990, requiring explicit certificate setups and dedicated firewall considerations for its separate control and data channels.

To complete the interactive site challenge, launch the practical site and match each legacy cleartext protocol port with its corresponding encrypted counterpart. Connecting port 143 to 993 (IMAPS), 110 to 995 (POP3S), 21 to 990 (FTPS), 80 to 443 (HTTPS), 25 to 587 (SMTPS), and 23 to 22 (SSH) validates all matches correctly.

Successfully linking all six port pairs reveals the completion pop-up containing the flag required to complete the task.

Questions and Answers

Click on the View Site button to access the related site. Please follow the instructions on the site to obtain the flag.

Answer:

THM{Protocols_secur3d}

THM{Protocols_secur3d}

Task 7: VPN

A Virtual Private Network (VPN) extends a private network across a public network like the Internet by creating an encrypted tunnel between endpoints. This setup allows connected devices to send and receive data securely as if they were directly plugged into the local corporate infrastructure.

Organizations typically deploy site-to-site VPNs using specialized gateway routers to connect distinct branch offices, ensuring seamless and encrypted communication across geographic locations. Alternatively, remote workers use client-based remote access VPNs to securely reach internal corporate resources from home or on the road. Beyond enterprise connectivity, individual users leverage consumer VPN services to hide their public IP addresses, routing outbound traffic through remote servers to bypass local content filtering or regional access restrictions.

Questions and Answers

What would you use to connect the various company sites so that users at a remote office can access resources located within the main branch?

Answer:

VPN

VPN

Task 8: Closing Notes

Network traffic protection relies on three fundamental paradigms. First, TLS encapsulation upgrades plaintext application standards into secure variants like HTTPS, SMTPS, POP3S, and IMAPS. Second, SSH replaces insecure remote administration services like TELNET on TCP port 22 while supplying integrated file transfer via SFTP. Third, VPNs secure entire network interfaces across public transit paths.

Practical Walkthrough: Decrypting TLS Packet Captures

To analyze encrypted capture files like randy-chromium.pcapng in Wireshark, we can import the corresponding TLS session key log file to decrypt the record layer.

First, open the capture file in Wireshark, right-click any TLS frame (such as frame 10), navigate to Protocol Preferences, and select Transport Layer Security.

Next, browse to the (Pre)-Master-Secret log filename field, select /home/ubuntu/Documents/ssl-key.log, and click OK to apply the decryption key across the packet capture.

Once Wireshark decrypts the payload, apply the filter http2.headers.path contains "login" to isolate authentication attempts. This reveals packet 365, which issues a POST /login request operating on HTTP/2 stream ID 15.

Filtering specifically by http2.streamid == 15 isolates the full conversation stream. Selecting packet 366 immediately following the POST header reveals the decrypted application/x-www-form-urlencoded body payload, exposing the submitted password THM{B8WM6P} inside the form data field.

Questions and Answers

One of the packets contains login credentials. What password did the user submit?

Answer:

THM{B8WM6P}

THM{B8WM6P}

Summary & Key Takeaways

You have successfully completed the Networking Secure Protocols room and finalized the four-part networking fundamental series!

Key lessons:

• TLS Encryption: Protects application data against sniffing and tampering by layering symmetric encryption and public-key infrastructure over TCP connections.
• Certificate Verification: CAs validate server identities via signed certificates; self-signed variants fail strict authentication checks.
• Secure Port Mapping: Secure protocols use designated listening ports (HTTPS: 443, SMTPS: 465/587, POP3S: 995, IMAPS: 993, SSH/SFTP: 22, FTPS: 990).
• SSH Protocol Suite: Replaces plaintext TELNET with encrypted administration, key-based login, X11 forwarding, and SFTP file transfer capabilities.
• VPN Tunnels: Encapsulate layer 3 IP traffic across public transit networks to secure remote workforce access and interconnect site infrastructure.