Negli ultimi tempi, WireGuard ha attirato molta attenzione, è infatti la nuova "stella" tra VPN. Ma è davvero così buono come sembra? Vorrei discutere alcune osservazioni e analizzare l'implementazione di WireGuard per spiegare perché non rappresenta una soluzione in grado di sostituire IPsec o OpenVPN.
In questo articolo, desidero sfatare alcuni miti [intorno a WireGuard]. Sì, dovrai leggere a lungo, quindi se non hai ancora preparato una tazza di tè o caffè, è il momento di farlo. Vorrei anche ringraziare Peter per aver corretto i miei pensieri confusi.
Non ho intenzione di screditare gli sviluppatori di WireGuard, né di svalutare i loro sforzi o idee. Il loro prodotto è funzionante, ma personalmente ritengo che sia presentato in modo completamente diverso da ciò che è — presentato come una sostituzione di IPsec e OpenVPN, che in realtà non esiste al momento.
A titolo di nota, ci tengo a sottolineare che la responsabilità per tale posizionamento di WireGuard ricade sui media che ne hanno parlato, e non sul progetto stesso o sui suoi creatori.
Recentemente, non ci sono state molte buone notizie riguardo al kernel Linux. Ci hanno parlato di gravi vulnerabilità della CPU che sono state mitigate attraverso software, e Linus Torvalds ha discusso l'argomento in modo piuttosto secco e noioso, usando il linguaggio utilitaristico degli sviluppatori. Temi come il pianificatore o lo stack di rete a livello zero non sono molto comprensibili nemmeno per le riviste di moda. E qui entra in gioco WireGuard.
Sulla carta, tutto sembra eccezionale: una nuova tecnologia che cattura l'immaginazione.
Ma diamo un'occhiata più da vicino.
Documentazione tecnica di WireGuard
Questo articolo si basa su documentazione ufficiale di WireGuard, scritta da Jason Donenfeld. Qui spiega il concetto, l'obiettivo e l'implementazione tecnica di [WireGuard] nel kernel Linux.
La prima frase dice:
WireGuard […] mira a sostituire IPsec nella maggior parte dei suoi casi d'uso, così come altre soluzioni popolari basate su spazio utente e/o TLS, come OpenVPN, risultando così più sicuro, performante e facile da usare [strumento].
Naturalmente, il principale vantaggio di tutte le nuove tecnologie è la loro semplicità [rispetto ai predecessori]. Ma un VPN deve anche essere efficace e sicuro.
E poi?
Se dici che hai bisogno di qualcosa di diverso da [VPN], allora puoi smettere di leggere qui. Tuttavia, osserverò che simili sfide si pongono a qualsiasi altra tecnologia di tunneling.
La cosa più interessante nella citazione sopra risiede nelle parole "nella maggior parte dei casi", che, naturalmente, sono state ignorate dalla stampa. E così, ci troviamo qui a causa del caos creato da questa negligenza — in questo articolo.
WireGuard diventerà una sostituzione per la mia connessione VPN [IPsec] tra siti?
No. Semplicemente non ci sono possibilità che grandi fornitori come Cisco, Juniper e altri adottino WireGuard nei loro prodotti. Non "saltano su treni che passano" se non c'è una grande necessità. Più tardi parlerò di alcune ragioni per cui è probabile che non possano integrare WireGuard nei loro prodotti, anche se volessero.
WireGuard trasferirà il mio RoadWarrior dal laptop al data center?
No. Attualmente WireGuard non implementa molte funzioni importanti per poter svolgere un compito simile. Ad esempio, non può utilizzare indirizzi IP dinamici sul lato server del tunnel, e già solo questo compromette l'intero utilizzo del prodotto.
IPFire è spesso utilizzato per connessioni internet a basso costo, come DSL o connessioni via cavo. Ha senso per piccole o medie imprese che non necessitano di una connessione in fibra veloce. [Nota del traduttore: non dimenticate che in termini di connettività la Russia e alcuni paesi della CSI sono molto avanti rispetto all'Europa e agli USA, perché abbiamo iniziato a costruire le nostre reti molto più tardi e, con l'avvento dell'Ethernet e delle reti in fibra ottica come standard, è stato più semplice ristrutturarsi. In paesi dell'UE o negli USA, l'accesso broadband xDSL a velocità di 3-5 Mbit/s è ancora la norma, mentre la connessione in fibra ottica costa somme irragionevoli secondo i nostri parametri. Ecco perché l'autore dell'articolo parla di connessioni DSL o via cavo come se fossero la norma, e non una cosa obsoleta.] Tuttavia, DSL, cavo, LTE (e altri metodi di accesso wireless) hanno indirizzi IP dinamici. Certo, a volte cambiano non spesso, ma comunque cambiano.
Esiste un sottoprogetto chiamato «wg-dynamic», che aggiunge un demone di spazio utente per superare questo difetto. Un grande problema nello scenario utente descritto sopra è l'aggravarsi della situazione con l'assegnazione dinamica degli indirizzi IPv6.
Dal punto di vista del distributore, tutto ciò non appare molto bene. Uno degli obiettivi dello sviluppo era mantenere la semplicità e la pulizia del protocollo.
Sfortunatamente, tutto ciò è diventato davvero troppo semplice e primitivo, tanto che dobbiamo usare software aggiuntivo affinché tutta questa struttura sia sostenibile in condizioni operative reali.
È così semplice utilizzare WireGuard?
Non ancora. Non dico che WireGuard non sarà mai una buona alternativa per il tunneling tra due punti, ma per ora è solo una versione alpha del prodotto che deve diventare.
Ma cosa fa realmente? È davvero IPsec così più complicato da gestire?
È evidente che no. Il fornitore di IPsec ha pensato a questo aspetto e fornisce il proprio prodotto con un'interfaccia, ad esempio, con IPFire.
Per configurare un tunnel VPN tramite IPsec, avrai bisogno di cinque set di dati da inserire nella configurazione: il tuo indirizzo IP pubblico, l'indirizzo IP pubblico della parte destinataria, le subnet che desideri rendere pubbliche tramite questa connessione VPN e la chiave precondivisa. In questo modo, la VPN può essere configurata in pochi minuti ed è compatibile con qualsiasi fornitore.
Sfortunatamente, ci sono alcune eccezioni in questa storia. Chiunque abbia provato a inoltrare un tunnel VPN tramite IPsec a una macchina su OpenBSD sa di cosa parlo. Ci sono anche altri esempi dolorosi, ma in realtà ci sono molte più pratiche positive nell'uso di IPsec.
Sulla complessità del protocollo
Il consumatore finale non dovrebbe preoccuparsi della complessità del protocollo.
Se vivessimo in un mondo dove questo fosse un reale problema per l'utente, ci saremmo già liberati di SIP, H.323, FTP e altri protocolli creati più di dieci anni fa che funzionano male con NAT.
Ci sono motivi per cui IPsec è più complesso di WireGuard: fa molte più cose. Ad esempio, l'autenticazione degli utenti tramite login/password o SIM con EAP. Ha anche la possibilità avanzata di aggiungere nuovi primitivi crittografici..
WireGuard non ha queste opzioni.
E ciò significa che WireGuard, a un certo punto, smetterà di funzionare, perché uno dei primordiali crittografici diventerà debole o sarà completamente compromesso. L'autore della documentazione tecnica lo esprime così:
È importante notare che WireGuard è crittograficamente presuntuoso. Gli manca intenzionalmente la flessibilità degli algoritmi e dei protocolli. Se si trovano gravi falle nei primordiali sottostanti, sarà necessario aggiornare tutti i punti finali. Come si può vedere dal costante flusso di vulnerabilità SSL/TLS, la flessibilità della crittografia è aumentata enormemente.
L'ultima affermazione è assolutamente corretta.
Raggiungere un consenso su quale crittografia utilizzare rende protocolli come IKE e TLS più di complessi. Troppo complessi? Sì, le vulnerabilità in TLS/SSL si verificano abbastanza spesso e non ci sono alternative.
Riguardo all'ignorare i problemi reali.
Immagina di avere un server VPN con 200 clienti attivi sparsi in tutto il mondo. Questo è un contesto d'uso piuttosto comune. Se devi cambiare la crittografia, dovrai distribuire l'aggiornamento a tutte le copie di WireGuard su questi laptop, smartphone e così via. Simultaneamente Distribuire. Questo è praticamente impossibile. Gli amministratori che tenteranno di farlo impiegheranno mesi per implementare le configurazioni necessarie, mentre le aziende comuni possono letteralmente avere bisogno di anni per realizzare un simile intervento.
IPsec e OpenVPN offrono una funzione di negoziazione dei cifrari. Pertanto, per un certo periodo, dopo aver attivato la nuova crittografia, continuerà a funzionare anche quella precedente. In questo modo, i clienti attuali possono aggiornarsi alla nuova versione. Una volta che l'aggiornamento è stato distribuito, basta disattivare la crittografia vulnerabile. E voilà! È fatto! Sei fantastico! E i clienti non si accorgeranno nemmeno di nulla.
In realtà, questo è un caso molto comune per grandi distribuzioni, e anche OpenVPN incontra alcune difficoltà. La retrocompatibilità è importante, e anche se stai usando una crittografia più debole, per molti non diventa un motivo per chiudere l'attività. Perché questo porterebbe a un paralisi del lavoro di centinaia di clienti a causa dell'incapacità di svolgere il proprio lavoro.
Il team di WireGuard ha semplificato il suo protocollo, ma è completamente inadeguato per le persone che non hanno un controllo costante su entrambi i peer del loro tunnel. Per la mia esperienza, questo è lo scenario più comune.
Crittografia!
Ma quale è quel nuovo e interessante algoritmo di crittografia utilizzato da WireGuard?
WireGuard utilizza Curve25519 per lo scambio delle chiavi, ChaCha20 per la crittografia e Poly1305 per l'autenticazione dei dati. Funziona anche con SipHash per le chiavi hash e BLAKE2 per l'hashing.
ChaCha20-Poly1305 è standardizzato per IPsec e OpenVPN (tramite TLS).
È evidente che lo sviluppo di Daniel Bernstein è ampiamente utilizzato. BLAKE2 è l'erede di BLAKE, finalista dello SHA-3, che non ha vinto a causa della sua somiglianza con SHA-2. Se SHA-2 fosse stato compromesso, ci sarebbe stata una grande probabilità che anche BLAKE fosse stato compromesso.
IPsec e OpenVPN non necessitano di SipHash a causa del loro design. Pertanto, l'unica cosa che attualmente non può essere utilizzata con loro è BLAKE2, e questo solo finché non sarà standardizzato. Ciò non rappresenta un grande svantaggio, perché le VPN utilizzano HMAC per garantire l'integrità, considerata una soluzione robusta anche in combinazione con MD5.
Quindi, sono giunto alla conclusione che praticamente tutti i VPN utilizzano lo stesso set di strumenti crittografici. Pertanto, WireGuard non è né più né meno sicuro rispetto a qualsiasi altro prodotto attuale quando si tratta di cifratura o integrità dei dati trasmessi.
Ma nemmeno questo è il punto principale da considerare secondo la documentazione ufficiale del progetto. La cosa principale è la velocità.
WireGuard è più veloce di altre soluzioni VPN?
In breve: no, non è più veloce.
ChaCha20 è un cifrario a flusso che risulta più facile da implementare nel software. Cifra un bit alla volta. I protocolli a blocchi, come l'AES, cifrano blocchi di 128 bit alla volta. Per implementare il supporto hardware servono molti più transistor, motivo per cui processori più grandi sono dotati di AES-NI, un'estensione del set di istruzioni che esegue alcune operazioni del processo di crittografia per accelerarlo.
Si pensava che l'AES-NI non sarebbe mai stato integrato negli smartphone [e invece lo è stato, nota del traduttore]. Per questo motivo è stato sviluppato ChaCha20, come un'alternativa leggera ed economica, che consuma meno energia della batteria. Dunque potrebbe sorprenderti sapere che ogni smartphone che puoi acquistare oggi porta con sé un certo livello di accelerazione per l'AES, e gestisce questa crittografia in modo più veloce e con minore consumo energetico rispetto a ChaCha20.
È evidente che praticamente ogni processore per desktop/server acquistato negli ultimi anni è dotato di AES-NI.
Di conseguenza, mi aspetto che AES superi ChaCha20 in ogni singolo scenario. Nella documentazione ufficiale di WireGuard si menziona che grazie a AVX512 ChaCha20-Poly1305 supererà AES-NI, ma questa estensione del set di istruzioni sarà disponibile solo su processori di grandi dimensioni, il che, d'altra parte, non aiuterà con l'hardware più piccolo e mobile, che funzionerà sempre più velocemente con AES-NI.
Non sono sicuro se ciò sia stato previsto durante lo sviluppo di WireGuard, ma oggi il fatto che sia vincolato a una sola crittografia è già un difetto che potrebbe influire negativamente sul suo funzionamento.
IPsec consente di scegliere liberamente quale crittografia si adatta meglio al tuo caso. E questo è particolarmente necessario se, ad esempio, desideri trasmettere 10 gigabyte o più di dati attraverso una connessione VPN.
Problemi di integrazione in Linux
Anche se WireGuard ha scelto un protocollo di crittografia moderno, ciò ha già causato numerosi problemi. E così, invece di utilizzare ciò che è supportato dal kernel di default, l'integrazione di WireGuard è stata ritardata per anni a causa dell'assenza di questi primitivi in Linux.
Non sono completamente aggiornato sulla situazione negli altri sistemi operativi, ma probabilmente non è molto diversa da quella di Linux.
Com'è la realtà?
Purtroppo, ogni volta che un cliente mi chiede di configurargli una connessione VPN, mi imbatto nel fatto che usano credenziali e crittografia obsolete. 3DES insieme a MD5 è ancora una pratica comune, così come AES-256 e SHA1. E anche se quest'ultimo è un po' migliore, non è qualcosa da utilizzare nel 2020.
Per lo scambio delle chiavi sempre si utilizza RSA, uno strumento lento ma abbastanza sicuro.
I miei clienti sono legati ad organi doganali e altre istituzioni governative, oltre a grandi corporazioni i cui nomi sono conosciuti in tutto il mondo. Tutti loro utilizzano una forma di richiesta che è stata creata decenni fa, e la possibilità di utilizzare SHA-512 semplicemente non è mai stata aggiunta. Non posso dire che questo influenzi in modo evidente il progresso tecnologico, ma è evidente che rallenta i processi aziendali.
Mi fa male vedere questo, perché l'IPsec supporta le curve ellittiche sin dal 2005. Curve25519 è anche più recente e disponibile per l'uso. Ci sono anche alternative all'AES, come Camellia e ChaCha20, ma ovviamente non tutte sono supportate dai grandi fornitori come Cisco e altri.
E la gente le utilizza. Ci sono molte suite Cisco e molti kit progettati per lavorare con Cisco. Sono leader di mercato in questo settore e non sono molto interessati a innovazioni.
Sì, la situazione [nel segmento aziendale] è terribile, ma non vedremo cambiamenti a causa di WireGuard. I produttori probabilmente non riveleranno mai problemi di prestazioni con gli strumenti e la crittografia già in uso, non vedranno problemi con l'IKEv2 — e quindi non cercano alternative.
Allora, hai mai pensato di abbandonare Cisco?
Benchmark
E ora passiamo ai benchmark della documentazione di WireGuard. Sebbene questa [documentazione] non sia un articolo scientifico, mi sarei aspettato dagli sviluppatori un approccio più rigoroso o l'uso di un metodo scientifico come riferimento. Qualsiasi benchmark è inutile se non può essere riprodotto, e risulta ancora più inutile se ottenuto in condizioni di laboratorio.
Nella build di WireGuard per Linux, ottiene un vantaggio utilizzando GSO — Generic Segmentation Offloading. Grazie a questo, il client crea un enorme pacchetto di 64 kilobyte e lo cripta/decripta in un solo passaggio. In questo modo, i costi di chiamata e attuazione delle operazioni crittografiche sono ridotti. Se desideri massimizzare la larghezza di banda della tua connessione VPN, è un'ottima idea.
Tuttavia, come spesso accade, nella realtà non è tutto così semplice. L'invio di un pacchetto così grande a un adattatore di rete richiede che venga suddiviso in molti pacchetti più piccoli. La dimensione normale dell'invio è di 1500 byte. Ciò significa che il nostro gigante da 64 kilobyte sarà diviso in 45 pacchetti (1240 byte di informazioni e 20 byte di intestazione IP). Poi, per un certo periodo di tempo, bloccheranno completamente il funzionamento dell'adattatore di rete, perché devono essere inviati insieme e simultaneamente. Alla fine, questo porterà a un salto di priorità, e pacchetti come, ad esempio, VoIP, saranno messi in coda.
Pertanto, l'elevata larghezza di banda di cui parla così audacemente WireGuard è ottenuta a spese della rete di altre applicazioni. E il team di WireGuard ha già confermato questa mia conclusione.
Ma andiamo avanti.
Secondo i benchmark nella documentazione tecnica, la connessione mostra una larghezza di banda di 1011 Mbit/s.
Impressionante.
Particolarmente impressionante è il fatto che la massima capacità teorica di una connessione Ethernet da un gigabit è di 966 Mbit/s con un pacchetto delle dimensioni di 1500 byte, sottraendo 20 byte per l'intestazione IP, 8 byte per l'intestazione UDP e 16 byte per l'intestazione di WireGuard. C'è un'altra intestazione IP nel pacchetto incapsulato e un'altra da 20 byte in TCP. Quindi, da dove proviene questa capacità aggiuntiva?
Con frame di grandi dimensioni e i vantaggi del GSO menzionati in precedenza, il massimo teorico con una dimensione del frame di 9000 byte sarà di 1014 Mbit/s. Di solito, questa capacità non è raggiungibile nella pratica poiché comporta grandi difficoltà. Pertanto, posso solo ipotizzare che il test sia stato eseguito utilizzando frame ancora più corposi, superando le dimensioni di 64 kilobyte con un massimo teorico di 1023 Mbit/s, supportato solo da alcune schede di rete. Ma questo è assolutamente inapplicabile in condizioni reali, o può essere utilizzato solo tra due stazioni collegate direttamente, esclusivamente all'interno di un banco di prova.
Tuttavia, poiché il tunnel VPN viene instradato tra due host utilizzando una connessione Internet che non supporta affatto frame di grandi dimensioni, il risultato ottenuto in laboratorio non può essere considerato un benchmark. È semplicemente un risultato laboratoriale irrealistico, impossibile e inapplicabile in condizioni operative reali.
Anche se fossi nel data center, non potrei instradare frame di dimensioni superiori a 9000 byte.
Il criterio di applicabilità nella vita reale è assolutamente compromesso e, a mio avviso, l’autore della «misurazione» condotta si è seriamente discreditato per motivi evidenti.
L’ultima luce di speranza
Sul sito di WireGuard si parla molto di container ed è chiaro a cosa sia realmente destinato.
Un VPN semplice e veloce che non richiede configurazione e può essere distribuito e configurato tramite strumenti di orchestrazione massivi, come ad esempio nel cloud di Amazon. In particolare, Amazon utilizza le più recenti funzionalità hardware di cui ho parlato in precedenza, come AVX512. Questo viene fatto per accelerare le prestazioni e non essere vincolati all'architettura x86 o ad altre architetture.
Ottimizzano la larghezza di banda e i pacchetti di dimensioni superiori ai 9000 byte — si tratta di enormi frame incapsulati per consentire la comunicazione tra contenitori, o per operazioni di backup, creazione di snapshot o distribuzione di questi contenitori. Anche gli indirizzi IP dinamici non influenzeranno il funzionamento di WireGuard nel caso dello scenario descritto.
Ben fatto. Eccellente implementazione e un protocollo molto sottile, quasi esemplare.
Ma non si adatta al mondo al di fuori di un data center completamente controllato da voi. Se decidete di correre il rischio e iniziare a utilizzare WireGuard, dovrete fare continui compromessi nella progettazione e implementazione del protocollo di crittografia.
Risultato
Non posso non concludere che WireGuard non è ancora pronto.
È stato progettato come una soluzione leggera e rapida a una serie di problemi delle soluzioni esistenti. Sfortunatamente, per raggiungere questi obiettivi, ha sacrificato molte funzionalità che sarebbero rilevanti per la maggior parte degli utenti. Ecco perché non può sostituire IPsec o OpenVPN.
Affinché WireGuard possa competere, ha bisogno di aggiungere almeno la configurazione dell'indirizzo IP e della routing e DNS. È evidente che ci vogliono canali crittografati proprio per questo.
La sicurezza è la mia priorità principale, e al momento non ho motivo di ritenere che IKE o TLS siano in qualche modo compromessi o rotti. Entrambi supportano la crittografia moderna ed sono stati testati da decenni di utilizzo. Qualcosa di più nuovo non significa necessariamente che sia migliore.
La compatibilità funzionale è estremamente importante quando ti connetti a terze parti, le cui stazioni non controlli. IPsec è de facto uno standard ed è supportato praticamente ovunque. E funziona. E, per quanto possa sembrare, in teoria, WireGuard in futuro potrebbe non essere nemmeno compatibile con diverse versioni di se stesso.
Ogni protezione crittografica viene violata prima o poi e deve quindi essere sostituita o aggiornata.
Negare tutti questi fatti e il desiderio cieco di usare WireGuard per connettere il tuo iPhone alla stazione di lavoro domestica è semplicemente una lezione su come mettere la testa nella sabbia.
Fonte: habr.com
