Tailscale è sicuro? Il modello di attendibilità

La sicurezza di Tailscale: risposta breve

Tailscale è sicuro? Per l'aspetto che preoccupa la maggior parte delle persone, sì: il server di coordinamento che gestisce il tuo tailnet non conserva le chiavi private usate per cifrare il traffico, quindi non può leggere ciò che i tuoi dispositivi si inviano. La pagina sulla sicurezza di Tailscale lo dichiara esplicitamente: «Le chiavi private non lasciano mai il dispositivo. Tutto il traffico è cifrato end-to-end, sempre». La domanda utile è un'altra. Un server di coordinamento compromesso o soggetto a un ordine giudiziario non deve necessariamente leggere i tuoi pacchetti. Decide quali chiavi pubbliche vengono considerate attendibili dai tuoi dispositivi, quindi potrebbe registrare un dispositivo che non hai mai approvato.

Questo è il modello di attendibilità in una frase: la cifratura protegge i dati, mentre il piano di controllo decide chi fa parte della rete. Ogni sezione seguente identifica una parte di cui devi fidarti, spiega che cosa può effettivamente fare e indica il controllo che ne limita i poteri. Se il prodotto ti è nuovo, inizia da che cos'è Tailscale e come funziona la sua rete mesh.

Il piano di controllo e il piano dati sono separati

Tailscale è una VPN mesh (rete privata virtuale) basata su WireGuard, lo stesso protocollo che configureresti manualmente su un VPS WireGuard self-hosted. Ogni dispositivo genera localmente la propria coppia di chiavi WireGuard. L'articolo come funziona di Tailscale definisce il server di coordinamento "un contenitore condiviso per le chiavi pubbliche" e afferma: "La chiave privata non lascia mai, in nessun caso, il proprio nodo."

Il piano dati è il traffico crittografato tra i dispositivi. Il traffico passa direttamente da un dispositivo all'altro, quando la rete lo consente. Il piano di controllo comprende tutto il resto: quali dispositivi appartengono al tailnet, quale chiave pubblica corrisponde a ciascun dispositivo, i criteri di accesso, le impostazioni DNS e l'elenco dei relay. Tailscale fornisce il piano di controllo come servizio hosted. Il piano dati viene eseguito sulle tue macchine.

Mantieni separati questi due piani e ogni questione di sicurezza diventa verificabile. La crittografia è una proprietà del piano dati. L'appartenenza alla rete è una decisione del piano di controllo. Nessun livello di crittografia può indicare chi è autorizzato a essere un peer.

Che cosa potrebbe fare un server di coordinamento compromesso?

Non potrebbe decrittografare il traffico. Le chiavi che eseguono la cifratura vengono generate sui dispositivi e non vengono mai caricate sul server. Non esiste quindi nulla da sottrarre o divulgare per aprire il tunnel. Questo vale anche per il traffico inoltrato, descritto più avanti.

Potrebbe registrare un nodo. Quando Tailscale ha annunciato tailnet lock, l'azienda ha descritto il rischio con queste parole: un server dannoso potrebbe «usare un nodo aggiunto di nascosto per inviare o ricevere traffico dai nodi esistenti» e, a quel punto, «non importerebbe che il traffico sia cifrato, perché il peer stesso sarebbe dannoso». Il dispositivo considera attendibile un peer perché il control plane gli comunica che quella chiave appartiene alla tailnet.

Potrebbe modificare le destinazioni raggiungibili dai dispositivi. La policy di accesso risiede nel control plane e viene distribuita ai nodi. Il white paper di tailnet lock di Tailscale afferma che tailnet lock «non impedisce a un control plane compromesso di interrompere la connettività nella rete, ad esempio omettendo di distribuire le chiavi dei nuovi nodi oppure distribuendo una policy di controllo degli accessi che nega l'accesso a tutti i nodi».

