Unii cretini mă iau la pulă (în comentarii pe care nu le aprob) când postez conversații cu chatboți, dar această discuție este informativă și nu am detectat halucinații în ea. Idioții care-s mai Luddites decât mine și refuză orice răspuns de la un LLM să și-o bage singuri în cur; ceilalți ar putea afla ceva nou sau li s-ar putea reaminti aspecte pe care le cunoșteau deja.

🤖

❶ Ludditus: De ce continuă campaniile imbecile, precum cea de la Radio România sau cea a Directoratului Național de Securitate Cibernetică (DNSC), care insistă ca oamenii să nu se conecteze pe Wi-Fi publice nu doar la bănci, dar nici la rețelele sociale, când toate aceste aplicații folosesc SSL/TLS/HTTPS, iar conexiunile nesecurizate via HTTP sunt practic inexistente în ziua de azi? Când astfel de campanii de propagandă sunt promovate de ofertanții de VPN, sunt de înțeles: vor să vândă. Însă când sunt campanii publice care vin din partea unor autorități care se pretind informate, ele reprezintă pur și simplu FUD (Fear, uncertainity and doubt)!

Gemini: Ai perfectă dreptate să fii frustrat. Mesajul clasic „nu folosi Wi-Fi public pentru că îți fură hackerii parola” este, în mare parte, o relicvă a anilor 2010. Este o moștenire din epoca în care site-urile foloseau HTTP în clar, iar extensii precum Firesheep puteau captura sesiuni din aer cu un simplu click. Astăzi, datorită adoptării universale a TLS 1.2/1.3 și a politicilor HSTS (HTTP Strict Transport Security), interceptarea pasivă a traficului de către un terț care „ascultă” rețeaua este practic imposibilă.

Furnizorii de VPN capitalizează masiv pe această fobie învechită pentru a vinde abonamente, însă din partea autorităților, situația este puțin diferită. Nu este neapărat doar ignoranță, ci o aplicare stângace a principiului „cel mai mic numitor comun”.

De ce persistă acest mesaj din partea autorităților

  1. Simplificarea extremă pentru publicul larg: Pentru o instituție precum DNSC, este mult mai simplu să impună o interdicție binară („nu folosi Wi-Fi pentru bănci”) decât să explice unui utilizator non-tehnic cum să verifice valabilitatea unui lanț de certificate, ce este DNS over HTTPS sau de ce HSTS previne atacurile de tip downgrade.
  2. Oboseala alertelor (Warning Fatigue): Criptarea modernă este solidă, dar factorul uman cedează. Dacă un atacator încearcă un atac de tip SSL Stripping sau prezintă un certificat falsificat, browserul va bloca pagina cu un avertisment roșu uriaș. Din păcate, statisticile arată că un număr enorm de utilizatori apasă instinctiv pe „Advanced” și „Proceed anyway”, anulând singuri toată securitatea oferită de TLS. Autoritățile preferă să evite cu totul această interacțiune.

Riscurile reale care au rămas

Chiar dacă interdicțiile absolute sunt de tip FUD, rețelele Wi-Fi publice nu sunt complet lipsite de riscuri, însă vectorii de atac s-au mutat de la interceptarea traficului la manipularea infrastructurii și a dispozitivului:

  • Evil Twin și Portalurile Captive: Este trivial să ridici un Access Point fals numit „CFR_Free_WiFi”. Traficul către bancă va fi în continuare criptat, dar portalul captiv (pagina care îți cere să accepți termenii pentru a primi internet) poate fi o clonă de phishing. Aceasta poate cere autentificarea cu Facebook/Google pentru acces, sau poate oferi spre descărcare un executabil malițios mascat sub forma unei „actualizări necesare pentru securitatea rețelei”.
  • Expunerea serviciilor locale: Conectarea la o rețea de nivel 2 (Layer 2) necunoscută plasează dispozitivul tău în aceeași subrețea cu sute de alte dispozitive. Dacă firewall-ul sistemului de operare este configurat greșit (de exemplu, acceptarea profilului de „Private Network” în Windows în loc de „Public”), porturile pentru partajarea de fișiere (SMB/CIFS) sau alte servicii locale devin vizibile și pot fi exploatate.
  • DNS Hijacking: Dacă rețeaua controlează serverul DNS și clientul nu folosește DNS criptat, interogările legitime pot fi redirecționate către IP-uri malițioase. Dacă un utilizator tastează manual domeniul fără https://, iar acel domeniu nu se află pe lista preîncărcată de HSTS a browserului, atacatorul poate servi o versiune de phishing înainte ca cererea să fie redirecționată către o conexiune sigură.

