Il Wi‑Fi pubblico è pericoloso anche con HTTPS: attacchi reali, casi e protezione nel 2026

Wi‑Fi pubblico: ciò che sembra sicuro ma in realtà non lo è

Adoriamo internet gratuito nei bar, hotel e aeroporti. Chi non ama la comodità? Ti connetti e puoi lavorare subito. Ma spesso si paga questa comodità con la sicurezza. Il Wi‑Fi pubblico è come un bollitore in un ostello: sembra pulito, ma non sai chi e cosa ci ha fatto ieri. E sì, anche quando vedi il lucchetto HTTPS, non è una protezione al 100%. Nel 2026 gli attaccanti sono più astuti, gli strumenti più accessibili e la posta in gioco più alta.

Sembra preoccupante? Un po’. Ma proprio per questo spiegheremo tutto con calma: come e perché HTTPS non protegge da tutto, quali attacchi funzionano davvero oggi, come i malintenzionati sfruttano captive portal e falsi access point, cosa può e non può fare una VPN, e come possiamo ridurre i rischi quasi a zero senza paranoia ma con consapevolezza.

Parleremo in modo semplice, umano, con dati e casi concreti. Così non annuirete solo, ma cambierete davvero le vostre abitudini. Allora, partiamo?

Perché il Wi‑Fi "gratuito" raramente è davvero gratis

Il Wi‑Fi pubblico lo paghi con i tuoi dati. I portali di autenticazione raccolgono email, numero di telefono, impronte del dispositivo e a volte cercano di "iscriverti" a notifiche push. Gli amministratori di rete vedono i metadati del traffico: quali domini visiti, quando e in che quantità. E se non è un amministratore ma un malintenzionato connesso alla stessa rete? Allora si parla di attacchi MITM, sostituzione DNS, phishing e furto di sessioni.

Come i malintenzionati "vedono" il tuo dispositivo

Il router o un falso access point monitorano ARP, DHCP, DNS e handshake TLS. Anche senza decriptare HTTPS si capisce molto dai metadati: SNI (se non cifrato), indirizzi IP, dimensione dei pacchetti, frequenza delle richieste. Aggiungi il traffico pubblico di app e protocolli non protetti — e il quadro è sorprendentemente chiaro.

Mito del "ho HTTPS, sono al sicuro"

Amiamo il lucchetto nella barra degli indirizzi. Ma HTTPS protegge il canale "browser-server", non "punto di accesso-coscienza del gestore della rete". Se un malintenzionato ha cambiato il DNS e ti ha mandato su un clone di phishing con certificato valido (sì, può succedere per compromissione della catena, errori di configurazione o certificati radice malevoli sul dispositivo), la tua fiducia è un contro. E se l’attacco avviene prima di HTTPS (ad esempio via captive portal), il lucchetto nemmeno compare.

Come funziona HTTPS nel 2026 e perché non è la panacea

Nel 2026 la maggior parte dei browser usa TLS 1.3 di default e punta a Encrypted Client Hello (ECH) per nascondere il SNI. È un miglioramento. Ma non è perfetto. Il diavolo sta nei dettagli: redirect, primo click non protetto, contenuti misti, HSTS incompleto, vecchie app, configurazioni router deboli. Poi c’è il problema della fiducia nei certificati radice e nei profili MDM personalizzati.

TLS 1.3, ECH, HTTP/3 e la realtà dei bar

HTTP/3 basato su QUIC accelera e cifra il trasporto, ECH nasconde il dominio nell’handshake cifrato. Perfetto sulla carta. Ma le reti di bar spesso limitano o filtrano QUIC per risparmiare e forzano il client a tornare a HTTP/2 o addirittura HTTP/1.1. Qui si aprono “buchi” di compatibilità, che gli attaccanti sfruttano bloccando i protocolli nuovi o manipolando le risposte al primo contatto.

HSTS protegge, finché qualcuno non lo disabilita

HSTS dice al browser: “usa sempre HTTPS”. Funziona se il sito è nella lista pre-caricata o ci sei già stato con HTTPS. Male se è la prima visita e la rete forza redirect HTTP. La finestra d’attacco è piccola ma reale. E se il router taglia le intestazioni HSTS (proxy intermedio) o induce downgrade? Rarità, ma succede in reti “grigie” con filtri aggressivi.

