SimFinder
Security

How to Use Public Wi-Fi Safely

Public Wi-Fi risks are real but manageable. The spread of HTTPS (TLS) across the web has significantly reduced the harm a passive attacker on the same network can cause — your data in transit is encrypted to the destination server. The remaining risks come from rogue access points, evil-twin networks, and apps or services that do not use encryption. Five measures address the majority of practical risk: verify you are connecting to the correct network, use a VPN, keep HTTPS-only mode on, turn off auto-join for public networks, and switch to mobile data for banking and sensitive logins.

This guide explains each threat and what to do about it, without speculation about attacker capabilities that cannot be verified.


Why Public Wi-Fi Is Different From Your Home Network

On your home or office Wi-Fi, you control who has the password and who has physical access to the router. On a public network in a café, hotel, airport, or library, anyone in range can join the same network — including attackers.

On a shared network, another device on the same subnet can:

  • Passively observe unencrypted traffic (traffic sent without HTTPS)
  • Attempt ARP spoofing or similar techniques to redirect traffic through their device
  • Set up a rogue access point mimicking the legitimate network

What an attacker on the same network cannot do, assuming correct HTTPS implementation on the site you are visiting:

  • Read the content of your HTTPS-encrypted sessions
  • Learn which specific pages within an HTTPS site you are viewing (though the domain name may be visible via DNS or TLS Server Name Indication)

The practical implication: widespread adoption of HTTPS has reduced but not eliminated the risk of using public Wi-Fi. The threats that remain are worth understanding and defending against.


Threat 1: Passive Eavesdropping on Unencrypted Traffic

When a website or application sends data without encryption — using plain HTTP rather than HTTPS — any other device on the same network can read that traffic. This includes login credentials, session cookies, and any information you submit in forms.

Most major websites now redirect HTTP connections to HTTPS automatically. However, some older or poorly maintained sites and applications still send data in plaintext. Apps that use unencrypted API connections are particularly difficult to identify because the user sees no visible difference.

What to do:

  • In your browser, enable HTTPS-only mode. In Chrome and Firefox on desktop, this can be configured in security settings. On iOS, Safari enforces HTTPS warnings by default.
  • Check for the padlock icon (or equivalent) in your browser’s address bar before submitting any login or payment information.
  • Treat any site that serves over plain HTTP on a public network as insecure for any sensitive interaction.

Threat 2: Man-in-the-Middle Attacks

A man-in-the-middle (MITM) attack occurs when a device positions itself between your device and the router, intercepting traffic before it reaches the internet. This can be accomplished on a local network through ARP spoofing (also called ARP poisoning), where the attacker convinces your device that their MAC address corresponds to the router’s IP address.

If the attacker can intercept your traffic before a TLS connection is established, they can potentially see the content of that traffic — or serve you a fake version of a site to capture credentials.

TLS certificate validation is a defence against MITM: if an attacker tries to impersonate an HTTPS site, the browser will warn you that the certificate is invalid (unless the attacker has somehow installed a trusted root certificate on your device, which would require prior compromise of the device).

What to do:

  • Do not dismiss browser certificate warnings on public networks. A certificate error on a public network may indicate a MITM attack rather than a simple configuration issue.
  • Use a VPN (see the VPN section below). A VPN establishes an encrypted tunnel to a server before any application traffic is sent, so a local MITM attacker sees only VPN-encrypted data.

Threat 3: Evil-Twin and Rogue Access Points

An evil-twin attack involves setting up a Wi-Fi access point with the same network name (SSID) as a legitimate network. If you — or your device’s auto-join — connects to the attacker’s access point, all your traffic passes through the attacker’s equipment before reaching the internet.

Unlike a MITM attack on a shared network, an evil-twin positions the attacker as the network infrastructure itself. The attacker does not need to exploit any protocol weakness to intercept your traffic — they see it by design.

Rogue access points can also be set up in locations without any legitimate network, advertising open Wi-Fi to attract connections.

What to do:

  • Confirm the exact network name and, where possible, the network password with a staff member before connecting in airports, hotels, or cafés.
  • Disable auto-join for all public networks (see the auto-join section below).
  • Use a VPN immediately upon connecting to any public network, before performing any browsing or application activity.

Threat 4: Auto-Join Connecting You Without Your Knowledge

Most operating systems save the name (SSID) of every Wi-Fi network you join and automatically reconnect when that SSID is detected again. An attacker can broadcast any SSID — including common names like “Starbucks”, “Airport WiFi”, or the name of your home network — and nearby devices with auto-join enabled may connect automatically.

