Aanvallen op openbare WiFi in 2026 — wat er werkelijk gebeurt en wat het tegenhoudt

De korte versie: de klassieke dreiging uit 2015 — "iemand op het café-WiFi kan je wachtwoorden lezen" — is grotendeels verdwenen. HTTPS is overal, HSTS-preload dekt de grote sites, en SSL-strip-aanvallen hebben een veel kleinere aanvalsoppervlak dan vroeger. Maar drie categorieën aanvallen werken nog steeds in 2026, en aanvallers hebben zich aangepast: evil-twin rogues APs (een netwerk namaken dat je vertrouwt en je apparaat automatisch laten verbinden), captive portal-exploitatie (de welkomstpagina die je e-mail vraagt of malware pusht), en verkeersanalyse op metadataniveau (versleuteld maar observeerbaar: met wie je communiceert, wanneer, hoe vaak en hoeveel). De maatregelen die echt helpen zijn: een echte VPN-tunnel (niet alleen DNS), MAC-randomisatie ingeschakeld laten, ongevraagde inlogprompts van captive portals negeren, en de beveiligingsstandardinstellingen die Apple/Google standaard meeleveren.

Wat er werkelijk gebeurt op een typisch vijandig netwerk

Een "vijandig netwerk" betekent niet per se dat het café kwaad in de zin heeft. Meestal betekent het een of meer van het volgende:

• De legitieme netwerkbeheerder verzamelt gegevens over verbonden apparaten (extreem gebruikelijk bij retail, vrij gebruikelijk bij hotels) voor marketing of analyses.
• Een andere bezoeker draait observatietools op hetzelfde subnet (minder gebruikelijk dan vroeger, maar triviaal met hardware van €200).
• Een aanvaller heeft een nep-accesspoint in de buurt met dezelfde SSID als een vertrouwd netwerk, in de hoop dat je apparaat automatisch verbinding maakt.
• Het captive portal serveert kwaadaardige inhoud — advertentie-injectie (hinderlijk), phishing naar inloggegevens (schadelijk) of malware-push (zeldzaam maar grote impact).

Voor de meeste mensen, op de meeste dagen, doet geen van deze gevallen er wezenlijk toe — HTTPS-versleuteling beschermt je actieve sessies, en moderne standaardinstellingen van het OS regelen de voor de hand liggende gevallen. De gevallen die er nog toe doen zijn wanneer je lang genoeg op een netwerk zit zodat een geduldige aanvaller kan wachten, wanneer je blindelings een verzoek van een captive portal accepteert, of wanneer je apparaat automatisch verbinding maakt met wat je denkt dat je thuisnetwerk is, maar dat niet is.

Aanval 1 — Evil twin (nep-accesspoints)

Wat het is: Een aanvaller brengt een draagbaar accesspoint (een WiFi Pineapple, of gewoon een laptop met de juiste software) in de buurt van een doelwit. Ze zenden een SSID uit die overeenkomt met een netwerk waarmee het apparaat van het doelwit eerder verbinding heeft gemaakt — "attwifi", "xfinitywifi", "Starbucks WiFi", de naam van je thuisnetwerk — met een sterker signaal dan het legitieme netwerk (of het legitieme netwerk is helemaal niet in bereik).

Je apparaat, in je zak, maakt automatisch verbinding omdat het een "bekend" SSID ziet. Nu is de aanvaller het netwerk: ze zien je DNS-queries (en je onversleuteld verkeer, al is daar weinig van over), ze kunnen captive portal-prompts tonen en ze kunnen andere vervolgaanvallen proberen.

Realiteit in 2026: werkt nog steeds, met aanpassingen. iOS 14+ en Android 10+ implementeren beide Private MAC Address — je apparaat toont een ander MAC-adres aan elk SSID, zodat cross-netwerk tracking moeilijker is. Maar dat stopt het automatisch verbinden niet; de aanvaller heeft je echte MAC niet nodig, ze willen alleen dat je apparaat koppelt. Wat meer heeft geholpen is dat iOS 16+ expliciet waarschuwt voor netwerken met zwakke beveiliging (open, WEP, alleen WPA) en gebruikers steeds meer aanspoort om niet automatisch te verbinden; Android 13+ doet iets vergelijkbaars.

Wat het tegenhoudt: Zet "automatisch verbinden" uit voor openbare netwerken (Instellingen → Wi-Fi → tik op netwerk → Automatisch verbinden uit op iOS; zelfde pad op Android met lichte UI-verschillen). Op netwerken waar je wel op verbindt, zorgt een VPN-tunnel ervoor dat de aanvaller-als-netwerk alleen versleutelde bytes ziet — ze kunnen je verkeer niet lezen, geen inhoud injecteren en geen captive portal-phishing naar inloggegevens uitvoeren (want je browser waarschuwt voor certificaatmismatches als ze het proberen).