Vedrebbe comunque i metadati delle connessioni. I log dei flussi di rete di Tailscale registrano gli eventi di apertura e chiusura per ogni connessione tra macchine. La documentazione specifica che questi log «non contengono in alcun caso informazioni sulle operazioni eseguite dai client o sul contenuto del traffico di rete». Il control plane può quindi sapere quali dispositivi hanno comunicato tra loro e in quale momento. Non sa che cosa si sono detti.

Solo un elemento dell'elenco riguarda la cifratura. Gli altri riguardano i membri della tailnet e il contenuto della policy. Per questo, i controlli più importanti sono quelli che regolano la registrazione dei nodi.

Il tuo provider di identità è la radice di attendibilità della tailnet

Tailscale non gestisce un proprio database delle password. La documentazione specifica chiaramente che non esistono password Tailscale e che l'accesso viene delegato a un provider di identità (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin o un provider OpenID Connect personalizzato.

Consideralo un requisito di sicurezza, perché lo è. Chiunque possa accedere al tuo account Google o Microsoft può accedere alla tua tailnet. L'autenticazione a più fattori (MFA) è quella applicata dall'IdP. La procedura di revoca degli accessi quando una persona lascia l'organizzazione dipende da ciò che fa l'IdP. Un account IdP compromesso equivale a un account della tailnet e l'attaccante non deve attaccare WireGuard: aggiunge un dispositivo e ottiene tutti i privilegi concessi dalla policy a quell'utente.

Tra un account di identità sottratto e un dispositivo funzionante nella tailnet ci sono due controlli: l'approvazione del dispositivo e la scadenza delle chiavi. Tailnet lock è un terzo controllo, rivolto al control plane anziché all'account.

Approvazione dei dispositivi: nessuno accede finché una persona non autorizza

La documentazione di Tailscale descrive l'approvazione dei dispositivi come una funzionalità che «consente agli amministratori della rete Tailscale di esaminare e approvare i nuovi dispositivi prima che possano accedere alla rete Tailscale». Possono approvare un dispositivo un Owner, un Admin o un IT admin. Finché qualcuno non interviene, nella pagina Machines il nuovo dispositivo mostra il badge «Needs approval».

Attivando questa funzionalità, lo scenario di un account sottratto cambia. L'aggressore accede, il dispositivo viene registrato e poi resta in attesa, senza poter raggiungere alcuna risorsa. Nella console di amministrazione compare il badge che segnala la richiesta di accesso di una macchina non riconosciuta. L'automazione continua a funzionare, perché quando generi una auth key puoi contrassegnarla come pre-approved e puoi approvare i dispositivi tramite API.

Le auth key sono l'altro punto di accesso, quindi devono essere trattate come credenziali. La documentazione di Tailscale è esplicita sul tipo più rischioso: «Presta molta attenzione alle chiavi riutilizzabili. Possono essere molto pericolose se vengono sottratte. È preferibile conservarle in un prodotto di gestione delle chiavi progettato specificamente a questo scopo». Ad agosto 2026, l'intervallo documentato per la scadenza delle chiavi è compreso tra 1 e 90 giorni; se la scadenza non viene specificata, viene usato il valore massimo di 90 giorni. Preferisci chiavi monouso, contrassegnale come ephemeral per le macchine temporanee e conserva ogni chiave riutilizzabile crittografata con Ansible Vault o in un secrets manager, non in uno shell script.

Scadenza delle chiavi: il timer che limita ogni altro errore

Le chiavi dei nodi scadono. Questo trasforma un dispositivo rubato o dimenticato in un problema temporaneo. La documentazione di Tailscale afferma che «per impostazione predefinita, i nuovi domini sono configurati con un periodo di scadenza di 180 giorni» e che «se non viene eseguita la riautenticazione, le chiavi scadono e le connessioni da e verso l'endpoint interessato smettono di funzionare». È possibile riautenticare manualmente un dispositivo:

tailscale up --force-reauth

La documentazione avverte che questa operazione «potrebbe interrompere la connessione tailnet e quindi non deve essere eseguita da remoto tramite SSH o RDP senza un metodo alternativo per accedere al sistema se la connessione viene persa». Eseguila con l'accesso alla console già aperto oppure da un secondo percorso di accesso alla macchina, perché stai per interrompere la rete che stai utilizzando.

