Beetje achterhaald allemaal. Tegenwoordig is er OWE.

https://www.networkworld.com/article/3325745/opportunistic-wireless-encryption-um-what-s-that-again.html

Het klopt wat je zegt maar ik gooi er zelf toch nog wel graag een VPN connectie overheen omdat dan ook de DNS requests buiten beeld blijven. Ook daar zijn wel andere oplossingen voor maar zo doe ik het.

Om het risico van het gebruik van public wifi in te kunnen schatten, zou je moeten weten:
1) Hoe groot de kans is dat de eigenaar (of hacker) van het access point kwaadaardig is;
2) Of en hoe kwetsbaar jouw device + software zijn voor aanvallen vanuit/via het access point;
3) Of jouw device op onveilige wijze multicasts verstuurt, servers/printers zoekt, verbindingen maakt en/of updates downloadt;
4) Of je zelf onverstandige dingen doet (en software je daar niet tegen beschermt).

Wellicht het grootste probleem van public WiFi is dat je niet weet of je met een access point van de bedoelde eigenaar verbinding maakt, of van iemand "met een hoodie en vallende groene letters op een zwart scherm". OWE helpt hierbij geen zier.

WPA2-PSK kent zwaktes en er bestaan buggy implementaties, maar een nep publiek access point optuigen zal in de meeste gevallen eenvoudiger zijn dan een MitM-aanval op WPA2-PSK met een fatsoenlijk (lang en geheimgehouden) wachtwoord.

In elk geval zou ik zelf nooit met een niet-dichtgetimmerde Windows laptop gebruik maken van public WiFi. Van Android en iOS weet ik het niet, maar er zijn voldoende "handige" protocollen om bestanden met "devices in de buurt" uit te kunnen wisselen, dat ik ook hiervoor niet mijn hand in het vuur durf te steken.

De kans dat er "zo'n hoodie" in je buurt zit is waarschijnlijk klein. Maar niet alles gaat over https en zeker niet op een lokaal netwerk (ongemerkt lek je allerlei informatie waaronder mogelijk je naam, en als jouw device via IMAP mail ophaalt weet die "hoodie" ook op welke server jij een 1FA account hebt).

Staat je browser op https-only?

Anders kan de beheerder de dns natuurlijk aanpassen en zorgen dat je nooit op https uitkomt (mits hsts niet werkt op de bezochte site).

Maar dan zul je dat altijd zien in de adresbalk. En ja, ik gebruik HTTPS ONLY.

@ Erik, dank voor de feedback, nuttig!

Maar wat is nu het risico als iemand een super evil access point heeft? Browser traffic via https is niet te onderscheppen, zeker niet bij HTTPS ONLY. En als je wordt geredirect naar een HTTP of andere site is dat zichtbaar.

Updates in de background die niet via een versleutelde verbinding gaan zijn tricky inderdaad. Maar als je puur naar de browser kijkt geloof ik het eigenlijk wel. DNS requests boeien mij niet zoveel. Een attacker mag best weten dat ik naar website x, y of z ga.

HSTS helpt om connecties met nep sites te voorkomen maar die gebruiken heel veel sites niet. Als ik een kwaadwillende ben en een accesspoint opzet kan ik zien waar jouw DNS requests naar toe gaan, om die gegevens vervolgens te gebruiken om je een volgende keer naar een nagebouwde nep versie van die site te laten gaan en "in te laten loggen". En apps hebben geen adres balk waarin dat op zou kunnen vallen.

Hoe weet jij dat je device alleen HTTPS doet? Een site die https doet kan nog best vanalles (zoals ads en scripts) sideloaden via HTTP. een app die gewoon HTTP doet is niet te achterhalen want dat zie je niet eens in een adres balk. als je niet op je device HTTP actief uitzet (b.v. met firewall) dan kan dat nog steeds HTTP zijn. daarnaast is DNS veelal niet versleuteld. je krijgt van je public wifi een dns server via DHCP, die kan vervolgens ook vanalles achterhalen waar je naar toe gaat.