Problema dei certificati fidati e profili MDM

A volte sui dispositivi ci sono certificati radice extra di dubbia fiducia: via VPN pirata, profili aziendali, antivirus obsoleti. In una rete pubblica un attaccante può proporre “aggiornamento certificato internet” tramite un falso captive portal. Se accetti — MITM su TLS diventa possibile. Casi visti in hotel e reti turistiche.

Minacce reali nelle reti pubbliche: da MITM a sostituzione DNS

Gli attacchi possibili sono tanti, ma nel 2026 quelli più frequenti sul campo sono: MITM (tramite ARP spoofing o proxy), DNS spoofing con sostituzione domini e blocco DoH, Evil Twin clonando SSID, captive portal di phishing con script proxy, e furto di sessioni in app senza pinning rigoroso.

MITM tramite ARP spoofing

Classico: il malintenzionato convince il tuo dispositivo di essere il gateway predefinito. I pacchetti passano da lui. Può vedere domini, IP, handshake tentati. Se riesce a imporre un certificato proxy o a forzarti su HTTP, scatta ispezione profonda. Notizia buona: i sistemi moderni si difendono meglio, ma le reti pubbliche spesso disabilitano protezioni per “compatibilità”.

DNS spoofing e blocco DoH/DoT

Tutti amano DNS over HTTPS, ma molte captive portal bloccano DoH/DoT finché non si supera il login, poi "dimenticano" di riattivarlo. In questa finestra l’attaccante sostituisce facilmente risposte: chiedi bank.example — ottieni bank-secure-login.example. Seguono SSL stripping o certificati validi ma rari e difettosi. Senza attenzione e difese apposite, è un problema serio.

Evil Twin e il clone che nasce in due minuti

Creare un punto con lo stesso SSID, stessa maschera MAC e segnale più forte è questione di pochi click e minuti. Questa “gemella” intercetta il traffico senza essere notata, soprattutto se hai l’auto-connessione attiva. Nel 2026 è più facile con device economici compatti e software che “copia” reti automaticamente. E sì, molti dispositivi si connettono sempre al segnale più forte senza chiedere.

SSL stripping e reset di HSTS: cosa succede dal vivo

SSL stripping ti fa passare da HTTPS a HTTP prima che scatti la protezione. È come attirarti su una scala mal illuminata: un passo falso e sei su un terreno scivoloso.

Scenario 1: redirect prima di HTTPS

Digiti un indirizzo senza https. Il malintenzionato intercetta la prima richiesta e risponde con un sito HTTP di passaggio che sembra quello giusto. Il pulsante "Accedi" punta al sito HTTPS vero, ma i dati vengono già intercettati. Visivamente tutto lampeggia, l’utente non si accorge e la sessione è compromessa.

Scenario 2: bug di compatibilità e HSTS tagliato

Alcuni siti abilitano HSTS parzialmente: sottodomini non protetti, vita breve, niente preloading. L’attaccante propone un sottodominio senza HSTS, dove ti autentichi per abitudine o perché aperto da una pubblicità. Poi gioca sporco: cookie, token, ingegneria sociale.

Scenario 3: certificato utente

Attraverso un falso captive portal ti offrono di “sbloccare internet” installando un “certificato di accesso”. Un tap e MITM anche su HTTPS diventa realtà. Nel 2026 meno frequente, ma ancora vivo in luoghi turistici e eventi. Soprattutto se la rete offre coupon, sconti o “Wi‑Fi bonus senza pubblicità”.

Attacchi captive portal senza magie: dove cadono anche gli attenti

Il portale di autenticazione è legittimo. Ma è amato dagli attaccanti perché rende normale l’idea di un redirect. L’utente vede uno schermo insolito? Certo, è il portale. E clicca. E lì arrivano di tutto: certificati, “aggiornamenti browser”.

Pagine di phishing che si mascherano da rete

Logo del bar, nome dell’aeroporto, persino la palette colori corrisponde. Più credibile di così non si può. Il portale chiede email, password social “per accedere”, numero carta “per verificar 1 euro” o Apple/Google ID per “sincronizzazione”. Ti sorprenderesti di quanti ci cascano. Abbiamo visto conversioni del 3-7% in eventi grandi, decisamente tanto.

