Computerbeveiliging - Hoe je bad guys buiten de deur houdt

HTTPS op public wifi?

31-05-2022, 17:18 door Anoniem, 25 reacties
Hi,

Laatst een discussie met een collega over HTTPS op public wifi. Hoor nog altijd dat je geen public wifi moet gebruiken. Volgens mij complete onzin doordat alles nu over HTTPS gaat.

1. HSTS of zelf https:// intikken zorgt ervoor dat een mogelijke MITM voor een browser warning zorgt (natuurlijk altijd blijven opletten of je echt op HTTPS zit).

2. Het is mogelijk dat iemand ziet dat ik op een bepaalde HTTPS site zit. Maar niet wat ik daar doe. Dus de privacy impact is zeer beperkt.

3. Eventuele updates in de achtergrond gaan (meestal) ook via een versleutelde lijn.

Mis ik iets, of kun je met HTTPS eigenlijk probleemloos public wifi gebruiken?

Zie ook Why Public Wi-Fi is a Lot Safer Than You Think
https://www.eff.org/deeplinks/2020/01/why-public-wi-fi-lot-safer-you-think
Reacties (25)
31-05-2022, 19:41 door Anoniem
Beetje achterhaald allemaal. Tegenwoordig is er OWE.

https://www.networkworld.com/article/3325745/opportunistic-wireless-encryption-um-what-s-that-again.html
31-05-2022, 20:36 door Anoniem
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.
31-05-2022, 22:10 door Erik van Straten
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).
31-05-2022, 22:24 door Anoniem
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).
01-06-2022, 12:07 door Anoniem
Door Anoniem: 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.
01-06-2022, 12:40 door Anoniem
Door Anoniem:
Door Anoniem: 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.
01-06-2022, 13:07 door Anoniem
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.
01-06-2022, 13:40 door Anoniem
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
01-06-2022, 14:25 door Anoniem
Door Anoniem: 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.

Goede aanvulling.
01-06-2022, 15:05 door Anoniem
Door Anoniem:
Door Anoniem: 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.


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?
01-06-2022, 15:57 door Anoniem
Door Anoniem: 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).
Hoe zie je dat voor je, voorkomen dat je op HTTPS uitkomt middels DNS aanpassingen?
01-06-2022, 15:59 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: 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.


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?
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).
01-06-2022, 16:18 door Anoniem
Door Anoniem: 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

evil twin is al zo oud als Wifi en geldt nog steeds.
01-06-2022, 16:21 door Anoniem
Gezien bovenstaande reacties met goede argumenten denk ik dat je collega’s gelijk hebben.
01-06-2022, 22:44 door Erik van Straten
01-06-2022, 12:40 door Anoniem: HSTS helpt om connecties met nep sites te voorkomen maar die gebruiken heel veel sites niet.
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.

01-06-2022, 12:40 door Anoniem: 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".
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.

01-06-2022, 12:40 door Anoniem: En apps hebben geen adres balk waarin dat op zou kunnen vallen.
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.
02-06-2022, 00:23 door Erik van Straten
01-06-2022, 13:40 door Anoniem: 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?
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).
02-06-2022, 08:04 door Anoniem
Door Anoniem:
Door Anoniem: 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).
Hoe zie je dat voor je, voorkomen dat je op HTTPS uitkomt middels DNS aanpassingen?

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.
02-06-2022, 12:54 door Anoniem
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.
02-06-2022, 13:20 door Anoniem
Door Anoniem:
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.
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):


1. HSTS of zelf https:// intikken zorgt ervoor dat een mogelijke MITM voor een browser warning zorgt (natuurlijk altijd blijven opletten of je echt op HTTPS zit).
02-06-2022, 14:53 door Anoniem
Door Anoniem:
Door Anoniem:
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.
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):


1. HSTS of zelf https:// intikken zorgt ervoor dat een mogelijke MITM voor een browser warning zorgt (natuurlijk altijd blijven opletten of je echt op HTTPS zit).


Aanvullen met: check of dit de https site is die je wilde bezoeken.... :)
03-06-2022, 08:34 door Anoniem
Door Anoniem:
Door Anoniem: 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

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

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.......
03-06-2022, 10:28 door Anoniem
Door Anoniem:
Door Anoniem: 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

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

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.
04-06-2022, 14:55 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: 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

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

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.......

En daarom dus, jawel daar is ie weer, een VPN tunnel eroverheen.
05-06-2022, 21:14 door Erik van Straten
Door Anoniem: 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).
06-06-2022, 06:33 door Anoniem
@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/
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.