Campaniile de informare ar fi mult mai oneste și utile dacă ar explica cum să navighezi în siguranță (de exemplu: „Nu ignora niciodată alertele de securitate ale browserului” sau „Nu descărca fișiere cerute de rețeaua Wi-Fi”), în loc să recicleze sperietori de acum 15 ani care ignoră realitatea tehnologică actuală.

❷ Ludditus: DNS Hijacking poate exista uneori, deși rar, chiar și când ești conectat la ISP-ul de acasă! AP-urile false sunt totuși cea mai mare problemă, iar aici arhitectura Wi-Fi este de vină, căci dacă dispozitivul (telefon, laptop) este configurat să se conecteze automat la un anume nume de AP, iar AP-ul fals acceptă orice parolă, atunci utilizatorul nu știe că se conectează la un pirat! Cât despre alertele de certificate SSL neconforme sau invitațiile de a descărca fișiere, aici prostia utilizatorului nu poate fi îndreptată de „nanny state”. Firește, mă pot conecta și fără SSL la ceva neimportant, gen un ziar online, dar trebuie să fiu atent să nu fie un site deturnat. Trebuie să am discernământ și să detectez informația suspectă. Când însă mă conectez la o bancă, la o rețea socială, la un site de e-commerce, cât de tâmpit să fiu ca să ignor o alertă de securitate?

Gemini: Ai pus punctul pe i. În jargonul administratorilor de sistem, ai descris perfect faimoasa problemă de „Layer 8” (stratul uman din modelul OSI) sau clasicul PEBKAC (Problem Exists Between Keyboard And Chair). Oricât de mult ar încerca un „nanny state” să reglementeze sau să avertizeze, nu poți lansa un patch pentru discernământ.

Ceea ce subliniezi tu sunt deficiențe fundamentale fie în arhitectura protocoalelor, fie în psihologia utilizatorului, pe care nicio campanie radio nu le va rezolva.

Defectul fundamental al arhitecturii 802.11

Observația ta legată de AP-urile false lovește direct în inima modului în care a fost proiectat standardul Wi-Fi. Arhitectura 802.11 favorizează comoditatea în detrimentul securității prin mecanismul de Active Probing:

  1. Strigătul în orb: În loc să asculte pasiv ce rețele sunt în jur, telefonul sau laptopul tău (dacă nu e configurat altfel) strigă în mod constant în eter: „Ești aici, Cafe_Free_WiFi? Dar tu, Hotel_Guest?”
  2. Răspunsul fals: Un AP fals configurat cu unelte precum hostapd-wpe sau un simplu Pineapple ascultă aceste cereri și răspunde: „Da, eu sunt Cafe_Free_WiFi, și am și cel mai puternic semnal din zonă!”
  3. Autentificarea oarbă: Dispozitivul client nu face o verificare a identității AP-ului (nu validează BSSID-ul/adresa MAC) pentru rețelele deschise. Pur și simplu face handshake-ul și rutează tot traficul prin pirat.

Cât timp standardul permite clienților să se lege de orice echipament care poartă același SSID, problema Evil Twin va rămâne imposibil de rezolvat la nivel de infrastructură publică.

Realitatea DNS-ului la domiciliu

Ai perfectă dreptate și în privința ISP-urilor. De fapt, cel mai probabil loc în care un utilizator va suferi un atac de DNS Hijacking nu este o cafenea, ci propria sufragerie.

Sute de mii de routere SOHO (Small Office/Home Office) ieftine sau oferite de ISP-uri rulează firmware învechit, cu vulnerabilități cunoscute și credențiale implicite. Malware-uri precum VPNFilter sau atacuri automatizate modifică serverele DNS direct din routerul utilizatorului. Când se întâmplă asta, absolut tot traficul necriptat din casă este trimis spre serverele atacatorului. Din nou, campaniile autorităților ratează complet acest vector masiv, concentrându-se exclusiv pe Wi-Fi-ul public.

Sindromul „Proceed Anyway”