Attacchi push e trappole QR

Codice QR sul tavolo: “Connettiti al Wi‑Fi veloce”. Scansiona e atterri su pagina che ti chiede di installare profilo o abbonarti a notifiche. Poi arrivano push con link di phishing: “La tua sessione è scaduta”, “Conferma pagamento”. Funziona anche a distanza di ore, quando sei a casa. Pessimo.

Script proxy e raccolta token

Alcuni portali inseriscono script proxy che monitorano i passaggi finché il browser cache i redirect. Le tue abitudini emergono, si raccolgono ID, cresce il rischio di ritargeting. Non sempre cybercrimine — talvolta marketing aggressivo — ma fastidioso comunque.

Rogue AP e Evil Twin: noterai la sostituzione?

Credi di essere connesso a "Airport_Free_WiFi". Ma in realtà sei su "Airport_Free_WiFi" sul laptop di un attaccante a due metri da te, con segnale più forte. La rete dà internet, tutto veloce, il caffè è caldo — perfetto. Finché non è troppo tardi.

Segnali di sostituzione

Certificati instabili, redirect strani, DoH/DoT che si disconnette improvvisamente, avvisi tipo “Questa connessione può essere monitorata”, portali che spuntano ad ogni sito. Poi richieste inaspettate di installazione profili, cambi proxy, “aggiornamenti sicurezza”. Due di queste e scatta il sospetto.

Perché WPA2-Enterprise non basta sempre

Reti aziendali con 802.1X e EAP sono un progresso, ma spesso gli utenti ignorano di controllare il nome del server RADIUS. L’Evil Twin mette un RADIUS falso con certificato autofirmato e il client accetta. Nel 2026 i sistemi mobili allertano meglio, ma l’errore umano è sempre in agguato.

WPA3, SAE e la realtà

WPA3-Personal con SAE è più resistente a brute-force, ma non elimina MITM a livello IP e DNS se l’attaccante controlla il punto di accesso. La cifratura tra client e AP non è una fortezza contro tutto. Soprattutto se l’attaccante è sull’AP stesso.

VPN nel 2026: punti di forza, limiti e miti

La VPN è uno strumento potente, non una bacchetta magica. Cripta il traffico dall’access point al server VPN, nasconde richieste DNS (se configurata bene) e blocca molti attacchi MITM. Ma non difende dal phishing, non risolve problemi causati da certificati malevoli installati volontariamente, e a volte fallisce con captive portal.

Cos’è davvero protetto dalla VPN

Con VPN attiva dalla connessione, tutto il traffico viaggia in tunnel cifrato. L’attaccante non vede domini, contenuti o richieste. Una buona VPN usa propri DNS nel tunnel, previene DNS spoofing. Il kill switch blocca la connessione se il tunnel cade. Nel 2026 protocolli come WireGuard e IKEv2/ChaCha20 sono veloci anche su mobile e alcuni provider usano QUIC per resistere a reti instabili.

Dove la VPN non basta

Pagina di phishing? VPN non segnala se il TLS è valido. Profilo malevolo installato? VPN non lo vede. Furto token in app senza pinning? VPN nulla può se l’app consente MITM tramite certificati personalizzati. E la VPN può non partire prima del captive portal: così la finestra d’attacco resta aperta.

Split-tunneling e configurazioni delicate

Molti usano split-tunneling “per velocità”. Agli attaccanti piace: parte del traffico sfugge al tunnel e si può intercettare. Su Wi‑Fi pubblico meglio full-tunnel rigido, blocco reti locali e kill switch attivo. Non sempre comodo, ma dormi tranquillo.

Best practice pratiche: checklist senza fanatismi

Niente accademia. Passi concreti e abitudini che funzionano davvero. Prima regole base, poi settaggi avanzati e aspetti business.

Regole base per tutti

• Non inserire password e dati carte sul Wi‑Fi pubblico se non indispensabile. Se serve, usa VPN e solo su domini certi.
• Disattiva auto-connessione a reti aperte. Meglio accendere manualmente e dimenticare rete dopo l’uso.
• Stai attento agli avvisi sui certificati. Ogni “errore sicurezza” è un segnale rosso. Chiudi la scheda.
• Non installare profili, certificati radice, “acceleratori internet” o “aggiornamenti browser” dal portale.
• Usa un browser sandbox dedicato per reti pubbliche, senza sessioni o autenticazioni salvate.