This is not a theoretical risk. Network probing by devices broadcasting saved SSIDs is a known technique used in wireless security assessments.

What to do:

On iPhone and iPad (as of publication):

  • Go to Settings → Wi-Fi, tap the More Info button (shown as (i) on older iOS) next to any saved public network → set Auto-Join to off, or tap Forget This Network after each session.
  • Settings → Wi-Fi → Auto-Join Hotspot controls automatic joining of personal hotspots from contacts, not general public networks — these are separate settings.

On Android (as of publication, varies by manufacturer):

  • Go to Settings → Network & Internet → Wi-Fi → Saved networks to view and remove saved public networks after use.
  • Some manufacturers offer a per-network auto-connect toggle in the network detail screen.

For any public network you do not intend to return to: remove it from saved networks rather than simply turning auto-join off. An SSID that is saved but has auto-join disabled on iOS will still appear in the network list and may auto-join if a policy changes in an OS update.


The Role of HTTPS (TLS) in Reducing Wi-Fi Risk

HTTPS uses TLS (Transport Layer Security) to encrypt the content of communications between your browser and the server. As of publication, Let’s Encrypt, a free certificate authority operated by the non-profit Internet Security Research Group (ISRG), has significantly reduced the cost and friction of deploying HTTPS, contributing to broad adoption across websites and applications.

HTTPS protects the content of your communication — what you submit in forms, what the server sends back — from a passive observer on the same network. It does not conceal the destination domain (visible in DNS queries and TLS Server Name Indication by default) or the fact that you are communicating with a given server.

Browser initiatives have pushed HTTP towards effective deprecation for authenticated interactions. The major browsers — Chrome, Firefox, Safari, Edge — display warnings or block forms submitted over plain HTTP.

What HTTPS does not protect against:

  • Connecting to an evil-twin AP before a TLS session is established with the legitimate server
  • Applications that do not implement HTTPS (this is increasingly rare for major services but still exists)
  • Certificate errors that users dismiss without understanding the risk

What this means in practice: HTTPS has substantially reduced the risk of passive eavesdropping on public Wi-Fi. For ordinary browsing of major HTTPS sites, a passive attacker on the network learns very little. Active attacks — rogue APs, MITM — require more effort and remain possible, which is why additional measures (VPN, auto-join controls) are still warranted.


Using a VPN on Public Wi-Fi

A VPN (Virtual Private Network) creates an encrypted tunnel between your device and a VPN server before routing your internet traffic. From the perspective of the local network — including any rogue access point — all outbound traffic from your device is the VPN tunnel; the contents are opaque.

What a VPN provides on public Wi-Fi:

  • Encrypts traffic between your device and the VPN server, preventing local network observers from reading it
  • Prevents local ARP spoofing or evil-twin attacks from seeing your application traffic
  • Routes DNS queries through the VPN tunnel, preventing local observation of your DNS lookups

What a VPN does not provide:

  • Protection against the VPN server itself (the VPN provider can see your traffic if they choose to log it)
  • Anonymity on the destination server side — the destination sees the VPN server’s IP address, but your traffic is visible to the VPN provider
  • Protection if the VPN is not connected at the moment of attack (a VPN that drops connection and fails open does not protect against a race condition)

Choosing a VPN provider:

  • Look for providers with independently audited no-logs policies. Several established commercial VPN providers have published audit reports from firms such as Cure53 or KPMG. Audits confirm the technical architecture but cannot guarantee future behaviour — they audit a snapshot.
  • Operating system built-in VPN (IKEv2/IPsec, L2TP, WireGuard) can be configured with a self-hosted VPN server if you prefer to route traffic through infrastructure you control.
  • A VPN built into a browser (such as the Opera browser VPN) only protects traffic from that browser, not from other apps.

On mobile (iOS and Android): Enable the VPN before connecting to a public network. If your VPN app supports an “always-on VPN” or “kill switch” mode, enable it — this prevents your device from sending any traffic outside the VPN tunnel if the VPN connection drops.

On iOS (as of publication): Settings → General → VPN & Device Management → VPN — you can configure an always-on VPN here if your MDM profile supports it, or use a VPN app that implements the kill switch via the Network Extension framework.

On Android (as of publication): Settings → Network & Internet → VPN — tap the gear icon on your configured VPN and enable Always-on VPN and Block connections without VPN.


Captive Portals and What Happens When You First Connect