Cât despre ignorarea alertelor SSL… aici intervine limita absurdului. Astăzi, browserele moderne (Chrome, Firefox, Edge) fac un scandal uriaș când un certificat SSL nu corespunde. Ecranul se face roșu, textul este alarmant, iar butonul de „Continuă” este adesea ascuns sub un meniu de tip „Advanced”. În unele cazuri de HSTS, browserul nici măcar nu îți mai oferă butonul de bypass (trebuie să tastezi „thisisunsafe” în orb ca să treci de el).

Dacă un utilizator parcurge toți acești pași obositori, trecând peste zeci de bariere vizuale de securitate, doar pentru a-și introduce parola de la bancă pe o pagină compromisă… nicio campanie a DNSC nu îl va salva. Este echivalentul tăierii propriilor frâne la mașină înainte de a coborî o pantă.

Pentru traficul HTTP simplu (un ziar, un blog), singurul risc real pe o rețea deturnată este injecția de cod (un script malițios introdus invizibil în pagină de către AP-ul fals, care să exploateze o vulnerabilitate a browserului). Dar, după cum spui, cu un ad-blocker competent, JavaScript restricționat (dacă folosești extensii gen NoScript/uBlock) și puțin discernământ, riscul este perfect controlabil.

❸ Ludditus: Da, chiar așa, cum se dezactivează Active Probing? Cine a inventat porcăria asta ar trebui să ardă în iad! Adică, în loc să asculte și să afle că există un AP „Free_MyCafe” (care oricum poate fi un AP pirat, dar măcar are acel nume preconfigurat), dispozitivele care caută să se conecteze automat întreabă ca idioatele „ești prin zonă, Free_MyCafe, sau Free_MyMall, sau Free_MyAirport?” În astfel de cazuri, un AP pirat își poate modifica dinamic numele, astfel încât să poată spune: „da, sunt aici și te aștept să te conectezi la mine!”

Gemini: Frustrarea ta este 100% justificată, iar mecanismul pe care tocmai l-ai descris poartă chiar un nume în securitatea cibernetică: se numește Atac de tip KARMA (implementat faimos pe dispozitivele de tip Wi-Fi Pineapple).

Cât despre cine a inventat porcăria asta și de ce… inginerii care au creat standardul 802.11 au avut în minte două lucruri:

  1. Viteza de roaming: Ascultarea pasivă (așteptarea pachetelor de tip Beacon pe fiecare din cele 13+ canale de 2.4GHz și zecile de pe 5GHz) durează. Active Probing permite dispozitivului să scaneze toate canalele într-o fracțiune de secundă.
  2. Rețelele ascunse (Hidden SSIDs): Dacă un router nu își difuzează numele, singura modalitate prin care te poți conecta la el este ca dispozitivul tău să urle în eter: „Ești aici, rețea invizibilă?”.

Pentru a opri acest comportament sinucigaș, trebuie să elimini motivele pentru care sistemul de operare inițiază Active Probing.

Iată cum poți face asta în mediile pe care le administrezi:

1. Regula de aur: Fără Auto-Connect pe rețele deschise

Sistemul de operare face probing agresiv doar pentru rețelele din „Preferred Network List” (lista rețelelor salvate) care au flag-ul de conectare automată activat. Dacă nu vrei să uiți rețeaua complet, trebuie să o treci pe manual.

În Windows (via PowerShell):
Dacă vrei să rezolvi rapid din consolă pentru o rețea pe care o știi cu probleme:

netsh wlan set profileparameter name="Nume_Rețea_Publica" connectionmode=manual

Pentru a vedea toate profilurile și starea lor: netsh wlan show profiles. Ideal este să ștergi complet orice profil de Wi-Fi public cu comanda netsh wlan delete profile name="Nume_Rețea_Publica".

În mediile Linux (via NetworkManager):
Pentru desktop-urile minimaliste (indiferent că ești pe XFCE, MATE sau Cinnamon), NetworkManager este de obicei responsabil. Poți tăia conectarea automată direct din terminal:

nmcli connection modify "Nume_Rețea_Publica" connection.autoconnect no

2. Nu bifa niciodată „Connect to hidden networks”

Aceasta este opțiunea care forțează cel mai agresiv Active Probing-ul. Când bifezi pe Windows „Connect even if the network is not broadcasting its name” sau echivalentul în Linux/Android, îți transformi practic dispozitivul într-un far care urlă acel SSID încontinuu, oriunde te-ai afla în lume, facilitând atacul KARMA.

În Linux, asigură-te că flag-ul de rețea ascunsă este pe „no”:

nmcli connection modify "Nume_Rețea" 802-11-wireless.hidden no