I server sono il caso in cui questo controllo viene spesso disattivato. Una macchina che deve riautenticarsi ogni 180 giorni uscirà dalla tailnet alle 3 di notte, quando nessuno la controlla. Per questo gli amministratori disabilitano la scadenza delle chiavi. Così viene rimosso il timer che alla fine bloccherebbe una chiave rubata. Per un server, un dispositivo con tag è una soluzione migliore: il tag identifica la macchina invece di una persona, quindi la macchina continua a funzionare anche se quella persona lascia l'azienda. Qualunque sia la scelta, mantieni un elenco delle macchine per cui la scadenza è disabilitata: queste chiavi restano valide finché non elimini il dispositivo.

Tailnet lock: rimuovere il server di coordinamento dalla catena di trust

Tailnet lock affronta direttamente il problema dell’enrolment. La documentazione di tailnet lock di Tailscale descrive il meccanismo: «Quando un nuovo nodo entra nel tailnet, la sua chiave pubblica del nodo richiede una firma da una chiave Tailnet Lock. Il server di coordinamento distribuisce la chiave pubblica del nodo firmata ai nodi peer». I dispositivi esistenti verificano la firma prima di accettare un peer, quindi rifiutano una chiave del nodo generata autonomamente dal control plane.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init abilita la funzionalità e in quel momento si designano i nodi firmatari. Tailscale richiede almeno due nodi firmatari durante l’inizializzazione e ne consente al massimo 20 in un tailnet. In seguito, ogni nuovo dispositivo richiede una firma da parte di uno di questi nodi. Questo comporta un costo operativo concreto: per aggiungere un telefono è necessario eseguire un comando su un laptop.

I limiti sono documentati e sono più importanti della descrizione della funzionalità:

• Se si perde il secret per disabilitare la funzionalità, non esiste alcun recupero. La documentazione afferma: «Se perdi i secret per disabilitare la funzionalità e non ne hai fornito uno al supporto Tailscale, il tailnet non può essere recuperato».
• La chiave di firma risiede su un dispositivo di cui si ha il controllo, quindi eredita il livello di sicurezza di quel dispositivo. La documentazione è esplicita: «Se il dispositivo è compromesso, la chiave può essere ottenuta».
• Non è possibile usare entrambi i controlli. Tailscale specifica che tailnet lock e l’approvazione dei dispositivi sono mutuamente esclusivi. Abilitare una funzionalità significa quindi rinunciare all’altra.
• Si tratta di trust on first use (TOFU). La configurazione iniziale passa comunque dal control plane e il punto di ancoraggio del trust si sposta nella propria rete solo dopo questo primo passaggio.

Tailnet lock protegge l’appartenenza al tailnet. Non protegge la disponibilità, come afferma il white paper.

Una connessione inoltrata espone il mio traffico?

No. Quando due dispositivi non possono raggiungersi direttamente, il traffico passa a un server DERP (Designated Encrypted Relay for Packets). La documentazione di Tailscale descrive questa proprietà senza ambiguità: «Poiché le chiavi private di Tailscale non lasciano mai il dispositivo locale che le ha generate, per un server DERP è impossibile decrittografare il traffico. Un server DERP inoltra senza analizzarlo il traffico già crittografato da un dispositivo all'altro».

Un relay riduce comunque la velocità e osserva i metadati: due endpoint crittografati, oltre alla temporizzazione e al volume dei dati che passano tra loro. Verifica quale tipo di connessione è effettivamente in uso:

tailscale status
tailscale netcheck

