Consultatie voor gebruik WPA2 Enterprise bij publieke overheidsnetwerken begint

De overheid start donderdag een internetconsultatie over het verplichten van de WPA2 Enterprise-standaard op openbare overheidsnetwerken. Het Forum Standaardisatie raadde dat aan in een advies.

Het gaat om publieke wifinetwerken die bij overheidsinstellingen worden aangeboden, zoals gastnetwerken bij Rijksoverheidsinstellingen, provincies, gemeenten en waterschappen, en netwerken bij publieke instellingen.

Het ministerie van Binnenlandse Zaken begint donderdag een internetconsultatie waarin het input vraagt over het verplicht stellen van WPA2 Enterprise als standaardbeveiliging voor dergelijke netwerken. Daar moet een 'pas-toe-of-leg-uit'-beleid voor gaan gelden. Het Forum Standaardisatie raadt dat aan in een rapport.

Op dit moment wordt WPA2 Enterprise al toegepast bij de overheid als de standaard netwerkbeveiliging, maar er geldt een uitzonderingspositie voor 'openbare netwerken voor gastgebruik'. In het expertadvies zegt het Forum Standaardisatie dat een pas-toe-of-leg-uitbeleid 'veilig gebruik van digitale dienstverlening bevordert, een veilige samenwerking met niet-overheidsmedewerkers stimuleert en de faciliteiten die de overheid biedt, beter beveiligt'.

Het Forum benadrukt dat de nieuwe regels niet bedoeld zijn om het aanbieden van een gastnetwerk te verplichten. "Wanneer een wifinetwerk echter wordt aangeboden, moet deze standaard toegepast worden", schrijft de instantie. Betrokken partijen en geïnteresseerden hebben tot 4 november om te reageren op de consultatie.

Eerder dit jaar zei het commerciële Publicroam al dat een groot deel van de Nederlandse gemeenten onveilige wifigastnetwerken aanbood. Dat deed het nadat het Forum Standaardisatie in gesprek was gegaan met Publicroam voor een onderzoek naar het gebruik van WPA2 Enterprise bij de overheid.

Door Tijs Hofmans

Nieuwscoördinator

08-10-2020 • 10:28

91

Submitter: dwizzy

Reacties (91)

91
87
39
3
0
45
Wijzig sortering
Ik zie hier een hoop reacties, maar wil je invloed uitoefenen dan zal je moeten reageren via https://www.internetconsultatie.nl/wpa2enterprise -- iedere burger kan hier reageren, je moet alleen naam en e-mailadres opgeven, geen DigiD ofzo.
Iedereen duikt ook meteen de techniek in, zie ik, en daar moet ik best wel om glimlachen.

Het gaat misschien niet eens om de techniek, maar om de regelgeving omtrend aanbieden van een "gasten-WiFi" en verantwoordelijkheid wat daar dan vervolgens mee gedaan wordt.

Trouwens nog niet echt veel reacties daar ;)

[Reactie gewijzigd door Raymond Deen op 23 juli 2024 00:29]

Wij gebruiken zelf ook WPA2 Enterprise en 802.1X voor ons bedrijfsnetwerk.

Maar we hebben ook een gasten netwerk, dat in een afgezonderde VLAN zit, waarop enkel internet beschikbaar is.Dat dient voor gasten die bv. bij ons op bezoek zijn en een dag bij ons moeten werken (bv. consultants, belastingsinspecteurs, gsm's, etc). Daarop zijn dingen zoals torrent geblokkeerd, zit een antivirus profiel op en sites zoals botnets zijn geblokkeerd.

Uit de tekst begrijp ik dat de overheid nu wel WPA2 Enterprise voor hun bedrijfsnetwerken gebruikt, en het in de toekomst ook aangeraden wordt, maar niet verplicht, om WPA2 op een gastnetwerk te gebruiken, of lees ik dat verkeerd? Kan iemand me verduidelijken wat de bedoeling is? Met WPA2 Enterprise kan je juist geen paswoorden gebruiken maar moet de gebruiker gekend zijn in de Radius server. En dat is net wat je met gasten niet wil. Iets waar ik zelf wel over nadenk is roterende paswoorden (bv. per dag), maar het WPA2 Enterprise ipv WPA Personal verhaal voor gasten netwerken begrijp ik niet goed.
Als ik bij de gemeente een nummertje trek moet ik tegenwoordig mijn geboortedatum invullen. Vervolgens weet de kiosk precies wie ik ben en waar ik voor kom. Dat is dus aardig geïntegreerd met het afsprakensysteem. Het vervolgens aanmaken van een tijdelijke gebruiker in een Radius server en deze op datzelfde bonnetje printen is nauwelijks extra moeite.

Ook op minder formele plekken vind je dergelijke integraties. Zo zijn er horeca gelegenheden waar je een pincode/barcode voor het toilet op je bonnetje geprint krijgt. Of waar je bij de kassa gratis een uitrijkaart krijgt. In feite allemaal systemen die klantgebonden (en tijdelijke) authenticatie gegevens genereren en uitgeven. Een tijdelijke Wi-Fi gebruiker aanmaken is niet (veel) ingewikkelder.
Met WPA2 Enterprise kan je juist geen paswoorden gebruiken maar moet de gebruiker gekend zijn in de Radius server. En dat is net wat je met gasten niet wil.
WPA2 Enterprise kan je dankzij RADIUS tegen alles aan implementeren, ook tegen een gastendatabase. Met een goede configuratie hoeft de gebruiker enkel een (tijdelijke) gebruikersnaam en wachtwoord op te geven.

Dan nog zie ik het nut van zoiets niet echt. Je kan net zo goed een gastennetwerk WPA2-PSK (voor de (initiële) encryptie) laten gebruiken en daarachter alsnog een captive portal.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 00:30]

