La prima volta che le persone usano una VPN, la prima cosa che vedono è “quanto siamo veloci”. E se “siamo molto veloci, “siamo inclini” a pensare che “abbiamo a che fare con un buon prodotto, che produce poche spese generali.
Questo ha alcuni inconvenienti. Ad esempio, potresti creare una VPN che offusca solo il traffico con un rot(13) e sarebbe davvero molto veloce. Il guaio è che poi, usandolo, gli amministratori di sistema di tutto il mondo e tutti gli addetti alla sicurezza si renderebbero conto che la VPN è veloce perché fa ben poco.
Ma un altro modo per nascondere la perdita di prestazioni sarebbe farlo funzionare in modalità supervisore, come parte del kernel. Ancora una volta, VPN sembra produrre poca latenza. Ma questo sarebbe un trucco, a cui gli amministratori di sistema senior risponderebbero con un’alzata di spalle.
Detto questo, non me ne frega niente di quanto sia veloce o di quanta poca latenza abbia. Funziona in modalità kernel, altre VPN no, quindi non posso confrontare. Incorporare la VPN nel kernel è stato un trucco intelligente, ma dura tanto quanto.
Quindi ora ho bisogno di un KPI per decidere quanto sia sicura questa VPN, un KPI che non è il solito “quanto è robusto il tuo algoritmo”. Il mondo è pieno di algoritmi di crittografia molto robusti, ma gli incidenti accadono ancora. Come mai?
Perché in modo più o meno indiretto, i computer sono sistemi gestiti dall’uomo. E sebbene gran parte del compito di amministrazione sia automatizzato, quando si tratta di configurare e impostare apparati che forniscono sicurezza, il personale IT è la pietra angolare dell’infrastruttura.
Ma cosa significa che “l’essere umano è la pietra angolare dell’infrastruttura”?
Significa che gli esperti di sicurezza IT trascorrono del tempo a leggere i registri, a inserirli in database speciali in cui i sistemi automatizzati creano avvisi quando vedono cose sbagliate, magari attirando l’attenzione degli operatori umani quando qualcosa non va.
Gli operatori umani, a loro volta, devono capire cosa sta andando storto, perché sta andando storto e da lì trovare una soluzione.
Quando si parla di sicurezza si parla sempre di OSSERVABILITA’.
I gestori di sistema hanno bisogno dell’osservabilità per capire cosa sta andando storto, per sapere PERCHE’ sta andando storto, per sapere se si tratta di un attacco o di un malfunzionamento, per sapere se coincide con un modello di minaccia e così via.
Naturalmente, ora dovremo chiederci qual è esattamente l’osservabilità di Wireguard. E la risposta è che, anche quando lo mettiamo in modalità “debug”, l’osservabilità è assente, incompetente e del tutto inutile.
Guarda questo:
Come ho ottenuto questo? Non ne ho idea. Non ne ho idea perché si tratta di due macchine virtuali identiche che ho configurato seguendo la stessa procedura, che produce un file wg0.conf corretto.
E dico corretto perché l’unico strumento che posso usare, “wg”, lo legge e lo configura correttamente per me. (Ovviamente gli IP e le chiavi sono diversi per macchina, ecc ecc).
Da parte mia, ovvero da parte del cliente, non c’è nulla che possa migliorare. I due file sono identici, cambiano solo le chiavi pubbliche e gli IP del client. (ovviamente). Una macchina virtuale funziona, una no.
Idem sul lato server. In cui l’unica cosa che so è che WG comprende il peer, ma poi “Iniziazione stretta di mano non valida”.
Ma soprattutto, leggendo quei registri, COSA è esattamente non valido in “avvio della stretta di mano”? Cosa c’è che non va?
Se dovessi dare l’allarme a uno specialista, cosa alzerei? Non ci sono le chiavi giuste? Il checksum del pacchetto UDP non è valido? Sappiamo? No. Il messaggio di registro non dice nulla. Infine, al reparto IT viene chiesto di chiamare qualcuno e dire “qualcosa di non specificato sta andando storto”. La cosa peggiore che puoi dire a una persona in servizio notturno. La cosa peggiore MAI.
Quindi ti chiedi cosa potrebbe esserci di sbagliato in un pacchetto UDP e prima decidi di controllare il checksum.
Quindi farai un bel tcpdump e vedrai che (perché ce ne sono altri che usano la VPN) alcuni pacchetti hanno il checksum giusto e altri quello sbagliato: dovresti capire quale pacchetto si lamenta del log. Ma il registro non dice. È necessario disconnettere l’intera base di utenti e riprovare con un solo utente. Ma ovviamente non puoi.
La prima tentazione a cui NON dovresti cedere è disabilitare il controllo del checksum dei pacchetti UDP. Non sai se è questo il problema, e in ogni caso non è una buona pratica. Allora come si fa a prevenire qualcosa che non si capisce?
Eccoci al punto. Chiunque abbia lavorato nell’IT per molti anni sa che, per la maggior parte, i problemi di sicurezza non sono problemi sui livelli da 1 a 7. Sono problemi di sicurezza sul livello 8: sono cose che gli umani hanno sbagliato, sono cose che gli umani non hanno capito, o hanno configurato male.
Oppure è una reazione a un problema che si rivela peggiore del previsto, oppure è un presupposto sbagliato.
I sistemi che si occupano della sicurezza perimetrale, quindi, devono mitigare il più possibile il rischio che gli amministratori facciano la cosa sbagliata. Devono chiarire cosa sta succedendo. Devono chiarire perché sta succedendo qualcosa. Devono dare il controllo. Devono essere osservabili.
Ma wireguard non può. Ovviamente, lavorando a livello di kernel, non possono permettersi di avere un logging molto esteso, abbastanza da consentire un’osservabilità invadente. Di conseguenza, gli amministratori sono spinti a decisioni ignoranti: quale impostazione migliora la validità dell'”avvio della stretta di mano”? Chi lo sa?
Nessun sistema che non è osservabile è sicuro, perché non consente alle persone che lo supervisionano di sapere esattamente cosa sta succedendo.
Non mi interessa quanto sia robusto l’algoritmo. Non infastidirmi con quello. Non mi interessa nemmeno quanto sia robusta la stretta di mano. Non me ne frega niente.
Non mi interessa, perché essendo inosservabile e registrando pochissimo, wireguard:
- indebolisce gli amministratori di sistema
- indebolisce il sistema allarmante
- indebolisce la risposta del team di sicurezza.
Anche se gli algoritmi di crittografia fossero i più letali al mondo, avrebbero un costo inaccettabile: quello di accecare il team di sicurezza dell’azienda, o almeno l’amministratore di sistema.
E questo, in un sistema VPN, ovvero la sicurezza perimetrale, è semplicemente INACCETTABILE.
Wiregard è insicuro, perché tutto ciò che guadagna in semplicità di implementazione e prestazioni, perde in osservabilità.
È come mettere una porta di sicurezza, che è super resistente ma richiede di trasformare il resto della casa in una tenda da campeggio. Hai una porta super forte e il resto ora è debole. Allo stesso modo, usando wireguard, avrai un robusto algoritmo di crittografia, ma il resto della tua sicurezza aziendale o personale sarà sparito, perché non hai idea di cosa stia succedendo e perché.
Ancora non capisco perché Torvalds abbia accettato di inserire questa truffa nel kernel