tailscale status contrassegna ogni peer come diretto, indicato da direct 203.0.113.10:41641, oppure inoltrato, indicato da relay seguito dal nome del relay e dai contatori dei byte. Se un peer rimane su un relay, significa che i due endpoint non hanno potuto stabilire un percorso diretto, in genere perché UDP è bloccato da qualche parte oppure perché entrambi si trovano dietro un NAT (network address translation) restrittivo. tailscale netcheck indica se UDP funziona dalla macchina, come il NAT esegue il mapping delle porte e la latenza verso i relay più vicini. Questi dati permettono di capire quale delle due cause si applica.

Un exit node sposta il punto di uscita, ma non lo elimina

Un exit node instrada tutto il traffico Internet pubblico di un dispositivo attraverso un altro dispositivo della tailnet, usando le route predefinite 0.0.0.0/0 e ::/0. Su Linux, la macchina che offre il servizio lo pubblicizza e ogni client sceglie se utilizzarlo:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Un exit node deve essere approvato da un Owner, Admin o Network admin nella console di amministrazione, e la policy deve concedere autogroup:internet prima che un client possa utilizzarlo. Entrambi i passaggi sono intenzionali: una macchina non approvata non può diventare silenziosamente il punto di uscita dell'intera tailnet.

Resta la questione della fiducia. Il traffico è cifrato dal laptop all'exit node. Poi esce da quella macchina come normale traffico Internet, usando l'indirizzo IP della macchina. Di conseguenza, l'operatore dell'exit node vede le destinazioni, così come il provider di hosting della macchina e la rete upstream a cui è collegata. Hai spostato il punto di osservazione, non lo hai eliminato. È una scelta valida quando controlli l'estremità remota, che è il motivo per eseguire il proprio exit node su un VPS, e una scelta poco adatta quando non la controlli.

La policy predefinita è una rete piatta

Un nuovo tailnet viene fornito con una configurazione permissiva. La documentazione sul controllo degli accessi di Tailscale specifica che il file di policy predefinito «abilita la comunicazione tra tutti i dispositivi del tailnet». Ogni dispositivo può raggiungere tutti gli altri dispositivi su qualsiasi porta. Questa è una rete piatta. Il traffico è stato spostato all'interno del tunnel, una misura utile contro gli utenti esterni, ma inefficace se viene infettato un laptop.

È possibile applicare restrizioni nel file di policy del tailnet, che supporta gli elenchi di controllo degli accessi (ACL) e i nuovi grants. Entrambi usano un dialetto JSON che consente i commenti:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Questa policy consente a un gruppo di raggiungere il servizio SSH sui server di produzione, permette ai membri di usare un exit node e nega tutto il resto per omissione. Tailscale indica quali destinazioni delle regole sono disponibili per ciascun piano. Verifica queste informazioni prima di progettare la configurazione usando tag o autogroups e consulta cosa include effettivamente il piano gratuito. Per un dispositivo che non deve mai accettare connessioni in ingresso, ad esempio un telefono personale, tailscale set --shields-up le blocca sul client.

Cosa cambia con il control plane self-hosted di Headscale

Headscale è «un’implementazione open source e self-hosted del server di controllo Tailscale». Il README ne definisce chiaramente l’ambito: «implementa un ambito ristretto, una singola rete Tailscale (tailnet), adatta all’uso personale o a una piccola organizzazione open source». L’elenco delle funzionalità comprende ACL e grants, subnet router, exit node, un server DERP integrato, Tailscale SSH e Taildrop. Se questo ambito ristretto è il principale limite, NetBird è l’altra mesh che distribuisce un control plane self-hostable; eseguire il server NetBird sul proprio VPS sposta la stessa decisione sull’enrolment su hardware di propria proprietà.

Cambia l’identità del soggetto che potrebbe effettuare l’enrolment di un nodo non autorizzato. Con Headscale, la directory delle chiavi e le policy risiedono sul proprio server. Nessun soggetto terzo conserva l’elenco delle chiavi pubbliche dei dispositivi e nessun soggetto terzo può essere obbligato a consegnarne una o ad autorizzarne una.