Er moet dus een account geregistreerd zijn, anders kun je niet op het netwerk. Echt "openbaar" is het dus niet meer, en je wordt gelijk weer in een database gezet.
Er moet dus een account geregistreerd zijn, anders kun je niet op het netwerk.
Jij denkt te veel vanuit het klassieke AD/LDAP perspectief.

Bij het verstrekken van wifi gegevens kan meteen op dat moment een anoniem 'account' (combinatie gebruikersnaam en wachtwoord in een gastendatabase) gemaakt worden. Je kan dit ook van te voren voobereiden en de combinaties van (anonieme) gebruikersnamen en wachtwoorden op papiertjes uitgeven, hetzelfde als dat je zou doen voor eenmalig te gebruiken wachtwoorden voor enkel captive portals.

Een 'geregistreerd' account hoeft niets anders te zijn dan een combinatie van een anonieme gebruikersnaam en wachtwoord in een database, die enkel maar geldig zijn voor een bepaalde periode. Je hebt niet eens LDAP daarvoor nodig. Het zou zelfs (bij wijze van spreke) in een flat-file database kunnen doen, hoewel ik voor een mini-implementatie het waarschijnlijk met SQLite zou doen. net naar wat de eisen zijn.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 00:30]

Maar als je dat gaat doen, waarom dan niet een standaard WPA-PSK met captive portal? Dit is heel veel moeite voor iets wat super omslachtig in gebruik is en alleen goed werkt als je hier nog aangepaste scripting voor hebt. Dus iets met een website waar je je aan kunt melden (al dan niet anoniem).
Omdat de PSK de sleutel is om al het wifi verkeer te ontsleutelen, er is hier geen versleuteling per sessie maar een sleutel voor alle sessies.
Dat snap ik, maar is dat erg? Met asymmetrische versleuteling is dat helemaal prima. Het halve internet draait daar op. Daarnaast heb je nog meerdere lagen aan versleuteling erbovenop (SSL, misschien nog VPN tunnel als je het hebt).

Het grootste probleem is dat jij relay gaat zitten spelen als MITM

Probleem is alleen dat als het omslachtig werkt je alsnog dingen als account sharing gaat krijgen omdat gebruikers zoiets hebben van joh zoek het uit zolang het maar werkt. Het moet simpel zijn om te kunnen gebruiken anders ga je alsnog alles met 1 of hoogstens een paar sleutels krijgen
Je moet je hier realiseren dat niet alle gebruikers van wifi netwerken IT experts zijn.

Jij zult een afweging kunnen maken, maar het doel zou dan ook implicite beveiliging waardoor je als gebruiker beschermd bent ook als je niet ter zake deskundig bent.

En laten voorop stellen dat als personen zich bewust niet aan afspraken houden zij ook zelf verantwoordelijk zijn voor de consequenties van hun acties. Uiteraard kan men mogelijk systemen misbruiken, maar daar vind een wetgever ten aanzien van de beoogde doelstelling wel terdege iets van omdat de doelstelling van de maatregelen die je buiten spel probeert te zetten over het algemeen heel duidelijk zijn.
Je moet je hier realiseren dat niet alle gebruikers van wifi netwerken IT experts zijn.
Dat is exact mijn punt. Je moet vanuit de consultatie dan ook direct goede eisen stellen aan de usability bij implementatie anders gaat het geheid fout doordat de persoon die de boel zou moeten inboeken (receptie), maar gewoon dezelfde code aan iedereen geeft. kan zij er wat aan doen dat het weer niet werkt, of dat de nieuweling de training nog niet gehad heeft, of ...


Mijn punt is dat de persoon die het gaat gebruiken absoluut geen IT expert is. Dit gaat dus alleen goed werken als het voor de verstrekker ontzettend simpel is om gasten aan te melden (van buitenaf). Dat wordt vaak overgeslagen helaas.
Dat ben ik met je eens, het zou echter op dit stadium nog geen doorslaggevend argument moeten zijn.

Laten we als eerste eens nagaan of we betere impliciete veiligheid achten nodig te zijn, en daar ben ik het fundamenteel mee eens.

De methode die hier voorgesteld word is een beetje een "wij van wc eend" methode en daar heb ik net zoals jij nogal wat twijfels bij.

Dus in mijn beleving is het doel duidelijk maar de methode waarop zou nog ter discussie moeten staan, gezien men daarop voorstelt om naar WPA-2 Enterprise te gaan waar er ook terdege andere methoden bestaan die dan in het onderzoek maar even overgeslagen worden.

Het is in mijn beleving geen onafhankelijk onderzoek wat ook blijkt uit het feit dat de onderzoekende partij alleen zijn eigen dienst en gebruikte techniek als oplossing stelt.

[Reactie gewijzigd door mash_man02 op 23 juli 2024 00:29]

