Fake Wi-Fi in the Sky: What an Evil Twin Can See and What HTTPS Still Protects

In April 2024, airline staff in Australia noticed a suspicious Wi-Fi network on a domestic flight. They reported it. When the flight landed in Perth, Australian Federal Police searched a passenger's bags and seized a portable wireless access device, a laptop and a phone. BleepingComputer reported on the charges in July 2024: the man was accused of running fake access points on flights and at the Perth, Melbourne and Adelaide airports, with the networks leading to fake login pages that asked for email or social media credentials. Bitdefender covered the same case. The allegations were not proven at the time of those reports.

The trick has a name: the evil twin. This post explains why it works, what the person running one can and cannot read, and three checks that take less time than boarding.

TL;DR

• An evil twin is an access point that copies a real network's name. Your device cannot tell them apart by name alone.
• HTTPS still protects page content on a fake network. What leaks is the site list, plain HTTP, and anything you type into a fake login page.
• A VPN hides your traffic from the access point, but it cannot save a password you type into the attacker's portal.

Why the copy works

A Wi-Fi network is announced by a name (SSID). Your phone remembers names it has joined before and reconnects automatically. On an open network, such as airport or in-flight Wi-Fi, there is no password the access point must prove it knows, so a second access point with the same name and a stronger signal looks identical to the original.

Then comes the captive portal. Most public networks redirect you to a page where you accept terms or sign in. That page is also the attacker's best tool: it is a normal thing to see, and it asks for credentials. In the Australian case, that is how the alleged login-page theft was supposed to work.

What the person running the fake network sees

Assume you joined it. The operator is now your network. They get:

• Every plain HTTP request in full: URL, headers, cookies, form fields.
• Your DNS queries, so a list of the hostnames you look up.
• The hostname of every HTTPS site, because it travels in the clear in the TLS handshake (a 15-line Python script can show you this on your own machine: build a TLS ClientHello offline and look for the hostname in the raw bytes).
• Destination IPs and traffic volume.
• Whatever you type into a page they serve you.

What they do not get: the content of pages loaded over HTTPS with a valid certificate. They cannot read your bank's page or your mail over a TLS connection unless your device accepts a forged certificate, and modern browsers show a loud warning when that happens.

HSTS closes the downgrade trick

A common attack on an open network is to strip HTTPS: you type bank.com, the attacker answers on plain HTTP and proxies the rest. HSTS, defined in RFC 6797, is the countermeasure. A site sends a header telling the browser to use HTTPS only for a set time. After that visit, the browser refuses plain HTTP for that site, even if you type http://. First visits and sites without HSTS remain exposed, which is why "just look for the padlock" is only half the advice.

Three checks for a network you do not control

1. Is the portal the real portal?

Before you type anything into a login page, look at the address bar. A portal you reached by redirect should still use HTTPS with a certificate that matches the airline's or airport's domain. If the page asks for your email password or a social login to get online, close it. A genuine Wi-Fi portal needs, at most, an email address, a booking reference or a payment on the operator's own domain.

2. Is plain HTTP being tampered with?

neverssl.com is a site that stays on HTTP on purpose, so captive portals can intercept it. Fetch it and look at the answer:

curl -sI http://neverssl.com | head -n 5

On an ordinary network you get HTTP/1.1 200 OK with the site's own headers (mine returned Server: Apache/2.4.68). On a network that intercepts traffic, you get a redirect (302) to a portal or an unexpected host. That is not proof of an attack, since real portals do the same, but it tells you something is in the middle and which page it wants you on.

3. Does the certificate match what you expect?

Ask for a site's certificate and read the issuer:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

On my machine this printed an issuer of Cloudflare TLS Issuing ECC CA 3 and a subject of CN=example.com. Run it on a trusted network first to get a baseline, then on the new network. A different issuer for the same site, or an s_client error about verification, is a red flag. Do not click through the browser warning that goes with it.

Where a VPN fits

A VPN builds an encrypted tunnel between your device and the VPN server. The access point, real or fake, then sees one connection to one endpoint and encrypted packets. The plain HTTP, DNS queries and SNI hostnames from the list above stop being readable to the access point. That is the real benefit on untrusted Wi-Fi.

A VPN does not change three things:

• A password you type into the attacker's portal. The VPN protects the path, not your choice to submit credentials to the wrong page.
• The order of operations. On most captive-portal networks you have to pass the portal before a VPN can connect. Verify the portal first, then connect, then do anything sensitive.
• Trust. You moved from trusting the café router to trusting the VPN operator.

If you want a quick sanity check after connecting, run the three checks above again, plus the curl trace. The visible IP should now be the VPN server's. Atomic VPN is one you can use for that comparison.

A small habit list

• Turn off auto-join for open networks on your phone and laptop.
• Forget a network after you use it, especially airport and flight Wi-Fi.
• Treat any "log in with your email or social account to get Wi-Fi" page as hostile.
• Keep file sharing off on untrusted networks.
• Do payments and logins on mobile data when you can.

FAQ

What is an evil twin attack?

A fake Wi-Fi access point that copies the name of a real one, so devices connect to it. The operator can then read unencrypted traffic and serve fake login pages.

Can someone read my passwords on public Wi-Fi if the site uses HTTPS?

Not from the encrypted connection, as long as the certificate is valid. They can still capture what you type into a fake page they control.

How can I tell a fake Wi-Fi network from a real one?

You often cannot by name. Check the portal's domain and certificate, watch for requests for email or social credentials, and compare behavior against a trusted network.

Does a VPN protect me on airport Wi-Fi?

It hides your traffic from the access point, including DNS and the site list. It does not protect credentials you hand to a fake login page.

Is in-flight Wi-Fi more dangerous than other public Wi-Fi?

The mechanism is the same. The 2024 case is notable because it was alleged to span flights and airports, but home, café and hotel networks have the same weakness.

What is HSTS?

A header, defined in RFC 6797, that tells a browser to use only HTTPS for a site for a set period. It blocks protocol-downgrade tricks after the first visit.

Bottom line

On a network you do not control, assume the operator can read plain HTTP, your DNS and the hostnames you visit. HTTPS keeps the content private. A VPN hides the rest from the access point. Neither helps if you type a password into the wrong page, so the habit that matters most is the dull one: do not log in to anything just to get online.

What is the strangest captive portal you have seen? Describe it in the comments.