Il data plane non cambia. È lo stesso WireGuard, con la stessa crittografia end-to-end e lo stesso fallback tramite relay quando non è possibile stabilire un percorso diretto. Si ereditano inoltre le attività che prima gestiva Tailscale: garantire l’operatività, applicare le patch, eseguire i backup e proteggere fisicamente il server. Un host Headscale compromesso offre a un attaccante esattamente ciò che offrirebbe un server di coordinamento compromesso: la possibilità di effettuare l’enrolment di un nodo e distribuire policy. Tailnet lock non è incluso nell’elenco delle funzionalità di Headscale, quindi il controllo compensativo per questo rischio specifico non è disponibile. Se la questione della proprietà è quella decisiva, self-hosting del control plane con Headscale illustra la procedura di configurazione.

Da cosa protegge Tailscale

• Porte in ascolto pubbliche. Un servizio associato a un indirizzo tailnet non è raggiungibile da Internet, quindi gli scanner che contattano ogni VPS sulla porta 22 non lo rilevano. L’eccezione è una funzione che abiliti personalmente: Funnel pubblica intenzionalmente un servizio tailnet su Internet aperto. Per questo è utile sapere dove finisce serve e dove inizia funnel prima di eseguire uno dei due comandi. Mantieni comunque attivo il firewall dell’host, perché una porta Docker pubblicata crea regole proprie e aggira ufw sull’interfaccia pubblica.
• Tentativi di indovinare le password contro gli accessi esposti. Se la porta risponde soltanto all’interno del tunnel, non c’è nulla da sottoporre a tentativi ripetuti. È una posizione più solida rispetto all’applicazione del rate limiting su una porta aperta, anche se fail2ban su Ubuntu 24.04 resta utile per tutto ciò che deve rimanere pubblico.
• Reti non attendibili lungo il percorso. Il traffico tra le macchine è cifrato end-to-end quando attraversa la rete di un caffè o la LAN condivisa di un provider, e rimane cifrato anche quando viene inoltrato tramite un relay.
• Distribuzione manuale delle chiavi. Ogni peer aggiunto manualmente a una configurazione WireGuard può causare il riutilizzo di un indirizzo o l’inserimento della chiave errata. La mesh gestisce questi dati al posto tuo. Questa è gran parte della differenza pratica descritta in WireGuard rispetto a Tailscale.

Cosa non protegge Tailscale

• Un endpoint compromesso. La tailnet considera attendibili i dispositivi. Un malware presente su un laptop approvato ottiene il tunnel, gli indirizzi della tailnet e tutto ciò che la policy concede a quell'utente. Questa è la lacuna principale e nessuna VPN può eliminarla.
• Un amministratore malevolo o negligente. Chiunque possa modificare il file della policy può concedersi l'accesso a qualsiasi risorsa. Lo stesso vale per chi riesce a compromettere l'account di identità di un Owner. Esaminate le modifiche alla policy come esaminereste il codice.
• L'analisi del traffico. Il vostro ISP (internet service provider) vede pacchetti UDP crittografati diretti a un endpoint, oltre a tempi e volumi del traffico. I log dei flussi di Tailscale mostrano quali peer hanno comunicato e quando. Nessuno dei due vede il contenuto, ma il fatto che esista una connessione non è nascosto. Prima di scegliere uno strumento per questo scopo, leggete come differiscono Tor e una VPN.
• Un dispositivo che avete già perso. La scadenza della chiave è una misura di sicurezza lenta, con un valore predefinito di 180 day. Rimuovere il dispositivo dalla console di amministrazione è l'intervento rapido. Verificate quindi dove si trova quel pulsante prima di averne bisogno.

Verifica la tua tailnet

1. Esegui tailscale status su un dispositivo e leggi l'elenco dei peer. Una macchina che non sai identificare è esattamente la situazione che l'approvazione dei dispositivi deve impedire.
2. Esegui tailscale lock status per verificare se tailnet lock è abilitato, quindi valuta se il costo della firma di ogni nuovo dispositivo è giustificato per la tua tailnet.
3. Apri la console di amministrazione e annota ogni macchina con la scadenza della chiave disabilitata, oltre a ogni chiave di autenticazione riutilizzabile ancora esistente. Entrambe sono credenziali senza un limite temporale.
4. Leggi il file delle policy. Se è ancora quello predefinito, ogni dispositivo può raggiungere tutti gli altri dispositivi su ogni porta e un laptop infetto può raggiungerli tutti.