omdat je in beginsel die trafic met dat login id wel kunt loggen en kunt achterhalen wat er met dat specifieke gast-account is gebeurd, kortom je zou achteraf (door een forensisch expert kunnen laten achterhalen welk temp-account bij welke gast (persoon) hoort. Dit kost echter wel behoorlijk wat resources en tijd.

je moet dan op zijn minst. A weten wanneer het feit gebeurd is, waneer dat account actief is geworden en dan op de gastenlijst kijken wie er om hoe laat het gebouw in is gekomen en zelfs dan ... loop je nog kans dat je meerdere personen moet gaan natrekken om uit te zoeken wie het uiteindelijk was. zoiets biedt denk ik genoeg waarborgen om massa-surveillance tegen te gaan, maar maakt het ook niet geheel onmogelijk om misbruik op te sporen.
zoiets biedt denk ik genoeg waarborgen om massa-surveillance tegen te gaan
Nee juist niet, want je gaat nu direct voor iedere gast die is aangemeld bij de receptie een account maken, omdat het anders heeeel omslachtig is de boel te matchen.

Juist door direct bij de deur iedereen te voorzien van een informatiekaart met oa wifi gegevens heb je als bedrijf gewoon een hele goede manier om gebruikers te tracken. De belastingdienst doet dat bijvoorbeeld ook. Als je daar naar een talk of dev sessie gaat, krijg je op papier (A4tje) een login voor jou specifiek (gebruikersnaam en password) inclusief een tijd waarin de code bruikbaar is. massa tracking is dan heel eenvoudig, want ieder request kan aan een gebruiker gelinkt worden.
Bor Coördinator Frontpage Admins / FP Powermod @The Zep Man8 oktober 2020 12:49
Bij het verstrekken van wifi gegevens kan meteen op dat moment een anoniem 'account' (combinatie gebruikersnaam en wachtwoord in een gastendatabase) gemaakt worden.
In hoeverre is zo'n account daadwerkelijk anoniem en hoeverre is verwerking hiervan toegestaan? Een unieke gebruikersnaam is bv een persoonsgegeven onder de AVG afaik.
Klopt werkt perfect hebben wij ook voor onze gasten, zo word er dus ook altijd een verantwoordelijke aan de bezoeker gekoppeld.
Maar nu heb je het over een gastnetwerk bij een bedrijf, imo wat anders dan een openbaar netwerk bij een gemeente.
imo wat anders dan een openbaar netwerk bij een gemeente.
Een openbaar netwerk is anders dan een publiek ('public') netwerk. Verder kan de gemeente gewoon eisen stellen aan het gebruik van het netwerk (bijvoorbeeld: papiertje ophalen van de balie met daarop een gebruikersnaam en wachtwoord).

Verder verschillen gastnetwerken bij bedrijven en bij overheden niet veel. Beiden bieden een internetverbinding.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 00:30]

Van ISEC perspectief gewoon ophouden met openbare wifi.
Je kan net zo goed een gastennetwerk WPA2-PSK (voor de (initiële) encryptie)
Alleen is dat dan weer niet veilig. De initiële encryptie wordt opgezet op basis van de gedeelde sleutel, en pas daarna worden over de verbinding nieuwe willekeurige sleutels gecommuniceerd. Als iemand dus het opzetten van de verbinding snifft kan doe ook de rest van het verkeer ontsleutelen. En het sniffen van het opzetten van de verbinding kan weer makkelijk worden bereikt, je kunt gewoon een pakketje de lucht in sturen waardoor alles en iedereen disconnect.

PSK is dus alleen veilig als het wachtwoord niet bekend is. En laat dat nu niet zo zijn bij een gastnetwerk. Dus een gastnetwerk zonder wachtwoord is net zo (on)veilig als met PSK maar dat iedereen het wachtwoord weet.
Het doel is dus net om te voorkomen dat je gewoon een papiertje omhooghangt met: dit is het wachtwoord van vandaag. Men wil dat elke gast op het netwerk gekend is en daarbij dus een unieke login en wachtwoord krijgt. Het doel is dus vooral om te weten wie er op je netwerk zit en bij eventueel misbruik te kunnen nagaan wie daarvoor verantwoordelijk is.
Met WPA2 Enterprise kan je juist geen paswoorden gebruiken maar moet de gebruiker gekend zijn in de Radius server.
De kunst is mensen snel aan radius toe kunnen voegen.
Bij ons kunnen bezoekers dat op verschillende manieren, bv door een SMS bericht te sturen met een wisselende code die zichtbaar is op schermen in onze gebouwen. Dat is vooral voor "onverwachte" bezoekers.

Voor "verwachte" bezoekers kan ons personeel zelf een wifi-gast-account aanvraagen. Dat kan vooraf via een simpel self-service-portal waar ze eigenlijk niet meer hoeven te doen dan het e-mail-adres van de gast in te voeren. De gast krijgt dan een mail met een tijdelijke account, instructies, kant-en-klare configuraties en wat handige linkjes.
Omdat de instelling verantwoordelijk blijft voor het gebruik.
Er zijn vast dingen te bedenken waarin torrents nodig/handig zijn, maar moet dat echt op het wi-fi netwerk van de gemeente?

[Reactie gewijzigd door nexhil op 23 juli 2024 00:30]

Onzin, het verkomt dat er via jouw internet verbinding naar buiten torrents worden geupload/gedownload. Als iemand een vpn gebruikt is dat zijn of haar keuze. Maar dan is de eigenaar van de verbinding zelf niet verandwoordelijk.

Het blokeren is dan een primma middel voor dit risico.
Is dit ook wettelijk zo?

De eigenaar van het wifi-netwerk is verantwoordelijk voor het downloaden / uploaden van de data, ook van de gast-gebruikers. Maar vanaf een gast-gebruiker een VPN gebruikt zou het niet meer zijn verantwoordelijkheid zijn?

Lijkt me vreemd.
Dat komt omdat de opssporing van een dader al 'scheef' begint.
Die gaat van een "ouderwetse" waarde uit het gebruikte IPadres is een vast datapunt ( IP = adres -> heeft eigenaar )
Door te zorgen voor een 'aangepast' adres, lijkt de overtreding ergens anders vandaan te komen.
Dit maakt het niet minder strafbaar, alleen minder makkelijk inzichtelijk.

En de eigenaar van het netwerk is niet diegene die strafbaar is, maar de persoon die het misdrijf pleegft.
Maar dat is wederom 'ouderwets' opgepikt, gebruiker IPadres = eigenaar (verantwoordelijke) IPadres
Ik kan het zelf zo snel niet vinden wat er wettelijk is afgesproken over dit specifiek hier in Nederland.

