Red Hot Cyber
Cybersecurity is about sharing. Recognize the risk, combat it, share your experiences, and encourage others to do better than you.
RedWave Team : 12 November 2025 14:49
Many people believe that accessing only HTTPS sites is enough to ensure security when browsing on unsecured Wi-Fi networks. Spoiler alert: this belief is also a false sense of security.
HTTPS (HyperText Transfer Protocol Secure) uses encryption protocols such as TLS to protect communication between the browser and the website, ensuring data confidentiality and integrity.
While HTTPS does offer significant protection over HTTP.
In this article from our WiFi Column , we will show how this protection alone is not enough, especially in unsafe environments such as open Wi-Fi networks.
Despite the encryption provided by the HTTPS protocol, the open network and easy access to information by attackers exposes us to:
As written in several articles, hackers can exploit various techniques to bypass or compromise HTTPS protection, including:
Let’s start by saying that from our tests and analyses of alboratioro: one of the most insidious attacks of recent years, SSL Stripping , has proven to be much less effective.
Introduced in 2009 by Moxie Marlinspike , this attack was intended to transform a secure HTTPS connection into a plain HTTP one , stripping the user of the cryptographic protection without them realizing it.
In practice, the attacker inserted himself between the browser and the website – a classic man-in-the-middle attack – intercepting communications and modifying them on the fly, with the ability to read and manipulate everything that passed through.
To counter this type of attack, the HTTP Strict Transport Security (HSTS) mechanism was introduced in 2012. Using the Strict-Transport-Security header, a server can instruct the browser to access the site exclusively via HTTPS connections for a specified period of time. This prevents the browser from making insecure HTTP requests to the site, significantly reducing the attack surface for SSL stripping.
Imagine HSTS as an electronic gate: a digital barrier that opens only if you meet the right requirements—in this case, an HTTPS connection. If you attempt to pass through with an unencrypted HTTP connection, the barrier remains down. No access.
The website communicates a specific rule to the browser through a simple HTTP header:
“To enter here, you must only use HTTPS, always. Any other way is blocked.”
Once this command is received, the browser stores it and from then on refuses any unsecured connection to that site. Not even the user can force it: the gateway remains closed to anyone who doesn’t comply with the security requirements.
One limitation of HSTS is that its effectiveness depends on the user having previously visited the site via HTTPS. To mitigate this problem, major browsers maintain an internal list of “authorized” sites that must always be contacted via HTTPS on the first visit. It’s as if those sites had a pre-configured electronic badge : secure access is guaranteed right from the start.
However, this list cannot include all existing websites, leaving a window of vulnerability for sites not included.
That’s why, for sites that aren’t included in that list and don’t configure HSTS correctly, the barrier can remain up . And in that case, an attacker could still attempt a downgrade by forcing an HTTP connection with techniques like SSL stripping or DNS spoofing.
In addition to the above, incorrect configurations can expose websites to further risks. For example, if a website doesn’t implement HSTS correctly or isn’t included in the default browser list, an attacker could still attempt an SSL stripping attack. It’s therefore essential that websites properly configure HSTS and that users are aware of the risks associated with insecure connections.
HSTS is a powerful tool, but not a magic one . It works very well, but only if you meet the following criteria:
The adoption of HTTPS and HSTS has made SSL stripping attacks significantly less effective. However, complete security depends on proper server configuration and user awareness. It is essential that websites implement HSTS appropriately and that users pay attention to the security of their connections.
Complete security doesn’t exist ; awareness and understanding of these limitations allows us to be less exposed, especially on open networks like public or unprotected ones. Attackers have repeatedly shown us that they are very ingenious and always find a way to get what they want. In these two workshops, we want to highlight two possible scenarios we might encounter when connecting to an open network:
NB: All simulations are performed in a laboratory environment, without involving networks or real users.
Let’s start with a brief mention of ARP spoofing , which we will use in both labs and which is frequently used in unsecured networks.
ARP spoofing (or ARP poisoning) is a cyber attack technique that exploits vulnerabilities in the Address Resolution Protocol (ARP) to map the attacker’s MAC address to the IP address of another device on the same local network.
Simply put, the attacker sends spoofed ARP messages over the network, convincing other devices (e.g., a victim computer and the router) that the attacker’s MAC address matches the victim’s (or router’s) IP address.
In short, we can see in the victim’s device arp table, before the ARP attack, the correct MAC address associated with the gateway IP.
On Windows systems “arp -a” allows you to see the current arp table created from previous communications with hosts.
Once the arp spoofing attack was initiated, this mac associated with the gateway IP was replaced with that of the attacker.
From now on, all traffic that the victim tries to send to the gateway (192.168.0.1) to reach the Internet will all reach the attacker, who will then forward it to the original router and vice versa.
The victim is already under attack and is not aware of the problem.
ARP spoofing is one of the attacks used to perform MiTM.
Another technique could be to use DHCP spoofing, tricking clients into using different DHCP configurations than expected, including a different gateway that can be controlled by the attacker to sniff and redirect traffic.
In this lab, we analyze step-by-step a Man-in-the-Middle (MITM) attack conducted on an unprotected Wi-Fi network. The goal is to simulate a real-world scenario in which an attacker can intercept and manipulate the victim’s traffic, exploiting the user’s urgency and inattention. All operations are performed in a lab environment, for training purposes only.
In this lab, both victim and attacker are in the same unprotected network segment, where no network-side protection techniques have been implemented (we will discuss these mitigations in future articles).
Our victim is a user with a Windows 11 operating system updated to the latest available patches, who connects to an open Wi-Fi network. Using an unsecured network occurs for various reasons, as already discussed in the article ” Open Wi-Fi Networks: A Fertile Ground for Cybercrime .”
And it is precisely this need to stay connected at all costs that becomes a very powerful weapon for attackers.
The attacker operates from a Kali Linux machine , on the same network as the victim, and sets up the system to intercept and manipulate traffic.
The first step is to enable packet forwarding on Kali, turning it into a node that forwards traffic between the victim and the real gateway.
sudo sysctl -w net.ipv4.ip_forward=1
We use iptables to forward all outgoing traffic on ports 80 (HTTP) and 443 (HTTPS) to the local port 8080, where a proxy will be listening.
sudo iptables -t nat -A PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8080
sudo iptables -t nat -A PREROUTING -p tcp –dport 443 -j REDIRECT –to-port 8080
To intercept domain name requests and force them to the attacker’s IP, we configure DNS Hijacking with dnsmasq.
By editing or creating the configuration file:
sudo nano /etc/dnsmasq.conf
With the following content:
interface=wlan0
no-dhcp-interface=wlan0
bind-interfaces
bogus-priv
log queries
log-facility=/var/log/dnsmasq.log
address=/#/192.168.1.251
Finally, we start dnsmasq with:
sudo dnsmasq -C /etc/dnsmasq.conf
From now on, all DNS requests received by the wlan0 interface will always return the attacker’s IP address ( 192.168.1.251 ), simulating a captive portal or MITM proxy.
To intercept traffic, the attacker performs an ARP spoofing attack , making the victim believe that their MAC address is that of the gateway.
sudo arpspoof -i wlan0 -t 192.168.1.113 192.168.1.1
As seen above, this way, all traffic destined for the gateway will be diverted through the attacker’s machine, which acts as a transparent intermediary.
Now let’s enable mitmproxy , which will act as a transparent proxy to intercept and inspect HTTP and HTTPS traffic.
sudo mitmproxy –mode transparent –showhost –listen-port 8080
NB: For this lab we selected “mitmproxy” as it has a publicly downloadable certificate that does not need to be trusted, and therefore simplifies installation on the victim’s client (http://mitm.it/).
When the victim connects to the open, unprotected WiFi network, all their traffic will end up on the attacker’s Kali Linux machine. This, as we’ve seen in various articles, is already a problem in itself, but if the victim took no further action, at least the HTTPS traffic would be safe.
Once the victim opens the browser and attempts to browse, they are automatically redirected to a fake captive portal hosted by the attacker.
As shown in the figure with the accepted certificate and traffic passing through mitmproxy, the attacker will be able to:
In conclusion, this workshop represents a valuable opportunity to understand historical network interception techniques, exploring how they function in a controlled and secure environment. Analyzing these scenarios means not only understanding how attacks occurred, but above all understanding how to prevent them and strengthen the security of our digital infrastructures. Only through practical study and awareness can we build more resilient systems, capable of withstanding past and future threats.
Like HTTP, File Transfer Protocol ( FTP ) is now obsolete and insecure, but it continues to be used in many organizations for transferring files, including sensitive data.
Like HTTPS, the FTPS protocol allows for a secure, encrypted connection between the client and server; this extension of the FTP protocol adds TLS or SSL encryption (not to be confused with SFTP ), so that no one other than the server and client can access the data content.
FTP (File Transfer Protocol) is a standard network protocol used to transfer files between a client and a server over a TCP/IP network, such as the Internet. In practice, it allows you to upload and download files from a remote computer.
This is still widely used for data exchange,
It is therefore clear that this data travelling over the network or towards the Internet should also be protected by encryption.
In this type of attack we will force the victim to use a weak protocol, FTP downgrade.
This attack can be carried out when the victim uses an FTP client configured to automatically decide on the most secure protocol among those available.
In this example we used FILEZILLA, where the default configuration is for the program to automatically choose the secure connection if present.
In this case, when connecting normally, the client will automatically connect via TLS, because it will understand that the FTP server has configured the TLS protocol.
Instead, we see that using a MiTM (Man In The Middle) attack, in which an attacker positions himself in the middle of the communication, will allow the victim to be forced to use the clear FTP protocol, thus recovering the access credentials.
First, enable packet forwarding, which turns the attacker into an IPv4 router, so as we’ll see later, all incoming victim traffic will be forwarded to the real gateway and vice versa:
echo 1 > /proc/sys/net/ipv4/ip_forward
Let’s install a local FTP server on the victim’s device. In this example, we’ve also installed and started FTP and configured it to only accept cleartext connections (excluding TLS).
sudo systemctl start pure-ftpd
We perform some ARP spoofing (we will explain it better below) via the MITMf framework, this will make the victim change the MAC address associated with the router IP by replacing it with the victim’s.
MITMf (Man-In-The-Middle Framework) is a powerful all-in-one tool for performing Man-In-The-Middle attacks and manipulating network traffic. Its strength lies in overcoming the limitations of previous tools like Ettercap and Mallory, offering a modular and highly extensible architecture.
MITMf represents a significant evolution in the MITM tool landscape, offering a powerful, flexible, and up-to-date platform for network security analysis and attack scenario simulation.
We will use the -i parameter to indicate the interface connected to the public network, –spoof and –arp for this arp poisoning attack and finally –target and –gateway, as you can imagine, for the victim and gateway IPs.
sudo ./mitmf.py -i wlan0 –spoof –arp –target 192.168.0.42 –gateway 192.168.0.1
As explained above, thanks to ARP spoofing, all the traffic that the victim will try to send to the gateway to reach the Internet and external FTP, will all reach the attacker, who will then forward it to the original router and vice versa.
All this without the victim noticing anything.
Now, to intercept the transiting FTP traffic, we create a prerouting rule via iptables on the attacker’s device, so that all traffic sent by the victim to port 21 will be redirected to the attacker’s local FTP server.
sudo iptables -t nat -A PREROUTING -p tcp –destination-port 21 -j REDIRECT –to-port 21
Now if the victim connects to an FTP server from here on, authentication will be done on the attacker’s server without TLS.
In this case, this latest version of FILEZILLA would warn of a problem and a probable downgrade attack, other software might not even have this check and proceed without warning.
This is because we previously connected via TLS, but if it were the first time it would not have reported the problem.
If the victim accepts this message without asking too many questions and proceeds with authentication, MITMF will capture the exchanged credentials in clear text, including the FTP server’s IP address.
We will also see the message that we are using an unsecured connection in the FileZilla logs.
A consequence, in addition to credential theft, is that if the attacker had configured a local FTP server that could accept any credentials passed by the victim, they could also steal any data the victim might try to send to the attacker.
Obviously, in this case, pre-routing of port 20 and some passive ports is also missing.
NB: FileZilla reports the downgrade only if an FTPS connection has previously occurred, but does not always block the attempt if the configuration is set to “automatic connection”.
In this lab, we demonstrated how, even with secure protocols like FTPS, security can be compromised if proper and informed configurations are not adopted. Through a Man-in-the-Middle (MITM) attack and ARP spoofing techniques, it was possible to force an FTP client, configured to automatically select the most secure protocol available, to fall back to an unencrypted connection (FTP), thus exposing the credentials and transmitted data.
This scenario could also occur with the POP, IMAP, SMTP protocols if the mail client automatically configured the protocol.
It is therefore important to pay attention to client configurations to use only secure connections.
To reduce the risks associated with using public or untrusted networks, there are several mitigation techniques that can be applied at the infrastructure level. Among the most effective are:
In the next articles, we will delve into each of these solutions, analyzing real-world scenarios, recommended configurations, and their impact on overall network security.
As the RedWave Team, we want to raise awareness that blindly relying on encrypted protocols or default configurations can create a dangerous sense of security. We’ve seen how secure connections can be compromised if tools aren’t configured properly or if the user isn’t fully aware of the risks.
Secure communications is not just about using HTTPS or FTPS, but about adopting a proactive approach that includes secure configurations, ongoing training, and good operational practices.
In the next article, we’ll explore using a VPN as an additional layer of protection on untrusted networks, and in subsequent articles, we’ll analyze concrete mitigation strategies to reduce risk exposure even on problematic networks like open Wi-Fi.
RedWave Team
