Securing Python Client-Server Communication with Fernet Encryption & Wireshark

---

Introduction

In this post, I’ll walk you through a hands-on cybersecurity project that demonstrates the dangers of unencrypted network communication and how to secure it using symmetric encryption with Fernet (AES). We’ll then use Wireshark to observe the traffic in plaintext and encrypted forms.

---

Project Goals

• Understand network vulnerabilities through packet sniffing.

• Secure client-server communication using Fernet encryption.

• Compare plaintext vs encrypted traffic in Wireshark.

---

Tools You’ll Need

• Python 3

• cryptography Python package

• Wireshark (packet analyzer)

• Two terminals or networked machines (or just one for localhost testing)

---

Topology Overview

---

Step 1 – Plaintext Client-Server Setup

Let’s simulate a real-world scenario: a client sends a message to a server to mark attendance.

Server Code (Plaintext):

Client Code (Plaintext):

Step 2 – Analyze with Wireshark (Unsecured)

1. Start Wireshark and filter: tcp.port == 9090

2. Run the server, then the client.

3. Follow the TCP stream.

WireShark TCP Capture:

Mesage Capture (Plaintext):

Why Plaintext Transmission Is a Security Risk

When we run the plaintext version of our client-server communication, Wireshark successfully captures and displays the message in clear text.

This happens because:

• The message is transmitted without any form of encryption.

• Network traffic, even on localhost or internal networks, is still susceptible to packet sniffing.

• Tools like Wireshark operate in promiscuous mode, meaning they can intercept and display all traffic passing through the network interface.

---

Why This Is Dangerous

• Lack of Confidentiality: Anyone with access to the network or host (even via a misconfigured switch or infected host) can see sensitive information like badge numbers, user credentials, session tokens, or internal system commands.

• No Data Integrity: Since the traffic is readable, it's also susceptible to modification in a man-in-the-middle (MITM) attack. An attacker can change data in transit without either the client or server knowing.

• No Authentication: Plain TCP communication doesn't verify the sender or receiver, making spoofing attacks easier.

• Compliance Risks: Many standards (GDPR, HIPAA, PCI-DSS) require data encryption in transit. Transmitting identifiable or sensitive information in clear text violates these regulations.

---

Real-World Implication

If this system were deployed in a real company, even just on an internal network, anyone running Wireshark on that network could collect employee messages, badge numbers, etc, impersonate them, or even script malicious automated badge check-ins.

In more complex systems, this could be equivalent to intercepting login credentials, API keys, or even session cookies, which could grant unauthorized access to internal systems.

---

What This Teaches Us

This exercise underscores why "security through obscurity" is not security. Just because a system operates on a private network or doesn't expose a public API doesn't mean it's safe from internal threats or compromised endpoints.

Proper encryption in transit (like we’ll implement using Fernet) ensures:

• Even if intercepted, the data is useless without the key.

• Attackers can't understand or tamper with the content.

• You move closer to compliance with cybersecurity best practices.

Step 3 – Secure the Communication (Fernet Encryption)

We’ll now encrypt the badge number using Fernet, a symmetric encryption implementation using AES 128 in CBC mode + HMAC.

Generate Symmetric Key:

Run once and share the secret_key.key with both client and server.

Server (Encrypted):

Client (decrypted):

Step 4 – Analyze with Wireshark (Encrypted)

Repeat the Wireshark capture:

1. Run encrypted client/server scripts.

2. Use tcp.port == 9090 filter.

3. Follow the TCP stream.

This time, the message is unreadable.

Wireshark TCP Capture:

Wireshark Message Capture(encrypted):

Observing the Encrypted Traffic: Message Becomes Unreadable

After implementing Fernet encryption and running the client-server communication again, we observe a major difference when analyzing the traffic in Wireshark: the message is now unreadable.

Instead of seeing a clear badge number or identifiable string in the packet payload, we now see a seemingly random blob of characters this is encrypted ciphertext.

---

Why This Happens

This change occurs because:

• The badge number is now encrypted using Fernet, which internally uses AES (Advanced Encryption Standard) in CBC (Cipher Block Chaining) mode, combined with HMAC (Hash-Based Message Authentication Code) for integrity.

• Encryption transforms plaintext data into ciphertext, which appears as random binary or Base64-like characters over the network.

• Wireshark can still capture the packets, but without the symmetric encryption key, it cannot decrypt or interpret the payload.

Even if an attacker captures the traffic, they cannot decipher the original message unless they also have access to the encryption key (which in secure systems should never be transmitted over the network unprotected).

---

Why This Is Good for Security

• Confidentiality is Preserved: Sensitive data like badge numbers, login info, or personal details are not exposed, even if intercepted.

• Attack Surface is Minimized: The encrypted message is meaningless without the key. This prevents attackers from replaying, injecting, or modifying valid messages.

• Integrity and Tamper Resistance: Fernet encryption includes built-in HMAC validation, meaning any tampering with the message results in decryption failure.

• Mitigates Insider Threats: Even users with access to the network cannot interpret the encrypted payload without proper access control to the key.

---

Real-World Security Reflection

In a real deployment, encryption ensures that internal or external actors cannot eavesdrop on communication between services, devices, or users. This is especially critical in:

• Enterprise networks

• Financial transactions

• Healthcare data exchange

• Industrial control systems (ICS)

• IoT device communication

Even if the environment is "trusted" or private, zero-trust principles demand that data be protected in transit.

---

Summary

This unreadable message in the network trace isn’t a flaw, it’s proof that encryption is working.

Encryption doesn’t hide the fact that communication is occurring (metadata is still visible), but it renders the content unintelligible, which is the foundation of secure data transmission.

This reinforces the principle:

If someone can intercept your traffic and read it, you have no security. If they can intercept it but cannot read or alter it, you are encrypted and safe.

Conclusion

This project clearly illustrates a fundamental truth in cybersecurity: encryption is not optional, it's essential. In today's connected environments, every piece of data traveling across a network is a potential target. Whether you're building enterprise software, internal tools, or IoT applications, securing data in transit must be part of your design from the very beginning.

What we demonstrated may seem simple: sending a message from a client to a server. But the principle behind securing it applies to everything from login credentials to financial transactions and health records.

---

Key Takeaways

• Always Encrypt Sensitive Data
  Even basic user input like badge numbers can be exploited if transmitted in plaintext. Information doesn't have to be classified to be valuable to attackers. Encryption ensures confidentiality, data integrity, and trust.

• Symmetric Encryption is Practical and Effective
  In controlled environments where the client and server are part of the same system or trusted domain, symmetric encryption like Fernet (AES) offers a fast and reliable way to secure communication. It's easy to implement and highly performant, making it ideal for internal services, APIs, and embedded systems.

• Wireshark is an Eye-Opener
  Tools like Wireshark allow you to see what's happening on your network. They are essential for:

  • Verifying that encryption is working as intended

  • Detecting plaintext data leaks

  • Investigating incidents and analyzing threat vectors

  • Teaching and learning how protocols and data transmission behave in practice

---

Final Reflection

Security is not something you add at the end of development it’s something that must be woven into the architecture from day one. If you’re sending any data over a network, internal or external, assume it can be intercepted. That mindset will push you toward adopting secure practices like encryption by default.

This project wasn’t just about writing Python scripts. It was about building a security-first mindset:

• thinking like an attacker,

• validating with the right tools, and

• implementing countermeasures that work in the real world.