Aanval 2 — Captive portal-exploitatie

Wat het is: De welkomstpagina die verschijnt wanneer je verbinding maakt met WiFi in een hotel, op een luchthaven of in een café ("Accepteer voorwaarden om door te gaan"). De portalpagina wordt geserveerd door het authenticatiesysteem van het netwerk en is, by design, het eerste wat je apparaat op dat netwerk te zien krijgt — voordat je VPN verbinding kan maken, voordat HTTPS-waarschuwingen context hebben, voordat je echt zeker weet wie hem serveert.

Drie varianten van hoe dit wordt misbruikt:

• Stelen van inloggegevens: de welkomstpagina vraagt om je e-mailadres en een wachtwoord "om in te loggen." Veel mensen voeren het wachtwoord in dat ze ook voor andere accounts gebruiken. De aanvaller heeft nu je e-mail + wachtwoord uit je typische hergebruikspatroon.
• Drive-by malware-push: de welkomstpagina linkt naar "je gratis koffiebon" wat een kwaadaardige app-download is. De meeste moderne browsers waarschuwen; mobiele gebruikers klikken waarschuwingen vaker weg dan desktopgebruikers.
• Verzamelen van persoonsgegevens: de welkomstpagina vraagt om je telefoonnummer "voor connectiviteit" en je geeft het. Nu staat het in een marketingdatabase, vaak doorverkocht.

Realiteit in 2026: captive portal-phishing is vaker geworden, niet minder. De OS-niveau beveiligingen (private MAC, VPN) helpen hier niet omdat de gebruiker willens en wetens gegevens invoert. Wat geholpen heeft is dat iOS 17+ en Android 14+ captive portals presenteren in een sandboxed mini-browser die exfiltratiewegen beperkt — maar de gegevens die de gebruiker intypt worden nog steeds verstuurd.

Wat het tegenhoudt: Voer nooit een wachtwoord dat je elders gebruikt in op een captive portal. Voer nooit een telefoonnummer in dat je voor iets belangrijks gebruikt. Behandel captive portals standaard als vijandig. Als een netwerk "registratie" vereist die om wezenlijke informatie vraagt, verlaat het dan en gebruik mobiele data voor het komende uur. Caspers AI-dreigingsdetectie beoordeelt captive portal-domeinen op dezelfde manier als SMS-phishing — bekende slechte portals worden gemarkeerd voordat je iets typt.

Aanval 3 — Verkeersanalyse op metadataniveau

Wat het is: Zelfs wanneer je verkeer versleuteld is (HTTPS, TLS, elk modern protocol), kan een waarnemer op hetzelfde netwerk nog steeds zien met wie je communiceert, wanneer, hoe vaak en hoeveel data er stroomt. Ze kunnen de inhoud niet lezen, maar ze kunnen wel een profiel van je gedrag opbouwen.

Op een vijandig WiFi-netwerk betekent dit:

• De lokale beheerder kan zien dat je je bank, je zorgverlener, je datingapp, enz. bezoekt — ook al kunnen ze niet zien wat je daar doet.
• Verkeersvolume-patronen onthullen wat je doet (videostreaming heeft een kenmerkende vorm; berichten sturen een andere; bankieren weer een andere).
• DNS-queries (tenzij DoH/DoT/DNS-over-VPN gebruikt) lekken bestemmingen op hostnameniveau.
• TLS Server Name Indication (SNI) lekte historisch gezien de bestemming zelfs wanneer DNS versleuteld was — Encrypted Client Hello (ECH) sluit deze kloof vanaf 2025-2026.

Realiteit in 2026: ECH-adoptie is significant (Cloudflare heeft het eind 2024 standaard ingeschakeld, grote browsers ondersteunen het in stabiele releases) maar de dekking is gedeeltelijk. Voor sites die ECH nog niet hebben ingeschakeld, lekt SNI nog steeds. Zelfs met ECH is de verbindingsbestemming op IP-niveau nog steeds observeerbaar, en IP-naar-dienst-koppelingen zijn publiek — verbinding maken met een cluster van IP-adressen van Meta vertelt de waarnemer dat je WhatsApp of Instagram gebruikte, zelfs met alles versleuteld.

Wat het tegenhoudt: Een volledige VPN-tunnel. Je verkeer verlaat het lokale netwerk bestemd voor één IP (het VPN-eindpunt); het lokale netwerk kan zien dat je een VPN gebruikt maar kan niets verder zien. Dit is de meest impactvolle bescherming tegen verkeersanalyse op vijandige netwerken. Alleen-DNS-beveiligingen (NextDNS, Cloudflare 1.1.1.1) helpen met het DNS-querykanaal maar pakken SNI of IP-niveau observatie niet aan — daarvoor heb je de tunnel nodig. Onze diepgaande analyse van de beperkingen van DNS-niveau filtering behandelt precies deze kloof.