Configurazioni tecniche che aiutano

• Attiva VPN con avvio automatico e kill switch. Disabilita split-tunneling per reti pubbliche.
• Forza sistema a usare DoH/DoT dentro VPN. Blocca DNS locali se imposti provider tenta.
• Imposta blocco installazione certificati radice senza PIN o biometria. Controlla certificati fidati trimestralmente.
• Nel browser attiva modalità HTTPS-Only. Installa estensioni per isolamento sessioni (contenitori) e gestore password con rilevamento phishing.
• Attiva MFA/2FA, meglio con chiavi hardware o passkeys. Codici OTP via SMS minimo, ma meglio di niente.

Per smartphone e laptop

• iOS e Android: blocca sincronizzazioni in background di app pesanti in reti aperte senza VPN.
• Windows e macOS: attiva firewall, blocca connessioni in entrata in reti pubbliche, disabilita condivisione file e AirDrop/Nearby Share temporaneamente.
• Crea profilo Wi‑Fi "Pubblico": senza auto-connessione, promemoria VPN attiva, limitazioni rete locale.

Per aziende e team

• Policy MDM: vieta installazione certificati radice utente, VPN always-on obbligatoria, controllo CA fidati.
• Usa SASE/ZTNA con controlli device posture: accedi solo da dispositivi aggiornati e cifrati.
• Implementa filtraggio DNS tramite resolver sicuri, con blocco domini recenti (DGA, fast-flux).
• Forma utenti ogni sei mesi. Mostra demo live di attacco Evil Twin — attenzione cresce molto.

Casi reali: com’è nella pratica

Qualche storia asciutta. Imparare dagli errori altrui costa meno.

Caso 1: aeroporto e "accesso veloce senza pubblicità"

Rete con portale di autenticazione. Attaccante monta Evil Twin stesso SSID, segnale più forte. Portale identico, offre “acceleratore” installando profilo. Il 10% accetta. Seguono MITM su siti bancari, furto token, redirect phishing. Risultato: account compromessi e email aziendali leakate.

Caso 2: caffetteria e SSL stripping "al primo click"

Utente digita indirizzo senza https, attaccante inserisce proxy HTTP al primo passaggio. Form login intercettata e inoltrata sito vero, utente ignaro. Dopo due ore azioni sospette nell’account. Salva MFA e log attività, ma resta il fastidio.

Caso 3: conferenza, QR code e push phishing

Organizzatori espongono QR “connettiti al Wi‑Fi”. Alcuni adesivi sono stati sostituiti. Il link porta a falso portale, che iscrive a notifiche push. In un giorno arrivano messaggi “Conferma accesso”. Conversione 4%. Basta per scalpore social e qualche brutta storia.

Tendenze 2026 che cambiano le regole

Senza contesto ci si blocca con vecchi consigli. Nel 2026 tre mosse chiave: passaggio massivo a ECH, passkeys al posto di password, integrazione ZTNA nei dispositivi aziendali. Sembra burocrazia, ma è una spinta forte alla sicurezza.

ECH e nascondere il SNI

Ampio supporto a ECH riduce leak dominio al primo handshake. Diminuisce efficacia di certi tipi di sorveglianza passiva sul Wi‑Fi pubblico. Ma se si forza downgrade a protocolli vecchi (coi vecchi AP), la protezione cala. Quindi non disattivare protcoli moderni per “compatibilità” se puoi evitare.

Passkeys e WebAuthn

Quando nel tuo account usi dispositivo e biometrici invece della password, rubare la password non serve più. Anche se intercettano traffico, il segreto utile per l’accesso non si ottiene. Combina passkeys con limitazioni geografiche e device e il Wi‑Fi pubblico fa meno paura.

ZTNA e SASE sul campo

Le aziende passano da tunnel VPN a proxy interni con verifica contesto: chi sei, da quale dispositivo, patch installate, disco cifrato, telefono non rootato. In rete pubblica così cala drasticamente il successo dell’ingegneria sociale: anche con password rubate i servizi restano blindati.