Illegaal downloaden blijft ook met een VPN illegaal, er is alleen niet te bewijzen dat het verkeer over jouw verbinding is heen gegaan aangezien dit versleuteld is gegaan en op een andere plek in de wereld naar binnen toe is gegaan.
Dan zou je dus de data van de VPN provider moeten gaan opvragen om hier achter te komen en de client volledig moeten gaan loggen in het netwerk, dat is gewoon te veel werk om met elk apparaat te doen in een groot netwerk.
Is dit ook wettelijk zo?

De eigenaar van het wifi-netwerk is verantwoordelijk voor het downloaden / uploaden van de data, ook van de gast-gebruikers. Maar vanaf een gast-gebruiker een VPN gebruikt zou het niet meer zijn verantwoordelijkheid zijn?

Lijkt me vreemd.
een vpn is in weze een 'eigen' verbinding tussen de client en en de toegangsserver. dus ja als ik via het netwerk van de gemeente een torrent verstuur via hidemyass dan is niet de beheerder van de wifi AP verantwoordelijk maar de eigenaar van de pc waarop de vpn client draait (of omdat dat praktischer is, de persoon die eigenaar is van het VPN-account, wat op zijn beurt weer kan worden vertaald als de persoon met wiens bankrekening voor dat vpn account is betaald, voorzover die gegevens niet zijn gestolen)
Bor Coördinator Frontpage Admins / FP Powermod @Single Core8 oktober 2020 12:51
Ik kan een VPN gebruiken en toch gewoon gaan "torrenten"
- Ik kan een seedbox gebruiken en de files rechtstreeks van de server afhalen
- Er zijn veel andere opties om te gaan downloaden, waaronder ook nieuwsgroepen (NZB...)
Afhankelijk van hoe het netwerk ingericht is kan je meer of minder. Daarbij gaat het natuurlijk om acceptable use. Wanneer je bv op een bedrijfsnetwerk bovengenoemde zaken niet mag en toch doet kan je een stevig gesprek verwachten en bij herhaling erger.
Bor Coördinator Frontpage Admins / FP Powermod @Single Core8 oktober 2020 13:20
Het loopt direct uit de hand kan ik je vertellen. Denk aan verspilling van bandbreedte, imagoschade door bijvoorbeeld het uploaden of plaatsen van ongewenste content en andere onwenselijke gevolgen. Wat heeft het toelaten voor voordeel?
Kunnen ze niet beter meteen wet en regelgeving maken voor WPA-3? Bij de tijd dat de hele transitie en implementatie van WPA-2 is afgerond, is het al achterhaald.
WPA2 is nog steeds veilig, zit in alle bestaande apparatuur en werkt met bijna ieder apparaat met een scherm. WPA3 is nog relatief nieuw en ik betwijfel of er een gratis software-update is die Cisco en andere enterprise-leveranciers aan alle bestaande access points kunnen leveren.

Aangezien het nu al verplicht is bij bestaande netwerken (behalve voor het gastnetwerk) vind ik het alleen maar goed dat men probeert WPA2 enterprise probeert af te dwingen. Ik ken genoeg bedrijven waar men ervoor kiest om gewoon met hun telefoon op het gastnetwerk te gaan zitten en daarop alsnog de gevoelige mails en gegevens binnen te halen, want voor het bedrijfsnetwerk moet je meer dan één veld overnemen van de mail en dan snappen veel mensen het al niet meer. Wij op Tweakers krijgen WPA Enterprise nog wel werkend op onze telefoons, maar als je naar onderwijsinstelling met Eduroam gaat merk je dat er toch best veel mensen die knap in de bol zijn, moeite hebben met inloggen op een Enterprise-netwerk.
Veilig is een relatief begrip. In de scope dat data misschien niet of erg lastig onderschept kan worden (DLP) (afhankelijk van de gebruikte hardware/config) is WPA2 nog steeds erg vatbaar voor Deauthentication/Disassociation attacks.
Met een ESP8266 van onder de €2 op AliExpress kan een heel (2.4ghz) netwerk platgelegd worden. Met iets duurdere hardware gaat die vlieger ook op voor 5Ghz.

Productiviteit plat leggen is in veel gevallen ook schadelijk.
https://cybersecuritylabs...iondisassociation-attack/
Deauth is best lastig nu steeds meer clients authenticatie op deauth packets ondersteunen en access points die aanbieden. Ik heb het geprobeerd op mijn eigen netwerk en alleen een tablet uit 2014 kon ik nog makkelijk deauthen. Het zou kunnen zijn dat mijn Fritz!Repeater hier speciaal in is, maar voor zover ik weet is die minder fancy dan de enterprisehardware die bij overheden gebruikt wordt.

Maar goed, als je een deauth attack uit kan voeren, kun je net zo goed een jammer kopen. Werkt op 2.4Ghz, 5.2GHz en alle 3/4G-banden. Is misschien een tientje of twee op AliExpress en heeft dezelfde mogelijkheden (alhoewel deze niet zo gericht kan zijn voor een specifieke aanval). Ja, het bezit ervan is illegaal, maar dat is ook het geval bij een deauthapparaat onder de huidige wetgeving.
Je hebt gelijk, maar er zit wel een nuance in een jammer (specifiek illegaal apparaat kopen) vs een telefoon/laptop/pc/you name it met wifi adapter, waarbij je een aanval kan doen met dezelfde apparatuur wat geschikt is als client voor de betreffende toepassing.
Een ESP8266 is absoluut niet illegaal. Het uitvoeren van de aanval is mogelijk illegaal, maar dat is in principe elke actie om "een netwerk te kraken" al is het met WEP beveiligd. Zo kun je natuurlijk alles relativeren.