Aanvallen die grotendeels niet meer werken

Drie klassieke openbare-WiFi-dreigingen waarover gidsen uit 2015 uitgebreid spreken, maar die in 2026 grotendeels opgelost zijn:

SSL strip / SSL split

sslstrip (het 2009-tool van Moxie Marlinspike) degradeerde HTTPS naar HTTP op het netwerk en herschreef formulieren — jarenlang een café-klassieker. Vandaag: HSTS-preload dekt vrijwel elke site die inloggegevens verwerkt (bankieren, e-mailproviders, sociale media, enz.). Browsers weigeren preloaded domeinen te degraderen. Sites zonder HSTS bestaan maar verwerken zelden iets dat een aanvaller zou willen lezen.

ARP-spoofing voor algemene MITM

ARP-spoofing op een gedeeld subnet laat een aanvaller zich invoegen tussen je apparaat en de gateway. Werkt nog steeds voor het LAN-segment, maar wat ze krijgen is versleuteld verkeer — hetzelfde probleem als bij de verkeersanalyse-aanval hierboven. De "zie je wachtwoorden" opbrengst is verdwenen, tenzij ze ook TLS kunnen verslaan, wat ze doorgaans niet kunnen op preloaded sites.

DNS-spoofing op het lokale netwerk

Een vijandige netwerkbeheerder kan valse DNS-antwoorden teruggeven voor hostnames die je opvraagt, waardoor je wordt doorgestuurd naar phishing-klonen. Dit was effectief toen DNS onversleuteld was en TLS-certificaten gemakkelijk te vervalsen waren. Vandaag: certificate transparency-logs en HSTS-preload betekenen dat de phishing-kloon een geldig certificaat voor het doeldomein zou moeten verkrijgen (extreem moeilijk voor populaire sites) — en DNS-over-HTTPS / DNS-over-TLS / VPN-gerouteerde DNS verslaan elk de spoofing op de DNS-laag. Werkt nog steeds voor onervaren gebruikers op kleine obscure sites; zelden een probleem voor de gemiddelde consument.

Per platform: wat elk OS voor je doet

iOS / iPadOS

• Private MAC Address standaard ingeschakeld voor nieuwe SSID's sinds iOS 14
• Waarschuwingen voor WPA2-en-lager netwerken (push naar WPA3) sinds iOS 16
• Automatisch verbinden instelbaar per SSID
• iCloud Private Relay (iCloud+-abonnees) versleutelt Safari-verkeer — zie onze Private Relay-diepgaande analyse voor wat het wel en niet dekt
• VPN-on-Demand-ondersteuning voor het automatisch starten van Casper bij niet-vertrouwde SSID's

Android

• Private MAC Address (heet "Gebruik willekeurig MAC") standaard ingeschakeld sinds Android 10
• Private DNS (DoT) native ondersteuning sinds Android 9
• Per-app VPN-routing (flexibeler dan iOS)
• "Controleer opgeslagen netwerken"-meldingen sinds Android 13 — markeert wanneer een bekend SSID een ander beveiligingsprofiel heeft dan voorheen (mogelijk evil twin)
• Dreigingsdetectie op netwerkniveau in Play Protect

macOS

• Privé Wi-Fi-adres sinds macOS Sequoia (pariteit met iOS)
• iCloud Private Relay (iCloud+)
• Ingebouwde firewall + Stealth Mode (standaard uitgeschakeld — zie onze macOS-privacygids)
• FileVault-versleuteling (standaard ingeschakeld op nieuwe Macs)

Praktische werkwijze: wat je werkelijk doet als je verbinding maakt met café-WiFi