Many public Wi-Fi networks — in hotels, airports, cafés, and transit systems — use a captive portal: a web page that intercepts your first HTTP request after connection and requires you to accept terms, enter a room number, or pay before granting full internet access.

Captive portals present a specific security challenge: to display the portal page, your device must send unencrypted HTTP traffic that the portal can intercept and respond to. During this window, before you authenticate to the portal, your device is on the network without a VPN tunnel established, because the VPN itself may be blocked until the portal is completed.

What to do with captive portals:

  • Complete captive portal authentication before attempting to connect your VPN, or enable the VPN in the device settings so it attempts to connect automatically after portal authentication.
  • Use your browser’s captive portal login page rather than entering credentials into an app or other interface — the browser displays the site’s certificate, giving you a basis to verify you are on the legitimate portal.
  • Some VPN apps include a “captive portal detection” mode that temporarily allows unencrypted traffic for portal authentication only. Check your VPN provider’s documentation.
  • On iOS (as of publication), the system automatically detects captive portals and opens a browser window for authentication. On Android, a notification appears prompting you to sign in.

Do not submit any personal account credentials (email, passwords) during the captive portal flow itself — captive portals require only network-level authentication (terms acceptance, payment code, or room number), not your personal account passwords.

After completing captive portal authentication, connect your VPN before proceeding to any other application or website.


Avoid Sensitive Actions on Public Wi-Fi — Use Mobile Data Instead

Even with a VPN, some situations call for extra caution. For financial transactions, online banking, accessing email accounts, or any service where a credential compromise carries significant consequences, the lowest-risk approach is to switch to mobile data (turn Wi-Fi off entirely) before proceeding.

Mobile data travels over the cellular network. An attacker in a coffee shop or airport cannot passively observe your cellular traffic — they would need access to cellular network infrastructure. This is a categorically different threat model from public Wi-Fi.

The practical workflow:

  1. Before logging into your bank, payment service, or work email from a public location: turn Wi-Fi off.
  2. Perform the sensitive action over mobile data.
  3. Turn Wi-Fi back on after completing the session and logging out.

For travellers using a dual-SIM setup with a local eSIM for data and a home SIM kept in reserve, your home SIM’s data connection can serve as a fallback for sensitive tasks. See Using Dual SIM for Travel for how to configure line assignments. If you are on a limited data plan, be aware of data costs — see How Much Mobile Data Do You Need? and Data-Saving Techniques for context on consumption.


Keep Your Operating System and Apps Updated

Operating system updates frequently include security patches for network-related vulnerabilities. The same applies to browser updates, which address TLS implementation issues, certificate validation bugs, and other security weaknesses.

An unpatched operating system on a public network is a more exposed target than a fully patched one — vulnerabilities in network stack components can sometimes be exploited by other devices on the same network without any action from the user.

Practical steps:

  • On iPhone: Settings → General → Software Update → Automatic Updates — enable both “Download iOS Updates” and “Install iOS Updates”. Allow major updates to download on Wi-Fi at home.
  • On Android: Settings → System → System Update — enable automatic updates. The path varies by manufacturer.
  • Update your browser independently of the OS on platforms where this applies (Chrome and Firefox update independently of the OS on Windows and macOS).

Perform major OS updates on a trusted network (your home Wi-Fi or mobile data) rather than a public Wi-Fi connection. Major updates can be several gigabytes in size — see Data-Saving Techniques for how to restrict large downloads to Wi-Fi or mobile data you trust.


Summary: Five Steps for Safer Public Wi-Fi Use

  1. Verify before connecting. Confirm the exact network name with a staff member. Avoid connecting to open networks you did not seek out.
  2. Enable a VPN immediately. Connect your VPN before doing anything else on the network. Use always-on / kill switch mode if available.
  3. Keep HTTPS-only mode active. Do not dismiss certificate warnings.
  4. Turn off auto-join for public networks. Remove public networks from saved networks after each session.
  5. Use mobile data for sensitive actions. Switch to your cellular connection for banking, financial accounts, and sensitive logins — do not rely on Wi-Fi for those tasks even with a VPN.

If you use public Wi-Fi frequently when travelling, a Wi-Fi Calling–enabled SIM can let you receive calls and messages over trusted Wi-Fi at home or abroad without exposing your call content to the local network — see Wi-Fi Calling (VoWiFi) for how that works. For managing connectivity across multiple countries, International Roaming Explained covers how your home SIM behaves abroad.