Daarnaast kan je ook een poort op je device open hebben staan die door een lek aangevallen kan worden.
dus nee public WIFI is niet ineens veilig nu er veel HTTPS gebruikt wordt.

Hm. Wat nu als ik een krachtig Wifi-station in je buurt zet die ik dezelfde naam geef als jouw thuis-router, en die een verbinding accepteert, regardless-of-fifi-password?

Dan is er een dikke kans dat je al op mijn Wifi zit, zonder dat je het in de gaten hebt.
Oplossing is dat je gewoon vanaf je pc jet netwerk nooit vertrouwd.


https://webwereld.nl/how-to/security/zo-hack-je-je-eigen-wifi-netwerk-3774888/
https://www.juniper.net/documentation/en_US/junos-space-apps/network-director4.0/topics/concept/wireless-ssid-masquerade.html

Goede aanvulling.

Dat ligt een beetje aan de aanval.

Stel jij gaat naar http://example.nl en je wordt dan doorgezet naar https://exampie[.]nl, valt je dat dan nog steeds op?

Hoe zie je dat voor je, voorkomen dat je op HTTPS uitkomt middels DNS aanpassingen?

Als je HTTPS ONLY gebruikt wordt je request al aan de client kant omgezet naar https://example.nl voordat er een request de deur uit gaat. Een aanvaller heeft dan nog steeds een geldig certificaat voor example.nl nodig om je request te redirecten (hostname verificatie wordt ook gewoon bij een 3xx respons gedaan).

evil twin is al zo oud als Wifi en geldt nog steeds.

Gezien bovenstaande reacties met goede argumenten denk ik dat je collega’s gelijk hebben.

Er zijn ook veel sites die HSTS niet correct hebben geïmplementeerd, je hebt dus een punt.

Echter, als je "HTTPS-Only" gebruikt, geeft jouw browser op z'n minst een waarschuwing als de benaderde site niet via https bereikbaar is. Als dat komt omdat een MitM doorgaand netwerkverkeer naar TCP poort 443 blokkeert, is het wel een enorm risico om dan op "probeer via http" te klikken. Dat lijkt mij bij public WiFi zeer onverstandig, maar er zullen vast wel mensen zijn die de risico's niet overzien.

Zolang jouw "slachtoffer" https blijft gebruiken, kom je er niet tussen.

Toegang tot DNS verkeer heb je bovendien niet als jouw "slachtoffer" bijv. DoH (DNS over Https) gebruikt of (niet gangbaar) diens hosts file heeft aangevuld.

Aan de andere kant, toegang tot DNS heb je helemaal niet nodig bij een volledige MitM aanval: je kunt middels "NAT" (Network Address Translation) de netwerkpakketjes met een server met een ander IP-adres naar keuze uitwisselen, of zelf "eindpunt" spelen. Als je in https://blog.syss.com/posts/abusing-ms-office-protos/ zoekt naar responder, zie je in het screenshot daaronder de mogelijkheden van een bekende tool waarmee verschillende servers kunnen worden nageaapt, in veel gevallen ondetecteerbaar omdat onveilige protocollen worden gebruikt.

Wat je niet wilt is gegevens uitwisselen met een andere server dan bedoeld, en ook niet dat uitgewisselde gegevens "onderweg" kunnen worden meegelezen en/of gewijzigd. Https probeert alle drie die problemen te voorkomen, en bij MitM-aanvallen word je, nornaal gesproken, op z'n minst gewaarschuwd (of de verbinding komt niet tot stand of wordt verbroken). Daarbij is https ook nog eens geheel onafhankelijk van DNS en van routering.

