Provate un hotspot prima di avvicinargli le credenziali di lavoro

L'hotspot assegna un indirizzo prima di assegnare internet, e la fiducia si decide proprio in quel varco. Il dispositivo si associa, chiede un indirizzo, e poi ogni richiesta in uscita viene intercettata finché un portale non dichiara la sessione autorizzata. Questo meccanismo spiega perché una pagina può sembrare caricarsi mentre non esiste alcuna connessione reale. Provate il varco con qualcosa di innocuo prima che vi si avvicini qualsiasi credenziale di lavoro.

Che cosa fa l'hotspot alla vostra prima richiesta

L'associazione dà al dispositivo un collegamento, e il DHCP gli dà un indirizzo, un gateway e di solito un server DNS di proprietà del locale. Finché l'autorizzazione non è completa, il gateway scarta o reindirizza il traffico in uscita, e molti portali rispondono al DNS per ogni nome con il proprio indirizzo. Per questo una risoluzione sembra riuscire: la risposta è il portale, non il sito che avete chiesto. La rete si comporta come progettato; semplicemente non è ancora internet.

La prima richiesta HTTP riceve di solito un reindirizzamento al portale, che il sistema operativo può aprire per voi. HTTPS non può essere reindirizzato così, quindi fallisce o si blocca, e il browser mostra un errore di certificato o un timeout. La differenza è diagnostica: un reindirizzamento HTTP è il portale che parla, mentre un guasto TLS verso un host non correlato è un'altra cosa. Un giardino murato, dove pochi domini vengono lasciati passare per il pagamento o l'accesso, produce un terzo schema.

Confermate la rete prima di accedere

Confermate l'SSID e il metodo di accesso con il locale attraverso un canale che non sia la rete stessa. Un portale che chiede una password aziendale, un numero di carta e un indirizzo e-mail fa tre cose diverse, e solo le ultime due sono normali per l'accesso degli ospiti. Preferite l'avviso di portale captive del sistema operativo, che rileva il reindirizzamento tramite un endpoint noto invece di fidarsi di qualunque pagina appaia. Se il locale non sa descrivere il proprio portale, è un motivo per aspettare e non per improvvisare.

Un avviso di certificato durante l'accesso al portale non è un passaggio da saltare con un clic. Il portale non ha bisogno di impersonare un host non correlato per autenticarvi.

Fate il controllo più piccolo che dimostra l'accesso

Completate l'autorizzazione legittima, poi richiedete una pagina HTTPS pubblica qualsiasi che non abbiate mai caricato, così la risposta non possa venire dalla cache. Annotate che cosa è fallito davvero, se fallisce: una risoluzione di nome, un timeout di connessione, un errore di certificato o un rifiuto del servizio. Quei quattro appartengono a livelli diversi, e scriverli impedisce alla persona successiva di riprovare a sensazione. Poi collegate la VPN prevista e richiedete una risorsa che la richieda.

Tenete la prova piccola. Un download di speed test su un accesso a consumo risponde a una domanda che nessuno ha posto e può costare denaro all'utente. Una risposta con le intestazioni basta a stabilire la raggiungibilità, e non trascina megabyte su un collegamento fatturato a gigabyte.

Se l'accesso normale funziona e il tunnel no, è un'indagine diversa da quella di una rete che non ha mai autorizzato. Tenete separati i due risultati invece di cambiare più impostazioni di privacy insieme.

Tenete il lavoro privato fuori dal confronto

Ogni applicazione sul dispositivo è un potenziale osservatore, e un portale captive è il momento in cui tutte cercano di raggiungere i propri server. Chiudete quelle che potete, e trattate un dispositivo gestito sempre attivo come una questione di politica e non tecnica: usate il metodo approvato per il confronto invece di rimuovere la protezione che lo rende gestito. Se il dispositivo vieta del tutto il traffico fuori dal tunnel, fate il controllo su un altro dispositivo non sensibile. Il senso dell'esercizio è imparare sulla rete senza esporle credenziali.

Non catturate il traffico di altre persone per diagnosticare il locale, e tenete ogni cattura diagnostica entro il vostro dispositivo e la vostra sessione. Rivedete i campi di indirizzo e identificatore prima di allegare una cattura a un ticket, perché la rete del locale non è il vostro armadio delle prove.

Decidete che cosa il risultato vi permette di fare

Sono possibili tre esiti: accesso completo con un tunnel funzionante, accesso solo al portale con un tunnel guasto, o nessun accesso. Ognuno ha un passo successivo diverso, e il valore della prova è sapere in quale vi trovate prima di cambiare impostazioni. Accesso completo significa che il lavoro può proseguire attraverso il tunnel; accesso solo al portale suggerisce che la porta o il protocollo del tunnel è bloccato, quindi la risposta è un altro trasporto o un'altra rete; nessun accesso significa che il locale oggi non può sostenere il compito. Un dispositivo che prova sempre un solo protocollo non riesce a distinguerli.

Annotate l'SSID, l'esito e l'ora, così la persona successiva nello stesso locale parte da prove. La guida alle reti captive di Apple descrive il comportamento di rilevamento dietro l'avviso, ed è la parte che vale la pena capire prima di dare la colpa alla VPN.