Configurazioni passo passo sulle piattaforme popolari

Un po’ di concretezza: cosa fare oggi per stare tranquilli domani. Senza screenshot, solo passi chiari.

iOS 18 e iPadOS

• Impostazioni — Wi‑Fi — La tua rete — Auto-connessione: disattiva per reti aperte. Indirizzi Wi‑Fi privati: attiva.
• Impostazioni — VPN — Aggiungi configurazione: scegli WireGuard o IKEv2. Attiva "Connetti su richiesta" e "Blocca traffico senza VPN" (kill switch via profilo MDM o config).
• Impostazioni — Safari — Avanzate — Modalità solo HTTPS: attiva. Disabilita profili di terze parti, verifica certificati fidati.

Android 15

• Rete e internet — Wi‑Fi — Impostazioni — Auto-connessione: disattiva per aperte. MAC casuale: attiva.
• VPN: installa client con always-on e blocco traffico senza VPN. Abilita DNS-via-VPN, disabilita DNS locale.
• Chrome — Sicurezza — Usa DNS sicuri — abilita DoH (via VPN se possibile). Attiva password protette e allarmi phishing.

Windows 12

• Rete e internet — Wi‑Fi — Gestisci reti note: rimuovi aperte, disattiva auto-connessione.
• Firewall: profilo "Pubblico" — blocca connessioni in entrata. Disattiva condivisione file e stampanti.
• VPN: usa WireGuard/IKEv2, attiva "Disconnetti se VPN cade". Imposta policy "Permetti traffico solo via VPN" per reti pubbliche.

macOS 15

• Rete — Wi‑Fi — Avanzate: rimuovi reti aperte, disattiva "Connetti automaticamente" per sconosciute.
• Firewall — Attiva — Blocca tutte le connessioni in entrata per profili pubblici. Disabilita AirDrop su “Solo contatti” o del tutto.
• Configura VPN con "Connetti su rilevamento rete pubblica". Safari — Abilita “Preferisci HTTPS” e protezione tracciamento.

Phishing e ingegneria sociale: perché clicchiamo

La tecnica si stoppa con la configurazione. La gente è più difficile. Clicchiamo quando siamo di fretta, stanchi, tentati da bonus o perché sembrano logici. Il Wi‑Fi pubblico è perfetto per mettere pressione: sei in fila per imbarco, il caffè si raffredda, i colleghi scrivono “che succede?”. Qui scattano le trappole.

Come tutelarti

• Fermati tre secondi. Ogni portale sconosciuto: pausa. Se chiede password email, è quasi sicuro un inganno.
• Cerca segnali di “phishing”: domini strani con trattini, zone bizzarre, avvisi browser. Se dubbi, controlla via rete mobile, non la stessa Wi‑Fi.
• Usa gestore password: non riempirà password in domini diversi. Se manca autocompletamento, verifica la barra indirizzi.

App mobili: una ferita nascosta

Non tutte le app impostano pinning rigoroso dei certificati server. Quindi con MITM tramite certificati custom possono “credere” all’attaccante. Nel 2026 molti hanno sistemato, ma non tutti. Usa servizi critici nel browser con passkeys e impostazioni severe, non in app sospette.

Errori che facciamo sempre

Onestamente? Sbagliamo tutti. Chiamiamo le cose col loro nome e smettiamola.

Auto-connessione a tutto

Disattiva globalmente. Meglio 10 secondi a scegliere rete che 10 ore a recuperare account.

Ignorare errori certificati

“Eh, sarà un problema del bar”. No. Nel 9 casi su 10 è quello che il browser ti avverte. Esci.

Password servizi lavoro su reti aperte

Se non si può, non farlo. Se serve, solo con ZTNA/VPN aziendale, MFA e browser sicuro.

Per sviluppatori e amministratori: cosa fare oggi

Gli utenti useranno Wi‑Fi pubblici. Il nostro compito è rendere il tutto il meno pericoloso possibile.

Per il web

• HSTS rigido con includeSubdomains e preloading. Metti almeno 1-2 anni.
• Evita contenuti misti. Usa Content Security Policy e forzatura HTTPS.
• Supporta WebAuthn/passkeys. Minimizza dipendenza da password.
• Monitora sottodomini e typosquatting. Alert automatici su nuovi domini clone.