Voor een geslaagde moderne https-verbinding met bijv. "example.com" moet aan alle volgende voorwaarden worden voldaan:
1) De browser moet gegevens kunnen uitwisselen met de server die zich uitgeeft als "example.com";
2) De browser moet een https servercertificaat ontvangen (of al hebben) dat 100% geldig is voor "example.com";
3) De browser moet de uitgever van dat certificaat vertrouwen (het certificaat is van de enige echte "example.com");
4) De private key op de server, passend bij de public key in het certificaat, is nooit in verkeerde handen gevallen;
5) Middels Diffie-Hellman met random parameters komen server en client een symmetrische verbindingssleutel overeen;
6) De server zet de gebruikte encryptie-parameters achter elkaar, signeert ze met de private key en stuurt het resultaat naar de client;
7) De client checkt de signature: als die klopt is er een verbinding met de bedoelde server (dit sluit een MitM echter niet uit);
8) Als de client vervolgens constateert dat de server dezelfde parameters gebruikt als de client, is het zo goed als zeker dat de bedoelde server het andere eindpunt is van de versleutelde verbinding en er dus geen MitM tussen kan zitten.

Met andere woorden, als de MitM niet beschikt over een private key passend bij een door de browser vertrouwd certificaat voor de domeinnaam waar de browser verbinding mee probeert te maken, komt die verbinding niet (zonder foutmelding) tot stand. Redirects zijn ook niet mogelijk, want die kunnen pas plaatsvinden nadat de https-verbinding succesvol tot stand is gekomen.

Klopt, maar normaal gesproken zullen apps communiceren met servers met hard-coded (in die app) domeinnamen. En de "betere" apps zullen dat via https doen.

Wat bij https vanuit apps nog wel eens fout gaat is dat de programmeur wel het ontvangen server-certificaat op algemene geldigheid laat checken, maar vergeet om te checken of dat certificaat geldig is voor de bedoelde domeinnaam. Een MitM heeft dan genoeg aan een private key + servercertificaat dat geldig is voor een willekeurige domeinnaam.

Vroeger dacht ik ook dat dit eenvoudig was, maar dat klopt niet.

Als ik het goed begrijp werkt de verbindingsopbouw van WPA(2)-PSK, sterk vereenvoudigd, als volgt:
1) Zowel het AP (Access Point) als de client kennen het wachtwoord, de Pre-Shared Key. Deze wordt niet uitgewisseld;
2) Zowel het AP als de client verzinnen een niet eerder gebruikt getal (Nonce = Number used once) en sturen dat naar elkaar;
3) Zowel het AP als de client plakken beide nonces en de PSK achter elkaar en berekenen daar een soort hash over (nogmaals, dit is een vereenvoudiging van wat er echt gebeurt);
4) Die "hash" wordt de gebruikte symmetrische encryptiesleutel;
5) Ontsleutelen is alleen mogelijk als beide partijen dezelfde sleutel kennen en gebruiken.

Als een nep access point (met dezelfde SSID) het wachtwoord (de PSK) niet kent, kan er geen symmetrische sleutel ontstaan die zowel het AP als de client kennen, en komt er geen verbinding tot stand. Zo'n aanvaller zal het WiFi-wachtwoord moeten raden of brute-forcen, of gebruik moeten kunnen maken van kwetsbaarheden (zoals https://www.krackattacks.com/).

Bij public WiFi (of bekend wachtwoord) is dat allemaal niet nodig, waardoor aanvallen daarop eenvoudiger zijn dan op jouw WPA2-PSK thuis (vooral bij een lang, niet te raden en niet op de buitenmuur geschreven wachtwoord).

Zolang je browser niet in https-only staat zal de browser eerst over http een verbinding proberen op te bouwen bij de meeste sites. Als je browser de site probeert te resolven kun je dus simpelweg een ander IP adres teruggeven en de browser bezoekt die dan.

Dit werkt dus niet als je alles https-only hebt.

Tooltjes zoals sslstrip helpen daar automatisch.

Maar bij een algemeen advies kun je er niet vanuit gaan dat iedereen https-only heeft, want dat is geen standaardinstelling.
Zodra dat anders is, kun je prima op elk wifi gaan zitten.

Bovenstaande reacties in overweging genomen lijkt een VPN altijd een goed idee om te gebruiken.

Je verkeer is altijd versleuteld ook bij een mitm rouge accesspoint.
Een apparaat is lastiger te hacken door anderen die op dat zelfde wifi netwerk zitten.
Je blijft altijd uit sleepnetten waar onze *IVD diensten zich weinig aantrekken van de wetten die er gelden.