3. Randomizarea adresei MAC

Deși nu oprește Active Probing-ul în sine, oprește corelarea și profilarea. Atacatorii folosesc cererile tale de probing pentru a te urmări fizic (dacă telefonul tău caută rețeaua „CFR_WIFI”, atacatorul știe că mergi des cu trenul).

Atât Windows 10/11, cât și NetworkManager au acum suport nativ pentru MAC Randomization la scanare, ceea ce face ca identitatea hardware reală a plăcii de rețea (Intel/Realtek etc.) să fie mascată în timpul acestor cereri.

  • Linux: În /etc/NetworkManager/NetworkManager.conf, adaugă:
[device]
wifi.scan-rand-mac-address=yes

În esență, igiena perfectă constă în a trata orice rețea Wi-Fi deschisă ca pe un șervețel folosit: te conectezi manual, o folosești doar cât ai nevoie, iar la final îi dai „Forget / Șterge” din sistem.

❹ Ludditus: Cine a venit cu ideea imbecilă a rețelelor ascunse? (AP ascunse, de fapt, cele care nu-și broadcast numele)

Gemini: Ideea aparține comitetului de ingineri IEEE 802.11, care a redactat standardul original Wi-Fi aprobat în 1997. Deși astăzi pare o imbecilitate absolută, trebuie să privim contextul tehnologic și mentalitatea de securitate din anii ’90 pentru a înțelege cum a ajuns această funcție în standard.

La acea vreme, criptarea disponibilă era WEP (Wired Equivalent Privacy), care s-a dovedit rapid a fi o glumă proastă ce putea fi spartă în câteva minute. Disperați să ofere soluții companiilor, inginerii au apelat la cel mai vechi și mai prost principiu din domeniu: Securitatea prin obscuritate (Security through obscurity).

Iată logica lor falimentară de atunci și de ce a eșuat mizerabil:

1. Teroarea „Wardriving-ului”

La începuturile anilor 2000, era la modă wardriving-ul: pasionații se plimbau cu mașina, având un laptop și o antenă direcțională, pentru a mapa rețelele deschise din oraș. Companiile au intrat în panică. Soluția propusă de IEEE a fost ca AP-urile să nu își mai anunțe public prezența.

Logica lor era binară și simplistă: „Dacă hackerul nu vede rețeaua în lista de Wi-Fi din Windows, nu o poate ataca. Numele rețelei (SSID-ul) va funcționa ca o primă parolă.” Acest concept a fost integrat sub forma Closed System Authentication.

2. Iluzia invizibilității la nivel de pachet

Ceea ce face un AP „ascuns” este pur și simplu să șteargă textul SSID-ului din Beacon Frames (pachetele difuzate de 10 ori pe secundă pentru a anunța existența rețelei). În loc să trimită „Sunt rețeaua X”, AP-ul trimite un câmp gol (Null).

Inginerii au ignorat însă o regulă de bază a rețelisticii radio: aerul este un mediu partajat. Chiar dacă AP-ul tace, SSID-ul este transmis în clar (plain text) în alte trei situații:

  • Când clientul face Active Probing (caută rețeaua).
  • Când AP-ul răspunde clientului (Probe Response).
  • În momentul asocierii propriu-zise (Association Request).

Orice script kid cu o placă de rețea setată în monitor mode și Wireshark sau Aircrack-ng poate vedea numele rețelei „ascunse” în câteva secunde, așteptând pur și simplu ca un dispozitiv legitim (laptopul unui angajat, de exemplu) să se conecteze la ea. Dacă e nerăbdător, atacatorul poate trimite un pachet de de-authentication forțând clienții legitimi să se deconecteze și să se reconecteze instantaneu, dezvăluind imediat SSID-ul ascuns.

3. Transferul vulnerabilității către utilizator

Aceasta este partea cu adevărat revoltătoare a deciziei IEEE. Pentru a proteja o bucată fixă de hardware (routerul), standardul a sacrificat intimitatea dispozitivelor mobile.

Așa cum discutam anterior, pentru ca tu să te poți conecta la routerul ascuns de acasă sau de la birou, laptopul tău este forțat să preia el sarcina difuzării. Astfel, tu pleci cu laptopul în oraș, iar dispozitivul tău strigă încontinuu parola (SSID-ul rețelei tale ascunse) către absolut oricine vrea să asculte, făcându-te vulnerabil la atacuri de tip KARMA.

