Sei in un bar con un espresso decente e un Wi-Fi discutibile, e ti serve il desktop di casa. Collegarsi è sicuro? Dipende interamente dalla crittografia del trasporto — una sessione cifrata end-to-end è sicura sulla rete più sospetta della città, e un vecchio protocollo non cifrato non è sicuro sulla più bella. Ecco il modello di minaccia in parole semplici, i protocolli ordinati per ciò che perdono e la lista di controllo per la prossima volta che ti colleghi da un posto che non controlli.
Cosa può davvero vedere il Wi-Fi pubblico
Su una rete che non controlli, due soggetti sono in grado di osservare il tuo traffico. Il primo è il gestore — chi gestisce l'access point e il router dietro di esso, che sul Wi-Fi pubblico significa il locale, il suo fornitore di rete o chiunque abbia installato in silenzio un access point con il nome del locale. Il secondo sono gli altri dispositivi vicini: sulle reti senza isolamento dei client, un portatile due tavoli più in là può catturare il traffico che si muove intorno a sé. «Osservare» significa registrare i pacchetti che invii e ricevi. L'intera questione è cosa contengano quei pacchetti.
- Se il protocollo non è cifrato, i pacchetti contengono il contenuto. Per il desktop remoto è grave quanto sembra: fotogrammi dello schermo, ogni battuta di tasto che invii — comprese le password digitate sulla macchina remota — e, nei peggiori casi datati, le credenziali scambiate al momento della connessione.
- Se il protocollo è cifrato a dovere, i pacchetti contengono testo cifrato. L'osservazione si riduce ai metadati: con quali endpoint hai scambiato traffico, quando e quanto. Abbastanza per dedurre che hai usato un'app di desktop remoto; inutile per recuperare cosa è successo dentro la sessione.
Conviene tarare il giudizio sulla realtà di oggi e non sulle storie dell'orrore del 2010. La maggior parte del traffico che un portatile produce oggi è già cifrata — HTTPS ha tolto il dramma dallo spiare con leggerezza un bar. Le minacce residue realistiche sono l'osservazione dei metadati e gli access point fasulli: un malintenzionato che trasmette il nome di rete del locale per mettersi sul percorso, sperando di intercettare ciò che negozia in modo debole — protocolli vecchi, richieste di certificato accettate alla leggera, dispositivi che si uniscono da soli a nomi familiari. Non è una ragione per temere la rete. È una descrizione precisa di quali strumenti portarci: quelli che non negoziano in modo debole.
I protocolli, ordinati per ciò che perdono
Qui i nomi dei prodotti contano meno delle configurazioni — lo stesso software può andar bene o essere allarmante a seconda di versione e impostazioni, quindi la classifica qui sotto è per configurazione, dalla peggiore.
- RDP semplice senza TLS o NLA (datato). Lo strato di sicurezza originale di RDP precede la moderna sicurezza del trasporto, e un client disposto a negoziarlo può essere trascinato a quel livello da un man in the middle. Le versioni attuali di Windows usano per impostazione predefinita TLS con Network Level Authentication, quindi questo descrive per lo più host vecchi, client vecchi e criteri di gruppo allentati per compatibilità — ma su una rete ostile una sessione che può essere declassata va considerata leggibile.
- VNC senza crittografia. Il protocollo VNC classico invia il framebuffer — il tuo schermo vero e proprio — in chiaro, e il suo tradizionale login challenge-response è debole per gli standard moderni, con password spesso limitate a otto caratteri. Alcuni server e client aggiungono TLS sopra o girano su SSH; molte configurazioni rapide no. Il VNC non cifrato sul Wi-Fi condiviso fa trapelare ciò che c'è sullo schermo a chiunque registri i pacchetti.
- RDP con TLS e NLA. L'impostazione moderna predefinita, e sul cavo regge: la sessione è cifrata nel trasporto dal tuo client all'host o al gateway, e NLA richiede l'autenticazione prima ancora che venga creata una sessione. Sul Wi-Fi pubblico il punto debole pratico è umano — i certificati autofirmati rendono routinari gli avvisi, e un utente abituato a cliccarci sopra è esattamente ciò che spera un access point fasullo. La crittografia del trasporto inoltre non dice nulla sull'esposizione: la porta 3389 aperta su Internet è un errore a parte, ben documentato, da qualunque posto ti colleghi.
- App moderne cifrate end-to-end. Le sessioni sono cifrate da dispositivo a dispositivo prima che qualsiasi rete le tocchi. La rete dell'hotel — e tutto ciò che sta oltre — vede i metadati della connessione: testo cifrato che scorre tra gli endpoint, con tempi e volumi. Mai pixel, mai battute di tasto, mai credenziali, perché non ci sono credenziali di protocollo da rubare.
| Configurazione | Cosa ottiene un osservatore sulla rete | Verdetto sul Wi-Fi pubblico |
|---|---|---|
| RDP semplice, senza TLS/NLA | Il contenuto della sessione dove un declassamento riesce; credenziali a rischio | Non usare — considera tutto leggibile |
| VNC senza crittografia | Contenuto dello schermo in chiaro; stretta di mano di accesso debole | Non usare |
| RDP con TLS + NLA | Testo cifrato in transito; gli avvisi sui certificati sono il punto debole | Accettabile tramite un tunnel; non esporre mai la 3389 |
| App moderna con E2EE | Solo testo cifrato e metadati della connessione | Pensato proprio per questo |
Perché l'E2EE cambia la risposta
La crittografia del trasporto protegge un salto; la crittografia end-to-end protegge la conversazione. La distinzione sembra accademica finché non elenchi chi sta tra un bar e il tuo desktop di casa: l'access point del locale, il suo provider, il tuo provider, magari il server relay di un produttore. Con la crittografia end-to-end le chiavi si concordano direttamente tra i tuoi due dispositivi e i fotogrammi sono cifrati prima ancora di lasciare il dispositivo. Ogni parte di quell'elenco — compresa l'infrastruttura del produttore — inoltra testo cifrato di cui non ha la chiave.
Remio è costruito proprio su questo modello, quindi serve da esempio pratico. La fiducia si stabilisce quando abbini due dispositivi con un codice QR o con un Device ID e un PIN letti dallo schermo dell'host — non c'è un account, quindi non c'è una password su cui fare phishing al bar e nessun database di credenziali da violare da nessuna parte. Le chiavi di sessione sono negoziate direttamente tra i dispositivi abbinati a ogni connessione, e ogni fotogramma, battuta di tasto, sincronizzazione degli appunti e trasferimento di file è cifrato end-to-end. Quando una rete restrittiva costringe la sessione a passare da un relay cifrato, il relay inoltra fotogrammi cifrati che non può leggere — il modello di sicurezza è identico che il percorso sia diretto o via relay. Il progetto completo è nella pagina della sicurezza.
L'obiettivo non è trovare un Wi-Fi affidabile. È rendere irrilevante l'affidabilità del Wi-Fi.
Un limite onesto: la crittografia end-to-end protegge la sessione in transito, e nient'altro. Se il portatile nel bar è compromesso, o lo è l'host a casa, il cifrario più forte tra i due non cambia nulla — l'attaccante è dentro un endpoint e legge ciò che leggi tu. L'igiene degli endpoint, la storia delle violazioni dei produttori e il resto del quadro di protezione sono un altro articolo, e l'abbiamo scritto: la guida alla sicurezza del desktop remoto. Questo resta sulla rete.
La lista di controllo del bar
Sei punti, nell'ordine in cui rendono di più.
- Preferisci un'app di desktop remoto cifrata end-to-end. Risolve la questione del Wi-Fi pubblico per progetto e non per disciplina — la rete trasporta testo cifrato che tu abbia fatto o meno bene qualsiasi altra cosa in questa lista.
- Se sei bloccato con RDP, non esporre mai la porta 3389. Raggiungila tramite una VPN o un altro tunnel cifrato invece che con un port forward sul router; le alternative, comprese le app solo in uscita che non richiedono alcuna modifica al router, sono nella nostra guida al desktop remoto senza port forwarding.
- Lascia che il firewall del sistema tratti la rete come pubblica. Quando macOS o Windows ti chiedono che tipo di rete hai raggiunto, il profilo pubblico è la risposta giusta — impedisce che condivisione file, rilevamento e altri servizi in ascolto siano visibili a sconosciuti sulla stessa rete.
- Tieni aggiornato il client. Un client di desktop remoto analizza dati complessi in arrivo da una rete di cui hai deciso di non fidarti. Le patch esistono per un motivo; su una macchina che viaggia, l'aggiornamento automatico è l'impostazione corretta.
- Verifica di essere sulla vera rete del locale. Chiedi il nome esatto della rete e ignora i sosia — un access point può trasmettere qualsiasi nome il suo proprietario digiti. Dire al portatile di dimenticare la rete quando te ne vai gli impedisce anche di unirsi da solo a un'imitazione il mese prossimo.
- Tratta la sessione stessa come la cosa sensibile. Stai usando la tua macchina di casa o dell'ufficio da una sala pubblica: bada a chi può vedere il tuo schermo e blocca l'host remoto quando ti disconnetti, per non lasciarti alle spalle un desktop aperto.
E una VPN sopra?
Una VPN cifra tutto tra il tuo dispositivo e il server VPN, e sul Wi-Fi non fidato è davvero utile — protegge le ricerche DNS, il chiacchiericcio in background delle app e qualsiasi traffico sparso non cifrato dalla rete locale. Se ne useresti comunque una in aeroporto, nulla del desktop remoto argomenta contro.
Per la sessione di desktop remoto in sé, però, la logica è più ristretta e taglia in entrambi i sensi. Una VPN non è necessaria per una sessione cifrata end-to-end: il traffico è già testo cifrato prima di raggiungere il tunnel, quindi la VPN aggiunge un salto (e di solito un po' di latenza) senza aggiungere una riservatezza che la sessione non abbia. E non è sufficiente per una non cifrata: una VPN commerciale protegge il percorso fino al server di uscita della VPN, dopodiché il traffico prosegue verso l'host esposto com'era partito. L'eccezione che conferma la regola è un tunnel che termina dentro la rete di destinazione stessa — un server WireGuard sul router di casa, una VPN aziendale verso l'ufficio — che copre l'intero percorso ed è il modo standard di usare RDP da remoto. Se stai confrontando una VPN con un'app di desktop remoto come metodo di accesso in sé, è un confronto diverso, e ha un suo articolo: desktop remoto o VPN.
Hotel, aeroporto, campus: le stranezze di rete che rompono le connessioni
Sicurezza a parte, le reti pubbliche hanno un secondo tratto di carattere: rompono le connessioni in modi che le reti di casa non fanno. Tre stranezze ne spiegano la maggior parte.
- Portali di accesso. Finché non apri un browser e accetti le condizioni, la rete inghiotte tutto — un'app di desktop remoto resterà lì a fallire senza una ragione visibile. Completa prima il portale; e se una sessione che ha funzionato tutto il pomeriggio muore alla terza ora, sospetta un portale che si riautentica a tempo.
- Isolamento dei client. Hotel e campus di solito bloccano il traffico da dispositivo a dispositivo dentro la rete, quindi due tuoi dispositivi nella stessa stanza possono essere invisibili l'uno all'altro in LAN. Le app P2P solo in uscita si collegano comunque — entrambi i dispositivi chiamano verso l'esterno e si incontrano su Internet — ma il percorso può essere più lungo della stanza in cui sei seduto.
- Blocco dell'UDP. Le reti ospiti restrittive a volte consentono poco oltre il TCP sulle porte web. I protocolli in tempo reale preferiscono l'UDP, ed è qui che le app si distinguono: una con ripiego su TCP e relay continua a collegarsi, con un certo costo in latenza, mentre una configurazione solo UDP si blocca. I meccanismi — scoperta degli indirizzi, hole punching e cosa subentra quando — sono nella nostra spiegazione del NAT traversal, e le porte e i protocolli esatti che usa una sessione sono nella documentazione su firewall e NAT.
Domande frequenti
È sicuro usare il desktop remoto sul Wi-Fi dell'hotel?
Sì, se la sessione è cifrata end-to-end. Con un'app moderna di desktop remoto con E2EE, la rete dell'hotel trasporta solo testo cifrato, quindi né il gestore né gli altri ospiti possono recuperare il tuo schermo, le tue battute di tasto o i tuoi file. Il caso rischioso sono le configurazioni datate: RDP senza TLS e NLA, o VNC senza crittografia, possono esporre alla rete contenuto della sessione e credenziali e non vanno usati sul Wi-Fi dell'hotel senza un tunnel cifrato.
Qualcuno sullo stesso Wi-Fi può vedere il mio schermo remoto?
Non se la sessione è cifrata end-to-end. Qualcuno sulla stessa rete può catturare i tuoi pacchetti, ma con l'E2EE quei pacchetti sono testo cifrato e le chiavi esistono solo sui tuoi due dispositivi, quindi il contenuto dello schermo non è recuperabile dalla cattura. Ciò che un osservatore sulla stessa rete può comunque vedere sono i metadati — che esiste una connessione, quando è attiva e più o meno quanti dati sposta.
Mi serve una VPN per usare Remio sul Wi-Fi pubblico?
No. Le sessioni di Remio sono già cifrate end-to-end — le chiavi sono negoziate direttamente tra i tuoi dispositivi a ogni sessione — quindi la sessione non dipende dall'affidabilità della rete. Una VPN aggiunge comunque privacy al resto del tuo traffico, come le ricerche DNS e le altre app, e usare Remio attraverso una VPN va bene. È una scelta sul tuo altro traffico, non un requisito per la sessione.
RDP è sicuro sul Wi-Fi pubblico?
Con TLS e Network Level Authentication — l'impostazione predefinita moderna di Windows — la sessione è cifrata nel trasporto, quindi chi origlia sulla rete del bar vede testo cifrato. La regola fissa riguarda l'esposizione e non il locale: non aprire mai la porta 3389 direttamente su Internet; raggiungi RDP tramite una VPN o un altro tunnel cifrato. Le vecchie configurazioni che possono essere declassate alla sicurezza RDP datata senza TLS vanno considerate non sicure su qualsiasi rete non fidata.
Cosa viene comunque a sapere il gestore del Wi-Fi?
I metadati della connessione. Anche con una sessione completamente cifrata end-to-end, il gestore della rete può osservare tempi, volume di traffico e gli endpoint con cui scambi pacchetti — abbastanza per dedurre che c'è stata una sessione di desktop remoto e quanto è durata. Ciò che non può recuperare è il contenuto: niente fotogrammi dello schermo, niente battute di tasto, niente file, niente appunti.
Il filo di tutto: non è il locale a decidere se la tua sessione è sicura — è la crittografia. Se vuoi la versione che non richiede alcuna lista di controllo, installa Remio su entrambe le macchine, abbinale con un codice QR o con un Device ID e un PIN e collegati da qualunque rete ti offra la giornata; la sessione è cifrata end-to-end in ogni caso. La pagina come funziona mostra cosa succede sotto il cofano.