Niet als je gewoon https:// intikt, zoals punt 1 in de post van TS was (En ik hoop toch dat ik mag aannemen dat je, gezien je geen andere reactie citeert, daarop aan het reageren was):

Aanvullen met: check of dit de https site is die je wilde bezoeken.... :)

Precies om deze reden zou je publieke Wi-fi niet moeten vertrouwen... een hotspot van een "evil" is zo gemaakt en voor je het weet ben je alles al kwijt :). het kan dus gewoon iemand zijn die ook op het terras zit van het cafe en dat het lijk alsof hij aan het werk is maar ondertussen.......

Een beetje WiFi AP kan een alert geven als ie een ander AP ziet met dezelfde SSID (en je kunt een lijst van MAC
adressen maken waar ie niet op reageert, voor als je zelf meerdere AP's hebt met dezelfde SSID).
Net zoals je ook een alert kunt geven als er een andere DHCP server op je netwerk actief is die wellicht netwerk
info aan een andere gebruiker geeft waardoor die alle verkeer via hemzelf routeert en kan modificeren (https niet
uiteraard).

"wij hebben op het werk" dit allemaal wel ingeschakeld en inderdaad heb ik wel eens alerts gezien. Een keer iemand
die een Raspberry Pi aangezet had met dezelfde SSID, en ook een paar keer iemand die een DHCP server in de
lucht gebracht had. Hoewel ik bij dat laatste uitga van een een configuratiefout, niet van kwade wil.

En daarom dus, jawel daar is ie weer, een VPN tunnel eroverheen.

Als je verbinding hebt gemaakt met een access-point met een kwaadaardige "eigenaar":

1) Tussen het tot stand komen van de WiFi-verbinding en het moment dat al het netwerkverkeer van jouw device door de VPN-tunnel gaat, ben je mogelijk kwetsbaar.

2) Wat doe je als je geen verbinding kunt krijgen met jouw VPN-provider, bijvoorbeeld omdat de MitM dit blokkeert? Nb. er zijn zelfs thuisrouters die verbindingen met VPN-providers kunnen blokkeren ([1]) en de VPN-provider zou ook down kunnen zijn; geen VPN kunnen krijgen betekent niet altijd kwaadaardig handelen.

3) Eind 2019 gepubliceerde resultaten ([2], de PDF is m.i. goed leesvoer) van onderzoek naar "Client-side Vulnerabilities in Commercial VPNs" laat veel gebreken zien waar een MitM misbruik van kan maken (waaronder één "secret" key voor alle gebruikers). Het zou mij verbazen als er sinds die publicatie veel verbeterd is.

4) Merk je het in alle gevallen als de VPN-tunnel wegvalt (al dan niet door toedoen van de MitM)?

[1] https://www.security.nl/posting/755155/Fout+tijdens+het+verbinden
[2] https://arxiv.org/abs/1912.04669 (Abstract; PDF kun je daar downloaden).

@Erik

1) Die kans is heel klein als je verkeer zonder VPN tunnel blockt m.u.v. het DHCP verkeer omdat er anders geen verbinding met het WIfi accesspoint tot stand kan komen. De meeste tunnel applicaties hebben dat ingebouwd.
OpenVPN noemt dat "Seamless Tunnel"

2) Geen verkeer toestaan zonder VPN tunnel via een onbekend access point, dat is nogal simpel.

3) Moet ik induiken om dat te lezen, even niet nu.

4) Ja, mits je de settings van je App (daar zal het meestal op uitdraaien) goed hebt staan. Ik heb meerdere VPN tunnel applicaties bekeken, bij allemaal kan je je verkeer automatisch blokkeren als de tunnel niet actief is of wegvalt.

Een voorbeeld:
https://openvpn.net/faq/how-can-i-ensure-that-the-vpn-stays-continuously-connected/

HTTPS biedt geen volledige garantie dat je privacy bij WiFi wordt beschermd.
Waarom niet?
Omdat je computer (incl. tablet, smartfoon e.d.) voor een deel "een eigen leven leidt" namelijk vanwege de firmware
die vast in het apparaat is geprogrammeerd, precies zoals de fabrikant van het apparaat het heeft gewild.