deauth is een designfout/zwakte in WPA2 security. Je mag het er niet mee eens zijn maar het het blijft een security issue. Het is niet voor niets aangepakt in WPA3.
Een ESP is zeker niet illegaal, maar een ESP geprogrammeerd om overheidsnetwerken plat te leggen dan weer wel. Een keukenmes is niet illegaal en een bezem ook niet, maar als ik een speer van de twee maak, wordt het ineens een ander verhaal. Een jammer heeft ook gewoon een legaal nut als je het maar in de juiste context gebruikt.

Als je echt de 2.4GHz-band wil platleggen, modificeer je gewoon een magnetron. Je kunt bij draadloze netwerken nu eenmaal geen garanties stellen over de beschikbaarheid.

Ik ben wel blij dat de optionele WPA2-standaard die deauth attacks voorkomt in WPA3 zit, maar ik betwijfel of de kosten van het vervangen van iedere router in elk gemeentehuis en overheidskantoor opwegen tegen de beveiligingsvoordelen die het biedt. Wellicht dat de standaard kan eisen dat nieuw aangeschafte apparatuur WPA3 moet kunnen, maar dat oude opstellingen nog gebruikt kunnen worden.
Eens.
Maargoed het discussiepunt was "WPA2 is nog steeds veilig" wat in mijn ogen niet geheel klopt.

Vanuit financieel oogpunt en compatibilitieit is WPA3 nu onhaalbaar, maar het zou wel een streven moeten zijn.
Eigenlijk klopt het wel. Met die deauth actie heb je nog steeds geen data onderschept, je verstoort de communicatie. Dat de ander zijn verbinding kwijt is en niet terug krijgt is op zich niet onveilig, alleen erg irritant...
Dit kan natuurlijk wel tot een onveilige situatie leiden door een extra WiFi netwerk te starten en de gebruikers proberen te verleiden hier op in te loggen...
Met deze logica hoef je ook niet te beschermen tegen ransomware als je backups hebt. Productiviteit beschermen is vaak net zo belangrijk als DLP en soms nog belangrijker.
Productiviteit beschermen valt ook onder security.
(Web)servers met een (D)DoS vulnerability wordt ook als dusdanig gezien. Deauth valt onder DoS.

[Reactie gewijzigd door Razwer op 23 juli 2024 00:29]

Meestal zit er een sla op dat soort apparatuur dat je beveiligings updates krijgt en features zoals wpa 3
Nou, daar moet ik toch wel even een kanttekening bij plaatsen. Puur cryptografisch zit WPA2-PSK beter in elkaar dan de enige breed ondersteunde manier van WPA2-EAP. De binnenste tunnel is namelijk "versleuteld", als we het nog zo kunnen noemen, met MSCHAPv2. MSCHAPv2 komt nog uit de tijd van Windows 98! Het is dan ook al lang en breed gebroken.

En ja, daaromheen zit TLS, wat natuurlijk ciphertechnisch prima veilig is. Maar het probleem is ook niet de versleuteling zelf, maar de negotiation. https gebruikt ook TLS. En TLS gebruikt een PKI-infrastructuur. Browsers (en gebruikers) zijn vrij alert op https-fouten en er gaat meteen een belletje rinkelen als je een self-signed, verlopen, of non-matching cert gebruikt. Echter, de implementatie van PKI checking op WPA2-gebied bestaat nauwelijks. Je moet vaak een keer op "accept" drukken om het certificaat te accepteren alvorens je met een WPA2-EAP-netwerk verbindt, maar dat moet je ongeacht de vraag of het een geldig cert is of niet. Mensen moeten dus echt altijd het cert open gaan klikken en vanuit externe bron gaan valideren. En dat doet natuurlijk geen hond.

Dit betekent dat het geheel kwetsbaar is voor een "evil twin" attack. Dus als je naar een drukbezochte plaats gaat en je zet daar een rogue AP op met hetzelfde SSID en bam, de met MSCHAPv2-versleutelde wachtwoorden komen binnenstromen. Sommige clients geven nog een waarschuwing dat het certificaat is veranderd, maar bijvoorbeeld Android accepteert te allen tijde zonder prompt gewoon het certificaat. De eerste keer dat je met een SSID connect, maar ook nadat je bent geconnect en het certificaat verandert "ineens". Niks dat erop wijst dat je met een rogue AP bent verbonden.

WPA2-PSK heeft dit probleem niet, omdat de handshake daarvoor 5-wegs is. Er worden geen credentials uitgewisseld. En het geen gebruik maakt van MSCHAPv2.

edit: deze man van Aruba (een Nederlander, zo te horen) kan het veel beter uitleggen dan ik: https://www.youtube.com/watch?v=50fO3j4NgyQ

[Reactie gewijzigd door HarmoniousVibe op 23 juli 2024 00:29]

Echter, de implementatie van PKI checking op WPA2-gebied bestaat nauwelijks. Je moet vaak een keer op "accept" drukken om het certificaat te accepteren alvorens je met een WPA2-EAP-netwerk verbindt, maar dat moet je ongeacht de vraag of het een geldig cert is of niet. Mensen moeten dus echt altijd het cert open gaan klikken en vanuit externe bron gaan valideren. En dat doet natuurlijk geen hond.
Ja, dat is waarom ik zo'n hekel heb aan die interface in Windows. Op Android kun je het domein dat bij het certificaat hoort invoeren; als dit een geldig certificaat is volgens de systeem-PKI, wordt de verbinding tot stand gebracht, anders niet. Hetzelfde geldt voor Linux. Mocht je niet de systeemcertificaten willen gebruiken, kun je een CA-certificaat downloaden/installeren dat je alleen voor dat WiFi-netwerk gebruikt. Als dat een beetje goed beheerd wordt (bedrijfsapparatuur kan een CA-certificaat gepusht krijgen als het goed is) gaat dat ook goed, want dan hoef je je gebruikers niet te vragen dingen te installeren. Het kàn dus wel goed, men lijkt het alleen niet te willen.