1. Verifieer de SSID bij het etablissement. "Hoe heet jullie WiFi?" — een controle van 3 seconden die de meeste evil-twin-aanvallen verijdelt. Het nep-accesspoint heeft meestal een naam die bijna maar niet exact overeenkomt met de legitieme.
2. Accepteer het captive portal zonder wezenlijke gegevens in te voeren. "Accepteer voorwaarden" — prima. "Voer je e-mail + wachtwoord in" — sluit het tabblad, gebruik mobiele data. "Voer je telefoonnummer in" — alleen als je erop vertrouwt dat die gegevens niet worden doorverkocht.
3. Zet je VPN aan voordat je iets gevoeligs doet. Sommige configuraties (Caspers iOS-app, NetworkExtension auto-trigger) doen dit automatisch bij het verbinden met nieuwe SSID's. Het venster tussen het verbinden met het netwerk en het tot stand brengen van de VPN-verbinding is wanneer verkeersanalyse-aanvallen het meest blootgesteld zijn; minimaliseer dit.
4. Stel het netwerk niet in op automatisch verbinden voor toekomstige bezoeken tenzij je de beheerder vertrouwt. De 5-seconden-kosten van handmatig elke keer verbinden wegen op tegen de 0,01%-kans op een evil-twin-aanval op die locatie later.
5. Schakel Bluetooth / AirDrop uit als je ze niet nodig hebt op echt vijandige netwerken. Dit zijn aparte aanvalsoppervlakken van WiFi maar worden vaak tegelijk aangevallen.
6. Vergeet het netwerk als je vertrekt. Instellingen → Wi-Fi → tik op netwerk → Vergeet. Vermindert toekomstige blootstelling via automatisch verbinden.

Wanneer is een VPN echt noodzakelijk versus handig?

Eerlijk gezegd: bij een typisch 5-minuten café-bezoek waarbij je e-mail + Slack doet op HTTPS-overal-diensten, is de praktische dreiging laag. De TLS-beveiligingen doen het werk. Een VPN biedt verdediging in de diepte, maar je wordt zonder één de meeste tijd niet zichtbaar aangevallen.

De gevallen waarbij een VPN er wezenlijk toe doet:

• Vijandige internationale netwerken (hotel-WiFi in het buitenland in jurisdicties met actieve staatssurveillance op netwerkniveau, of bekende vijandige conferentienetwerken).
• Lange sessies op hetzelfde netwerk (uren werken vanuit een café, hotel-WiFi voor een verblijf van meerdere dagen) — geeft aanvallers tijd en een stilstaand doelwit.
• Netwerken van onbekende herkomst (de WiFi op het kantoor van iemand, het netwerk in een kleine Airbnb, conferentie-WiFi beheerd door wie-weet-wie).
• Wanneer gevoelige activiteiten van belang zijn — toegang tot gezondheidsinformatie, echt bankieren, alles waarbij je niet blij zou zijn als een waarnemer een profiel opbouwt.
• Om verkeersanalyse-profilering te verslaan door de netwerkbeheerder, die vrijwel altijd op zijn minst metadata logt.

Voor deze gevallen is een echte VPN-tunnel (niet alleen DNS-niveau filtering) de juiste interventie. Caspers dreigingsbeschermingslaag bundelt de WireGuard-tunnel met AI-gebaseerde zero-day phishing-detectie, blocklist-filtering en per-app-routeringscontroles. De tunnel staat aan; de versleuteling is end-to-end; het lokale netwerk ziet versleutelde bytes en niets anders.

Wat betreft telefoon-hotspot versus openbare WiFi?

De hotspot van je telefoon (mobiel tetheren) is dramatisch veiliger dan willekeurige openbare WiFi, omdat:

• Jij het enige apparaat erop bent (geen andere bezoekers die observatietools draaien)
• De provider de enige upstream-beheerder is (een bekende entiteit, gereguleerd, doorgaans betrouwbaar op metadataniveau)
• De versleuteling je eigen WPA3-configuratie van je telefoon is, die jij beheert
• Het tijdelijk is — geen voortdurende blootstelling wanneer je vertrekt

De kosten zijn datagebruik. Voor privacygevoelige sessies (bankieren, gezondheidszorg, gevoelig werk) is tetheren over het algemeen een beter standaard dan hotel/café-WiFi — zeker als je geen VPN hebt geconfigureerd. De meeste providers bevatten enige hotspot-data in moderne abonnementen; controleer dit voordat je erop vertrouwt voor lange sessies.

Conclusie

Openbare WiFi in 2026 is niet het rampgebied uit 2015, en het standaardadvies ("gebruik nooit openbare WiFi") raakt steeds meer uit de pas met het werkelijke dreigingsmodel. Het pragmatische 2026-kader: HTTPS beschermt de inhoud van je verkeer; wat blootgesteld blijft zijn de metadata, het captive portal en het aanvalsoppervlak van automatisch verbinden. Een VPN sluit de kloof bij metadata en verkeersanalyse. Captive portal-discipline (typ er geen wachtwoorden of e-mails in) sluit de phishing-kloof. SSID-verificatie voor het verbinden regelt het evil-twin-geval.

Als je dat allemaal geautomatiseerd wilt — VPN aan, dreigingsdetectie aan, DNS-filtering aan, per-app-routing waar je het wilt — dat is wat Casper doet op elk netwerk waar je verbinding mee maakt. Gratis proefperiode, apps voor iPhone, Mac en Android.