Maar als bijv. een fabrikant of overheid invloed uitoefent en zou willen dat er een mogelijkheid moet worden ingebouwd
om bepaalde zaken van het apparaat af te kunnen luisteren, dan is gratis WiFi voor hen ideaal.
Internet kun je nog flteren met een firewall, en met Wireshark kun je al het dataverkeer langs zien komen, omdat het verkeer allemaal via hetzelfde kabeltje gaat.
Het hoeft niet per se te gebeuren dat op die manier stiekem data lekt, maar dankzij WiFi kan je het niet garanderen,
of je moet je ergens bevinden waar alle gratis wifi-mogelijkheden ver genoeg buiten het bereik van je computer liggen.

In de praktijk is er echter haast altijd wel een gratis WiFi punt in de buurt waar je computer mee kan communiceren.
En dan kan jij wel instellen dat alle verkeer via jouw WiFi-router moet lopen, maar gebeurt dit dan ook alleen maar?... Want zonder dat je het weet kan zo'n tablet of smartphone op eigen houtje ook best even via een andere beschikbaar (gratis) wifipunt communiceren, zonder dat jij dit in de gaten hebt.

Bijvoorbeeld dankzij gratis wifipunten kan Google jouw locatie beter bepalen. Locatiebepaling kun je uit zetten, maar dan vertrouw je op het besturingssysteem van het apparaat. Als locatiebepaling "uit" staat verwacht of hoop je dat dit ook werkelijk zo is. Maar je kan niet gemakkelijk even controleren, of er op de achtergrond af en toe stiekem toch even via een gratis WiFipunt met Google wordt gecommuniceerd waar je uithangt.

Nu zou dit meestal niet direct het allerergste zijn, maar stel het gaat om een vertrouwellijke https verbinding.
Ergens via je browser komt unencrypted data op je scherm. Dit staat dus keurig ergens unencrypted in het videogeheugen van je apparaat. En weet jij veel of de fabrikant dat in zijn firmware goed heeft beveiligd of niet?
Of dat een tussenpersoon met veel know how dit heeft weten aan te passen in de firmware?

Stel dat het niet goed is beveiligd. Dan is er dus alleen maar een malicious routine nodig die op de achtergrond draait om de inhoud van het video-geheugen ongemerkt via een gratis Wifi-punt in de buurt door te seinen naar China town of Silicon City, En daar merk jij op dat ogenblik helemaal niets van. Want jij denkt dat er alleen maar verkeer heen en weer gaat naar je home-WiFi router, want dat had je toch ingesteld? Ja, dat had je ingesteld. Maar als de besturing van je apparaat niet deugt of er zelfs opzettelijk dingen op de achtergond gebeuren waar je nooit om had gevraagd, dan doe je daar niets aan.

En dát vind ik dus de pest van WiFi en van die gratis WiFi punten. (en dus de pest van tablets en smartfoons
die normaal altijd met WiFi moeten werken, zodat WiFi dus standaard aanwezig is op je apparaat.

Ik herhaal uit https://security.nl/posting/773926 van eerder deze maand:

Uit https://www.darkreading.com/remote-workforce/unencrypted-traffic-weak-e-mail-passwords-still-undermining-wifi-security:
Nb. het gaat hier om bezoekers van een conferentie over informatiebeveiliging...

Meer info: https://blogs.cisco.com/security/rsa-conference-2022-security-operations-center-findings-report (met verwijzing naar pdf-rapport).

Absurd dat er kennelijk nog steeds (mail-) servers zijn die authenticatie via afluisterbare of te AitM'en (Attacker in the Middle) verbindingen accepteren.

Goed verhaal, echter, in bijv. div. ziekenhuizen is VPN geblokkeerd omdat men zegt dan geen controle meer te hebben wat er op hun netwrtk gebeurd.

Draai je vpn server op 80, 443 of 53 etc
Heb je al een server aanwezig op een van die poorten gebruiken dan bv openvpn met port sharing.
https://www.vpntutorials.com/tutorials/openvpn-sharing-a-port-with-a-webserver-on-port-80-443/