De overheid kan via GOVROAM gewoon een normaal certificaat gebruiken en zolang mensen maar het goede domein invullen is alles veilig... behalve op platformen als Windows waar de beveiliging prut is. Desondanks is het net zo goed als PSK, aangezien je net zo makkelijk een netwerk met WEP kunt maken, mensen kan laten proberen te verbinden en op basis van die gepoogde handshake de key achterhalen. Mensen snappen WEP niet en hebben ook niet door dat er risico's verbonden zitten aan dat soort netwerken, laat staan dat ze letten op welk icoontje er naast een WiFi-netwerk staat.

In principe is EAP/TTLS + MSCHAPv2 (in combinatie!) prima zolang je je certificaat maar op orde hebt en je apparaten/software enigszins competent ontworpen zijn. De kwetsbaarheid zit hem in het gebrek van de interface, niet per se in het protocol.
Nee het is veel eenvoudiger om bestaande wetgeving op details aan te passen dan nieuwe wetgeving te maken. Starten met WPA-2 met een breed draagvlak gaat meer effect opleveren dan WPA-3 verplichten met allerlei, al dan niet terechte, bezwaren (kosten).
Mogelijk omschrijven ze het op een manier dat het niet gebonden is aan WPA2.

Waar ze eerder wetgeving voor zouden moeten maken is dat er op tijd geupgrade wordt, en niet pas wanneer de technical debt zoveel groter is als de originele vervangingskosten.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 00:30]

Dat is niet hoe de pas-toe-of-leg-uit lijst werkt. Die kun je alleen updaten met standaarden die daadwerkelijk geratificeerd zijn en dus ook echt bruikbaar.

WPA3 komt dus op de lijst zodra de standaard klaar is en daadwerkelijk geïmplementeerd kan worden.

Daar moet je dus ook ondersteunende vendors voor hebben.
Nee, daarmee zou je namelijk heel veel devices op dit stadium uitsluiten die geen WPA3 hebben en ook niet meer gaan krijgen, je zou denken dat een Intel 8xxx series wlan interface met zijn wifi AC (wave 2) een moderne kaart is, maar hiervan is al gesteld dat er geen WAP3 ondersteuning komt.
In hoeverre houdt men hiermee rekening met MitM van publieke accesspoints? Als je een 'veilige' login hebt, maar iemand vangt die op door een accesspoint met dezelfde naam op te zetten, dan heeft die login meteen geen waarde meer. Je hebt uiteraard wel certificaten, maar mijn ervaring is dat mensen die de eerste keer zelf moeten accepteren (op basis van de signature).

Of zijn er inmiddels betere methodes om dit echt dicht te zetten?
Dat is niet waar, aannemende dat je je instellingen goed instelt. Met ouderwetse authenticatiemethoden heb je gelijk, maar tegenwoordig is er in protocollen als TTLS een validatie op domeinnaam of certificaat. Als je geen geldig certificaat van de (bedrijfs)certificaatautoriteit hebt dat met het domein van de authenticatie matcht, krijg je ook geen verbinding. Aangezien ze bij de overheid een eigen root-certificaatautoriteit hebben, neem ik aan dat je uiteindelijk gewoon "rijksoverheid.nl" invult in het domeinveld zonder een intern CA-certificaat te installeren.

Dit moet je wel inschakelen natuurlijk, want omdat bedrijven incompetent zijn is die optie toegevoegd. Het is echter niet meer zodat je een plain text authenticatie kan doen door een simpele MitM als je netwerk correct is ingesteld.

Ik weet dat dit werkt vanwege het bestaan van Eduroam, het netwerkauthenticatiesysteem voor hogescholen en universiteiten in Europa. Nu zijn er tal universiteiten die in hun handleiding domme dingen aanraden (zoals verificatie uitzetten, handmatig via een ander netwerk een CA-certificaat authenticeren en dat dan over HTTP serveren, etc.) maar dat weerhoudt de overheid er niet van om het gewoon goed te doen.

Ik neem aan dat bij het uitvoeren van zoiets het NCSC de instellingen en basishandleiding nog een keer nakijkt waarna het probleem nagenoeg is opgelost.

Edit: die aanname is blijkbaar verkeerd want bij de eerste handleiding die ik vind als ik zoek op "govroam inloggen" krijg ik meteen al een handleiding die EAP + PEAP + "Selecteer bij CA-certificaat 'Niet valideren'" aangeeft. Dat is veilig omdat "er wordt ingelogd op een portal" dat dan weer veilig is, maar het is natuurlijk een fluitje van een cent om die na te maken. Wat is de overheid toch heerlijk incompetent als het aankomt op dit soort zaken.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 00:30]

TTLS is ook geen heilige graal.
https://www.securew2.com/blog/pitfalls-of-eap-ttls-pap/
If an organization seeks the best in network security, they turn to WPA2-Enterprise with 802.1X authentication. Each time a user connects to the network, their credentials are susceptible to over-the-air credential theft, so it’s vital that the process is rigidly protected. But authentication methods are not created equal, and some are more secure than others. Networks operating with a EAP-TTLS/PAP authentication method draw attention to themselves as targets for hackers because of the flawed systems under which EAP-TTLS/PAP operates. Many believe that EAP-TTLS/PAP should be avoided because glaring flaws exist in how it operates and newer authentication methods fill the security holes it leaves open.
Klopt, TTLS los is geen heilige graal maar met de juiste secundaire authenticatie is het wel weer veilig. Ik wilde alleen maar zeggen dat de oude standaarden waarmee je met tien seconden werk de credentials kan onderscheppen niet meer de dienst uitmaken als het aankomt op enterprise wifi: zelfs TTLS kan veilig worden uitgevoerd, en dat is al een redelijk achterhaalde standaard.
Daar zou je dan ook Chap moeten gebruiken. Een beetje radius server gebruikt standaard geen PAP.