Tailscale si è guadagnato la propria reputazione sul piano dati, dove il design non consente all'operatore di leggere il traffico. Considera questa affermazione nei termini descritti dal fornitore, quindi verifica le parti che dipendono da te: gli account di identità, l'impostazione di approvazione, l'elenco delle scadenze e il file delle policy. La pagina sulla sicurezza di Tailscale riporta una certificazione SOC 2 Type II e attività di sicurezza in corso con Latacora. Questo costituisce una prova del loro processo, non una dichiarazione sulla configurazione del tuo ambiente.

FAQ

Tailscale può leggere il mio traffico?

No. Il traffico è cifrato con chiavi WireGuard generate sui tuoi dispositivi e la pagina sulla sicurezza di Tailscale afferma che "le chiavi private non lasciano mai il dispositivo. Tutto il traffico è sempre cifrato end-to-end". Questo vale anche per le connessioni che usano un relay DERP, perché il relay "inoltra alla cieca traffico già cifrato da un dispositivo all'altro" e non possiede alcuna chiave che gli permetta di decifrarlo. L'infrastruttura Tailscale vede invece i metadati: quali dispositivi esistono, quali si sono connessi tra loro e quando.

Che cosa potrebbe fare concretamente un server di coordinamento Tailscale compromesso?

Potrebbe registrare un nodo. L'annuncio del tailnet lock di Tailscale descrive il rischio di un nodo aggiunto di nascosto che potrebbe "inviare o ricevere traffico dai nodi esistenti", perché la cifratura non protegge "quando il peer stesso è malevolo". Un control plane compromesso potrebbe anche distribuire una policy che modifica le destinazioni raggiungibili dai dispositivi e, secondo il white paper sul tailnet lock, potrebbe interrompere la connettività evitando di distribuire le nuove chiavi dei nodi. Non potrebbe invece decifrare il traffico tra i dispositivi esistenti, perché non ha mai posseduto le relative chiavi private.

Un exit node nasconde la mia navigazione al mio ISP?

Nasconde le destinazioni alla rete da cui ti connetti, incluso l'ISP di casa o del bar, perché tutto il traffico lascia il dispositivo cifrato e indirizzato all'exit node. Non ti rende anonimo. Le destinazioni sono visibili invece all'exit node, al suo provider di hosting e alla rete upstream, mentre i siti visitati vedono l'indirizzo IP dell'exit node. Hai scelto un osservatore diverso, quindi scegline uno di cui ti fidi realmente.

Headscale è più sicuro del server di coordinamento Tailscale?

È una scelta di trust diversa, non necessariamente più sicura. Con Headscale gestisci tu la directory delle chiavi e la policy, quindi nessun soggetto esterno può essere obbligato a registrare un dispositivo nel tuo tailnet. Devi però gestire anche quel server: patching, disponibilità, backup e sicurezza dell'host stesso. Un host Headscale compromesso offre a un attaccante lo stesso potere di registrazione che avrebbe un server di coordinamento compromesso. Inoltre, tailnet lock non è incluso nell'elenco delle funzionalità di Headscale, quindi devi proteggere quell'host di conseguenza.

Devo comunque usare un firewall su un VPS che appartiene al mio tailnet?

Sì. L'interfaccia di rete pubblica esiste ancora e qualsiasi servizio associato a 0.0.0.0 resta raggiungibile da Internet, indipendentemente dal fatto che Tailscale sia in esecuzione. Associa i servizi all'indirizzo del tailnet, mantieni una policy predefinita di deny sull'interfaccia pubblica e controlla le porte pubblicate dei container, perché Docker inserisce regole proprie e può esporre una porta che ritenevi chiusa.