Astăzi, nicio autoritate serioasă de securitate cibernetică nu mai recomandă ascunderea SSID-ului, fiind considerată o practică desuetă care doar îngreunează managementul rețelei pentru administratorii de sistem, fără a oferi niciun avantaj real de securitate.

❺ Ludditus: Atacul de tip KARMA rămâne o problemă, căci practic toți cei care folosesc un laptop sau un smartphone au configurată conectarea automată la AP-ul de acasă! Or, numele acestuia va fi strigat în eter și în locurile publice. E foarte puțin probabil ca oamenii să-și dezactiveze această conectare automată de fiecare dată când ies din casă.

În final, campaniile astea adesea uită să spună „nu vă citiți nici mail-ul când sunteți conectați la o rețea Wi-Fi publică”, dar asta nici nu ar fi posibilă, pentru că app de genul GMail oricum vor verifica în mod automat (sau primesc push). Firește, conexiunea e securizată, dar voiam să subliniez lipsa de realism a acestor campanii „de conștientizare”.

Gemini: Ai atins exact punctul nevralgic al întregii probleme: ignorarea completă a modului în care funcționează ecosistemele moderne și comportamentul uman real. Așteptarea ca un utilizator să activeze și să dezactiveze manual profiluri de rețea de fiecare dată când iese pe ușă este o aberație de design (și o recunoaștere a eșecului din partea dezvoltatorilor de sisteme de operare).

Totuși, există o nuanță tehnică importantă care previne colapsul total în cazul rețelelor de acasă, alături de o realitate tehnică pe care campaniile o ignoră complet când vine vorba de aplicații.

Salvarea parțială: Handshake-ul WPA2/WPA3

Atacul clasic KARMA este absolut devastator pentru rețelele deschise (fără parolă) salvate în telefon (gen Wi-Fi-ul de la mall sau din aeroport). Dacă telefonul tău strigă „Ești aici, Free_Airport?”, atacatorul spune „Da” și conexiunea se face instantaneu, în clar, oferindu-i un Man-in-the-Middle transparent.

Însă, pentru rețeaua ta de acasă configurată cu WPA2 sau WPA3, lucrurile stau un pic diferit:

  • Când telefonul tău caută rețeaua de acasă, un AP pirat poate răspunde: „Da, eu sunt rețeaua ta de acasă”.
  • Dispozitivul tău va iniția automat conexiunea, dar va cere validarea matematică a parolei (celebrul 4-way handshake).
  • Deoarece atacatorul nu are cheia pre-partajată (parola ta de acasă), nu poate finaliza handshake-ul. Conexiunea eșuează înainte de a i se aloca telefonului un IP și înainte de a se trimite vreun bit de trafic util.

Pentru a te compromite în acest scenariu, atacatorul trebuie să recurgă la un atac hibrid (cum ar fi framework-ul Wifiphisher): bruiază semnalul real de acasă, ridică un AP fals deschis cu exact același nume și îți servește un portal captiv care arată ca pagina de configurare a routerului tău, spunând: „A fost detectată o problemă de securitate. Introduceți parola Wi-Fi pentru a restabili conexiunea.” Aici intervine din nou ingineria socială și acel „Layer 8”.

Iluzia controlului manual asupra aplicațiilor

Observația ta legată de verificarea mail-ului expune probabil cea mai mare inepție a acestor campanii de conștientizare. Sfatul „nu intra pe mail” provine din era dial-up-ului sau a primelor conexiuni broadband, când deschideai Outlook Express, apăsai „Send/Receive”, vedeai un progres pe ecran și apoi închideai aplicația.

Astăzi, conceptul de „a nu folosi o aplicație” pe un smartphone conectat este o pură fantezie:

  1. Conexiunile persistente: Imediat ce interfața radio negociază o conexiune de Nivel 2 (Layer 2) și primește un IP, sistemul de operare trezește daemonii de rețea.
  2. Avalanșa de fundal: În secunda doi, se deschid automat zeci de tuneluri TLS către Google Play Services (FCM – Firebase Cloud Messaging) sau Apple Push Notification service (APNs).
  3. Sincronizarea invizibilă: Înainte ca tu măcar să deblochezi ecranul telefonului pentru a te gândi dacă e cazul să „intri pe mail” sau nu, GMail a sincronizat deja inbox-ul, WhatsApp a descărcat mesajele criptate, iar serviciile meteo și-au trimis telemetria.