https://en.wikipedia.org/...d_Authentication_Protocol

[Reactie gewijzigd door mash_man02 op 23 juli 2024 00:29]

Klopt. Helaas zit niet overal CHAP ondersteuning op. Vaak is het PAP of MS-CHAPv2. LDAP (niet Microsoft) lust vaak weer geen MS-CHAPv2.
CHAP is geen EAP methode. MS-CHAPv2 wel.

[Reactie gewijzigd door Razwer op 23 juli 2024 00:29]

In dat geval is geen access voor devices die geen MS-CHAPv2 ondersteunen toch ook een valide uitgangspunt.

Met devices van een organisatie zou dat bij de inkoop voorwaarden van wifi devices opgenomen moeten zijn.

Voor de gast devices geld dan dat je aan de veiligheids eisen van de aanbieder van het gastnetwerk moet voldoen. Lieven geen toegang dan onveilige toegang.

Ik durf wel te stellen dat 99% van de guest devices MS-CHAPv2 wel ondersteund.

WIndows / Apple / Android / Linux

En diegene die met zijn camera uit 1993 het gasten netwerk op wil heeft gewoon pech.

[Reactie gewijzigd door mash_man02 op 23 juli 2024 00:29]

Niet iedereen is Microsoft fanaat en niet iedereen wil hun technologie in huis.
niet iedereen wil niet commercieel ondersteunde producten op zijn gasten netwerk :-)

Ook daar zitten mogelijke security risico's aan.

[Reactie gewijzigd door mash_man02 op 23 juli 2024 00:29]

Het klinkt misschien gek met de halve wereld op Azure en Windows, maar er zijn ook andere commerciele bedrijven met oplossingen dan Microsoft alleen :)
Een goed voorbeeld (helaas nog weinig voorkomend meer) is een Domino directory, wat dus geen MS-CHAPv2 ondersteund. IBM is geen filantropische instelling en geen opensource toko :)

[Reactie gewijzigd door Razwer op 23 juli 2024 00:29]

Maar dat stel ik toch ? Apple / Microsoft / Android / Linux, ze hebben allemaal ondersteuning voor MS-CHAPv2.

Misschien moet je dan wat concreter worden en een voorbeeld geven van een device wat we mee zouden kunnen nemen om bij de overheid als gast device te gebruiken en geen ondersteuning voor MS-CHAPv2 heeft.
Exact, het vervelende van deze methodes is dat het prima kan werken, mits iedereen zich netjes aan de regels houdt. Zolang de combinatie gebruikersnaam/wachtwoord uniek is, kan het in de praktijk weinig kwaad. Maar als je dezelfde login gegevens van WPA2 Enterprise ook voor andere doelen gebruikt, dan wordt het lastig. Bijvoorbeeld een WPA2 Enterprise die een validatie op AD niveau doet, zonder 2-factor authenticatie, kan dan in de praktijk je AD wachtwoord bloot leggen. Althans, dat is hoe ik het ooit begrepen heb als die certificaat validatie niet klopt.
Client authentication certificates (private key) is wat anders dan een root (public key) van een proxy.
Deze certificaten zullen van andere bron moeten komen dan via de AP. Helaas is zelfs in IT land PKI een eng iets voor velen en zal hier een waterdicht delivery mechanisme voor moeten komen. Los van het risico van een private key wat "exposed" op een apparaat staat. Vooral op mobiele apparaten is dit een veiligheidsrisico.

[Reactie gewijzigd door Razwer op 23 juli 2024 00:30]

Daarom geef je dus een PKI per device uit, als dezelfde PKI 2x inlogt vanaf verschillende devices kun je deze automatisch blokkeren, want of verkeerd gebruikt door user, of uitgelekt. In beide gevallen wil je de user op het matje hebben om uit te vragen en nogmaals uit te leggen.
Dat is prachtig om credential theft tegen te gaan maar helpt niks tegen het decrypten van het verkeer natuurlijk.
De PKI gebruik je om in te loggen op het versleutelde netwerk, ipv de ssid/key combinatie.... PKI aanmelding die je met zoals dat je bij een SSH sessie in zou loggen (met een PKI). En bij WPA2-enterprise kun je per sessie een key gebruiken, dus dan heb je ook nog forward secrecy, met TLS verkeer is dat niks bijzonders.

Goed toegepast kunnen ze 1 sessie, of een deel daarvan als je time-based-key-rotation toepast, decrypten.
Dan helpt het tegen credential theft en decryption.
Ik denk dat er tegenwoordig steeds meer gewerkt wordt met een 2FA in plaats van een client certificate. Een client certificate heeft vooral zin als de machines in eigen beheer zijn en je dus een veilig transport van de key kunt garanderen. In het verleden heb ik nog wel eens meegemaakt dat ik van een IT beheerder een mailtje met de sleutel kreeg. Leuk natuurlijk, maar vaak blijft die key dan weer ergens in een download folder staan.
Daarnaast kun je een replay aanval uitvallen op WPA2-PSK wanneer je het wachtwoord hebt (en dat heb je op een publiek netwerk). Dat kan zelfs met terugwerkende kracht. Absoluut onbetrouwbaar. Zelfs het feit dat apparaten op hetzelfde netwerk zitten kan al gevaarlijk zijn omdat die apparaten doorgaans achter NAT zitten. En uiteraard wil je gasten op een apart VLAN hebben, liefst galvanisch gescheiden.

[Reactie gewijzigd door Jerie op 23 juli 2024 00:29]

Volgens mij moet eerst duidelijk zijn ...wat verstaan we onder een gast.