Per app mobili

• Pinning certificati con rotazione chiavi. Gestisci certificati radice non fidati.
• Blocca uso su dispositivi rootati/jailbroken per funzioni critiche. Attiva protezione MITM in SDK.
• Fail-closed: con certificato dubbio non procedere.

Per reti aziendali

• Policy MDM, ZTNA, device posture e controllo certificati. Blocca proxy locali e profili senza firma.
• Log e rilevamento anomalie: picchi errori TLS, blocchi DoH, reaccessi massivi a portali sono segnali di rischio.

Checklist veloce prima di connettersi a Wi‑Fi pubblico

1. È davvero la rete giusta? Verifica col personale.
2. Auto-connessione disattivata? Bene.
3. VPN si avvia da sola? Kill switch attivo?
4. Browser in modalità HTTPS-Only, gestore password pronto?
5. Niente installazioni di profili o certificati, anche se ti dicono “serve davvero”.
6. Evita pagamenti o azioni sensibili se possibile rimandare.

Cosa fare se pensi di essere sotto attacco

Non farti prendere dal panico. Il piano è semplice. Passi brevi, sei al sicuro.

Passo dopo passo

• Disconnettiti subito dal Wi‑Fi, passa a rete mobile.
• Cambia password degli account chiave, revoca sessioni e token.
• Controlla certificati e profili fidati. Elimina quelli sospetti.
• Attiva notifiche login, aggiungi/passkey nuovi, aggiorna MFA.
• Controlla log: accessi da luoghi strani, tentativi di recupero. Se serve, segnala a supporto servizi.

Rischio minimo con buon senso massimo

Il Wi‑Fi pubblico è come un taxi di notte: a volte serve, ma senza esagerare. Un po’ di attenzione, qualche configurazione giusta, buone abitudini — e sei tra il 10% delle “prede” più difficili. Gli attaccanti cercano vittime più facili.

Facciamo un patto: niente paranoie, ma occhi aperti. Accendiamo VPN prima, non installiamo profili dubbi, non ignoriamo avvisi, amiamo passkeys e ZTNA, e ogni sei mesi puliamo i certificati fidati. I dettagli fanno la differenza. E sì, il caffè resterà caldo, promesso.

FAQ: domande frequenti su Wi‑Fi pubblico e sicurezza

Basta solo HTTPS nel 2026 per stare al sicuro?

No. HTTPS è la base, ma non protegge da phishing, captive portal o se hai installato certificati malevoli. È parte della difesa, non il castello intero. Usa VPN, modalità HTTPS-Only, passkeys e sano scetticismo.

La VPN risolve tutti i problemi del Wi‑Fi pubblico?

No. La VPN cripte e nasconde DNS, ma non elimina phishing né ingegneria sociale. Non serve se hai dato fiducia a certificati malevoli tramite profili. Usa VPN come base, non unica difesa.

I captive portal sono pericolosi?

Lo sono quanto sei pronto a cliccare senza leggere. Portale legittimo va bene, ma normalizza “finestre strane” che gli attaccanti sfruttano. Non inserire password di servizi estranei, non installare profili o certificati. Mai.

Conviene disattivare auto-connessione a reti aperte?

Sì. È il modo migliore per evitare Evil Twin. Connettiti manualmente, verifica nome col personale, rimuovi rete dopo uso. E attiva MAC casuale (indirizzo privato).

Cosa conta di più: DoH/DoT o VPN?

Se devi scegliere uno, VPN perché incapsula DNS e traffico. Ma meglio insieme: DoH/DoT entro VPN. Importante che sistema non usi DNS locale del provider in rete pubblica.

Passkeys servono se ho password buone e 2FA?

Sì. Passkeys riducono phishing quasi a zero perché legate a dominio e dispositivo. Combinate con 2FA alzano molto la “difficoltà d’attacco” per i criminali.

Posso usare servizi bancari sul Wi‑Fi pubblico in sicurezza?

Sì, ma meglio con rete mobile o VPN molto rigida con HTTPS-Only e gestore password. Se vedi anche un solo avviso di certificato o redirect strano, esci e cambia rete.