Pentru a respecta la literă sfaturile DNSC, ar trebui să ții telefonul în Mod Avion, să îl conectezi la Wi-Fi-ul public, să oprești manual sincronizarea de fundal pentru absolut toate conturile și aplicațiile, să deschizi doar browserul pe ziarul online, și apoi să ștergi rețeaua. Nimeni, niciodată, nu va face asta.

Aceste campanii sunt scrise de birocrați care bifează niște metrici de „educare a publicului” folosind șabloane din 2005. Ele ignoră voit faptul că securitatea reală trebuie să fie invizibilă, construită la nivel de protocol (cum sunt TLS 1.3 și HSTS) și implicită, tocmai pentru că factorul uman nu poate și nu trebuie să gestioneze micro-decizii de rețelistică la fiecare pas pe stradă.

❻ Ludditus: Ah, nu știam despre „4-way handshake”. Eu rămăsesem la vechiul concept al acceptării tacite, în care AP-ul pirat „înghite” orice parolă, iar clientul acceptă „în orb” conexiunea.
Din fericire, nu cred că mai există routere casnice cu securitate mai slabă decât WPA2-Personal, iar Windows configurează implicit și AP-ul de acasă drept Public dacă nu folosești printer and file sharing (sau așa ar trebui să fie). 

Gemini: Exact, acel „4-way handshake” este eroul tăcut care ne salvează de un dezastru absolut. Mecanismul pe care îl aveai în minte, cel de „acceptare tacită” (unde AP-ul zice „da, vino la mine, orice parolă ai avea”), funcționează exact așa cum ai descris, dar doar pentru rețelele deschise (Open) sau pentru portalurile captive.

În cazul WPA2-Personal (PSK – Pre-Shared Key), autentificarea este mutuală. Nici clientul, nici routerul nu trimit parola prin aer. În schimb, amândoi folosesc parola pentru a rezolva o problemă criptografică (derivând o cheie de sesiune temporară). Dacă AP-ul pirat nu are parola ta reală, nu poate genera răspunsul matematic corect în etapa a 3-a a handshake-ului. Clientul (laptopul tău) vede că AP-ul a greșit calculul, își dă seama că e un impostor și închide imediat conexiunea cu un banal mesaj de tipul „Can’t connect to this network”.

Legat de observațiile tale tehnice, ai dreptate pe ambele fronturi:

1. Moartea protocoalelor vechi

Astăzi este extrem de rar să mai dai peste WEP sau WPA1. WPA2 a devenit standardul minim absolut. Singurul atac fezabil asupra WPA2-Personal este ca atacatorul să asculte pasiv acel handshake autentic când te conectezi la routerul tău legitim, să salveze pachetele, și apoi să încerce să spargă parola offline, acasă, folosind un dicționar de parole și o placă video puternică. Dacă ai o parolă decentă, atacul este inutil.

2. Salvarea oferită de Windows (NLA)

Ce ai subliniat despre Windows este o funcție vitală: Network Location Awareness (NLA). Când Windows detectează un BSSID nou sau un gateway nou, plasează implicit rețeaua în profilul „Public”.

Acest profil acționează ca un scut Zero Trust la nivel de host. Windows Defender Firewall închide automat porturile pentru partajarea locală (portul 445 pentru SMB/CIFS, 137-139 pentru NetBIOS, descoperirea UPnP, etc.). Astfel, chiar dacă te conectezi la un Wi-Fi de cafenea (sau acasă, cu setarea pe Public), celelalte laptopuri sau telefoane conectate la același router nu pot interoga sistemul tău de operare pentru a exploata vulnerabilități locale. Este o practică excelentă de administrare a sistemului să lași rețeaua de acasă pe „Public” dacă nu ai un NAS local sau o imprimantă de rețea care să necesite vizibilitate.

Ca o ironie a sorții: Acel concept vechi al tău, în care un AP fals înghite credențialele în orb, a rămas o problemă masivă fix acolo unde te-ai aștepta la mai multă securitate: pe rețelele corporative sau universitare (WPA2-Enterprise / 802.1X). Acolo te loghezi cu un cont și o parolă pe un server RADIUS. Dacă un AP pirat simulează rețeaua corporației, iar utilizatorul dă ignore la alerta de „Certificat Necunoscut”, AP-ul va accepta în orb conexiunea doar pentru a fura hash-ul MSCHAPv2 al parolei! Deci intuiția ta a fost foarte corectă, doar că se aplică la un alt nivel al standardului.