Gemeentehuis:
1. Gast die een paspoort komt ophalen
2. Een ICT consultant die een implementatie van een ICT oplossing komt doen.

Van nr2. snap ik dat je afdwingt dat het veilig etc. moet.
van nr1. zal het langzaam een onbetaalbare oplossing worden (ambtenaar die bonnetjes moet uitdelen, diverse security maatregelen invoeren,etc...) Dan gaan overheidsinstanties toch langzaam denken, laat een gasten WiFi maar zitten, iedereen heeft toch een 4/5G abon.
In de Eerste Kamer hebben ze voor dit doel Private Pre Shared Key van Aerohive (tegenwoordig extreme networks). Ieder bezoeker een unieke code en geen gezeur met certificaten. Is gewoon op basis van WPA2-PSK,. maar op basis van de PSK wordt uniek beleid per verbinding mogelijk. Codes zijn te krijgen op een zuil van ppsk-kiosk welke je met een QR code kan scannen. Zit patent op, dus helaas niet beschikbaar bij andere merken..
Prima oplossing totdat WPA3 gemeengoed is, duurt niet lang meer. Veel AP's van de grote zakelijke merken hebben al support.
Het zal me vast ontgaan, maar wat voor zin heeft het een openbaar publiek netwerk te beveiligen?
Een stukje opvoeding van de gemiddelde gebruiker die overal en altijd zijn gegevens achterlaat zonder na te denken als ze maar kunnen faceboeken. De overheid heeft allerlei campagnes om openbare wifi accespoints te mijden mits de beveiliging in orde is en dan kun je zelf natuurlijk geen onbeveiligd netwerk aanbieden.
Vooral omdat er een critieke ontwerpfout zit in WPA 2

Het huidige beveiligingsprotocol (WPA-2) bestaat eindelijk uit twee onderdelen
- Toegang beheer. Alleen de juiste mensen mogen op het netwerk
- Signaal beveiliging. Alle wifi communicatie moet beveiligd zijn

Bij WPA2 zijn deze twee helaas aan elkaar gekoppeld. Je moet jezelf aanmelden met een wachtwoord (#1), want anders dan kun je geen beveiligde verbinding (#2) opzetten.

Als jij een horeca gelegenheid (of stadhuis wachtruimte) hebt kun je twee dingen doen: Of je maakt een openbaar netwerk aan, waarmee iedereen onbeveiligd gecommuniceerd, of je hangt een poster op met een algemeen wachtwoord: KoffieCorner2020 of zo iets generieks. Ik adviseer optie twee, omdat je als horeca tent de maatschappelijke verwachting hebt om enige veiligheid te bieden aan bezoekers. Je wilt niet dat mensen worden opgelicht terwijl ze bij jou koffie drinken. Slechte marketing.

Zover ik deze wetgeving begrijp, willen ze dit dus nu ook formeel vastleggen voor publieke overheidsnetwerken.
In reactie op reacties op mijn eerste reactie - ik snap het nog steeds niet. Wat heeft het voor nut om Wifi te beveiligen in een openbare publieke ruimte, want daar gaat het om. Prachtig dat het wifi-signaal is versleuteld, maar als bijvoorbeeld achter het access point een 'man-in-the-middle' zit, dan heb je daar niet veel aan, lijkt me. Het lijkt me slimmer om mensen op het hart te drukken dat openbare netwerken per definitie onveilig zijn...
Iedereen kan de communicatie "lezen" en spoofing van ssid's zorgt er ook voor dat devices reconnecten aan het SSID zodra deze in range is.

Boefjes zouden dus een oplossing kunnen bouwen met het zelfde ssid als de gemeente en deze in een koffer voor de ingang positioneren.

Als dat het eerste in range AP zal zijn zullen de clients daar op connecteren. Alle niet applicatief versleutelde data zal daarmee direct leesbaar zijn.

Daarmee is de vraag of je vind dat de overheid dit moet oplossen of dat je vind dat dat de verantwoordelijkheid is voor de bezoeker van het netwerk.
WPA2-Enterprise verreist volgens mij dot1.x en/of gebruikersspecifieke credentials? Dat lijkt me niet praktisch in bv de wachtkamer van 't gemeentehuis? Iets met qr codes doen?

[Reactie gewijzigd door Opperpanter2 op 23 juli 2024 00:30]

In de praktijk heeft dit toch weinig zin?
Ik kom wel eens op plekken waar WPA2 enterprise geïmplementeerd is in het gastnetwerk. Daar krijgt elke gast dan simpelweg dezelfde accountgegevens, schiet je nog niks mee op...
Zelfs al gebruik je dezelfde accountinfo om te authenticeren. (gebruikersnaam en wachtwoord), Dan nog is er een verschil. Bij WPA2-personal gebruikt iedereen dezelfde key om te versleutelen, bij WPA2-enterprise krijg je bij elke sessie een eigen encryptiesleutel. Dus wanneer je wifi uitzet en weer opnieuw connecteert, heb je een nieuwe sleutel, wat afluisteren moeilijker maakt dan bij WPA2-personal
Zelfs al gebruik je dezelfde accountinfo om te authenticeren. (gebruikersnaam en wachtwoord), Dan nog is er een verschil. Bij WPA2-personal gebruikt iedereen dezelfde key om te versleutelen, bij WPA2-enterprise krijg je bij elke sessie een eigen encryptiesleutel. Dus wanneer je wifi uitzet en weer opnieuw connecteert, heb je een nieuwe sleutel, wat afluisteren moeilijker maakt dan bij WPA2-personal
En volgens mij doet enterprise zelfs in de sessie nog rekey’en, wat het nog veel veiliger maakt als er geen brakke crypto is gebruikt.

Op dit item kan niet meer gereageerd worden.