Negli ultimi tempi, WireGuard ha attirato molta attenzione, in effetti è 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 rappresenti una soluzione in grado di sostituire IPsec o OpenVPN.
In questo articolo, desidero sfatare alcuni miti [attorno a WireGuard]. Sì, ci sarà da leggere a lungo, quindi se non hai ancora preparato una tazza di tè o caffè, è il momento di farlo. Vorrei anche ringraziare Peter per la revisione dei miei pensieri caotici.
Non ho intenzione di screditare gli sviluppatori di WireGuard, né svalutare i loro sforzi o idee. Il loro prodotto è funzionante, ma personalmente considero che venga presentato in modo completamente diverso da quello che è realmente: viene presentato come un sostituto di IPsec e OpenVPN, che in realtà attualmente non esiste.
A titolo di nota, voglio aggiungere che la responsabilità per questa posizione di WireGuard è dei media che ne hanno parlato, e non del progetto stesso o dei suoi creatori.
Negli ultimi tempi, non ci sono state molte buone notizie riguardo al kernel Linux. Così, ci hanno parlato di mostruose vulnerabilità dei processori che sono state mitigate in modo software, e Linus Torvalds ha parlato di questo in modo piuttosto brusco e noioso, utilizzando un linguaggio utilitaristico da sviluppatore. Il pianificatore o lo stack di rete di livello zero non sono argomenti molto comprensibili per le riviste patinate. E qui appare WireGuard.
Sulla carta, tutto suona fantastico: una nuova tecnologia che stimola 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 recita:
WireGuard […] mira a sostituire sia IPsec nella maggior parte dei casi del suo utilizzo, sia altre popolari soluzioni basate su spazio utente e/o TLS, come OpenVPN, risultando più sicuro, performante e semplice da usare [strumento].
Certo, il principale pregio di tutte le nuove tecnologie è la loro semplicità [rispetto ai predecessori]. Ma una VPN deve anche essere efficace e sicura.
E poi?
Se dici che non hai bisogno di questo [da VPN], allora la lettura può finire qui. Tuttavia, vorrei notare che compiti simili si pongono per qualsiasi altra tecnologia di tunneling.
La parte più interessante della citazione sopra si trova nelle parole "nella maggior parte dei casi", che, ovviamente, sono state ignorate dalla stampa. E così, siamo finiti in un caos creato da questa negligenza — in questo articolo.
WireGuard sarà una sostituzione della mia connessione VPN [IPsec] tra siti?
No. Qui semplicemente non ci sono possibilità che grandi fornitori, come Cisco, Juniper e altri, adottino WireGuard per i loro prodotti. Non "saltano sui treni in corsa" senza una grande necessità. Più tardi parlerò di alcune ragioni per cui probabilmente non potranno integrare WireGuard nei loro prodotti, anche se lo volessero.
WireGuard sposterà il mio RoadWarrior dal laptop al data center?
No. Al momento, WireGuard non ha implementato un numero enorme di funzioni importanti per realizzare una cosa simile. Ad esempio, non può utilizzare indirizzi IP dinamici dal lato server del tunnel, e solo questo rompe totalmente lo scenario di utilizzo del prodotto.
IPFire viene spesso utilizzato per canali internet a basso costo, ad esempio, per DSL o connessione via cavo. Questo ha senso per piccole o medie imprese che non hanno bisogno di fibra ottica veloce. [Nota del traduttore: non dimenticate che in termini di connessione, la Russia e alcuni paesi della CSI sono molto più avanti rispetto all'Europa e agli Stati Uniti, perché abbiamo iniziato a costruire le nostre reti molto più tardi e con l'arrivo dell'Ethernet e delle reti in fibra ottica come standard, è stato più facile per noi adattarci. Negli stessi paesi dell'UE o negli Stati Uniti, l'accesso a banda larga xDSL a velocità di 3-5 Mbit/s è ancora la norma generale, mentre la connessione in fibra ottica costa somme irrealistiche a nostro avviso. Ecco perché l'autore dell'articolo parla di connessioni DSL o via cavo come norma, e non come vecchie tecnologie.] Tuttavia, DSL, cavo, LTE (e altri metodi di accesso wireless) hanno indirizzi IP dinamici. Certo, a volte cambiano non spesso, ma cambiano comunque.
Esiste un sotto-progetto chiamato "wg-dynamic", che aggiunge un demone di spazio utente per superare questo svantaggio. Un enorme problema dello scenario utente descritto sopra è l'aggravarsi della situazione dovuto all'assegnazione dinamica degli indirizzi IPv6.
Dal punto di vista dei distributori, tutto ciò non appare troppo positivo. Uno degli obiettivi dello sviluppo era mantenere la semplicità e la pulizia del protocollo.
Purtroppo, tutto ciò è diventato davvero troppo semplice e primitivo, tanto che dobbiamo utilizzare software aggiuntivo affinché tutta questa struttura sia sostenibile nelle condizioni di utilizzo reale.
È così semplice utilizzare WireGuard?
Al momento no. Non sto dicendo che WireGuard non sarà mai una buona alternativa per il tunneling tra due punti, ma per ora è solo una versione alpha del prodotto che dovrebbe diventare.
Ma cosa fa realmente allora? È davvero IPsec così più complesso da usare?
Ovviamente no. Il fornitore di IPsec ha considerato 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 ricevente, le sottoreti che desideri rendere accessibili tramite questa connessione VPN e la chiave precondivisa. In questo modo, la VPN è configurata in pochi minuti ed è compatibile con qualsiasi fornitore.
Purtroppo, in questa storia ci sono alcune eccezioni. Chiunque abbia provato a stabilire un tunnel VPN tramite IPsec a una macchina su OpenBSD sa di cosa parlo. Ci sono anche un paio di esempi dolorosi, ma in realtà la pratica positiva dell'uso di IPsec è molto più abbondante.
Sulla complessità del protocollo
Il consumatore finale non dovrebbe preoccuparsi della complessità del protocollo.
Se vivessimo in un mondo in cui ciò fosse veramente una preoccupazione per l'utente, avremmo già abbandonato SIP, H.323, FTP e altri protocolli creati oltre dieci anni fa che funzionano male con NAT.
Ci sono ragioni per cui IPsec è più complesso di WireGuard: fa molte più cose. Ad esempio, l'autenticazione dell'utente utilizzando nome utente/password o una SIM con EAP. Ha la possibilità estesa di aggiungere nuovi primitivi crittografici.
E WireGuard non ha tutto ciò.
E questo significa che WireGuard si romperà a un certo punto, perché uno dei primitivi crittografici si indebolirà o sarà completamente compromesso. L'autore della documentazione tecnica lo descrive così:
È importante notare che WireGuard è crittograficamente sicuro di sé. Gli mancano intenzionalmente la flessibilità degli algoritmi e dei protocolli. Se nei primitivi sottostanti vengono scoperte gravi vulnerabilità, sarà necessario aggiornare tutti i punti finali. Come si può vedere dal continuo afflusso di vulnerabilità SLL/TLS, la flessibilità della crittografia è aumentata notevolmente.
L'ultima affermazione è completamente vera.
Raggiungere un consenso su quale crittografia utilizzare rende i protocolli come IKE e TLS oltre complessi. Troppo complesso? Sì, vulnerabilità in TLS/SSL si verificano abbastanza spesso e non ci sono alternative.
Sull'ignorare i problemi reali
Immagina di avere un server VPN con 200 clienti attivi, sparsi in tutto il mondo. Questo è uno scenario d'uso piuttosto comune. Se dovessi cambiare la crittografia, dovresti distribuire l'aggiornamento a tutte le copie di WireGuard su questi laptop, smartphone e così via. Contemporaneamente distribuirlo. È letteralmente impossibile. Gli amministratori che tenteranno di farlo avranno bisogno di mesi per distribuire le configurazioni necessarie, e alle aziende medie richiederà letteralmente anni per condurre un'operazione simile.
IPsec e OpenVPN offrono una funzionalità di negoziazione degli algoritmi. Pertanto, per un certo periodo di tempo, dopo aver attivato la nuova crittografia, la vecchia continuerà a funzionare. In questo modo, i clienti attuali potranno aggiornarsi alla nuova versione. Dopo che l'aggiornamento è stato distribuito, spegnerai semplicemente la crittografia vulnerabile. E via! Fatto! Sei meraviglioso! E i clienti nemmeno se ne accorgeranno.
In realtà, questo è un caso molto comune per grandi distribuzioni, e anche OpenVPN ha alcune difficoltà in questo. La compatibilità retroattiva è importante, e anche se utilizzi una crittografia più debole, per molti questo non rappresenta una ragione per chiudere l'attività. Perché ciò 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 proprio protocollo, ma lo ha reso completamente inadeguato per le persone che non hanno un controllo costante su entrambi i peer del proprio tunnel. Dalla mia esperienza, questo scenario è il più comune.
Crittografia!
Ma cos'è questo nuovo e interessante algoritmo di crittografia utilizzato da WireGuard?
WireGuard utilizza Curve25519 per lo scambio di chiavi, ChaCha20 per la crittografia e Poly1305 per l'autenticazione dei dati. Lavora 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 viene utilizzato molto spesso. BLAKE2 è il successore di BLAKE, finalista di SHA-3, che non ha vinto a causa della somiglianza con SHA-2. Se SHA-2 venisse compromesso, ci sarebbe una grande possibilità che anche BLAKE lo fosse.
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 solo finché non sarà standardizzato. Questo non costituisce un grande svantaggio, poiché le VPN utilizzano HMAC per creare l'integrità, che è considerata una soluzione robusta anche in combinazione con MD5.
Quindi sono giunto alla conclusione che in tutte le VPN viene utilizzato praticamente lo stesso insieme di strumenti crittografici. Pertanto, WireGuard non è più né meno sicuro di qualsiasi altro prodotto attuale quando si tratta di crittografia o integrità dei dati trasmessi.
Ma nemmeno questo è il punto principale da considerare secondo la documentazione ufficiale del progetto. Ciò che conta di più è la velocità.
WireGuard è più veloce di altre soluzioni VPN?
In breve: no, non è più veloce.
ChaCha20 è un cifrario a flusso, che è più facile da implementare nel software. Cifra un bit alla volta. I protocolli a blocchi, come AES, cifrano blocchi da 128 bit alla volta. Per implementare il supporto hardware sono necessari molti più transistor, quindi i 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 prevedeva che AES-NI non sarebbe mai arrivato negli smartphone [e invece è successo, ndr]. Per questo è stato sviluppato ChaCha20, come alternativa leggera ed economica, che preserva la durata della batteria. Pertanto, potrebbe sorprenderti sapere che ogni smartphone che puoi acquistare oggi ha un qualche tipo di accelerazione per AES e funziona con questa crittografia più velocemente e con un minore consumo energetico rispetto a ChaCha20.
È evidente che praticamente ogni processore per PC desktop/server acquistato negli ultimi anni ha 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 più potenti, il che, di nuovo, non aiuta con l'hardware più piccolo e mobile, che funzionerà sempre più velocemente con AES-NI.
Non sono sicuro se questo fosse previsto durante lo sviluppo di WireGuard, ma oggi il fatto che sia strettamente legato a una sola crittografia rappresenta già un limite che potrebbe non influenzare positivamente le sue prestazioni.
IPsec consente di scegliere liberamente quale crittografia sia più adatta al tuo caso. E naturalmente è necessario, se ad esempio desideri trasferire 10 gigabyte o più di dati tramite una connessione VPN.
Problemi di integrazione in Linux
Sebbene WireGuard abbia scelto un protocollo di crittografia moderno, questo ha già creato numerosi problemi. E così, invece di utilizzare ciò che è supportato dal kernel di default, l'integrazione di WireGuard è stata rimandata per anni a causa della mancanza di questi primitivi in Linux.
Non sono completamente aggiornato sulla situazione in altri sistemi operativi, ma probabilmente non è troppo diversa da quella di Linux.
Com'è la realtà?
Sfortunatamente, ogni volta che un cliente mi chiede di configurargli una connessione VPN, mi trovo ad affrontare il tema che utilizzano credenziali e crittografia obsolete. 3DES insieme a MD5 è ancora una pratica comune, così come AES-256 e SHA1. E sebbene quest'ultimo sia leggermente migliore, non è quello da utilizzare nel 2020.
Per lo scambio di chiavi sempre si utilizza RSA, uno strumento lento ma abbastanza sicuro.
I miei clienti sono in contatto con le autorità doganali e altre organizzazioni e istituzioni governative, così come con grandi corporation i cui nomi sono conosciuti in tutto il mondo. Tutti utilizzano un modulo di richiesta creato decenni fa, e la possibilità di utilizzare SHA-512 semplicemente non è mai stata aggiunta. Non posso dire che questo influisca visibilmente sul progresso tecnologico, ma è evidente che rallenta i processi aziendali.
Mi fa male vedere ciò, perché IPsec supporta le curve ellittiche a occhio e croce dal 2005. Curve25519 è anche più recente e disponibile per l'uso. Ci sono 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 molti kit Cisco, e una miriade di kit progettati per lavorare con Cisco. Sono leader di mercato in questo segmento e non sono molto interessati a eventuali innovazioni.
Sì, la situazione [nel segmento aziendale] è terribile, ma non vedremo cambiamenti a causa di WireGuard. I produttori probabilmente non identificheranno mai problemi di prestazioni con gli strumenti e la crittografia già in uso, né vedranno problemi nell'utilizzare IKEv2, e quindi non cercano alternative.
Hai mai pensato di abbandonare Cisco?
Benchmark
Ora passiamo ai benchmark dalla documentazione di WireGuard. Sebbene questa [documentazione] non sia un articolo scientifico, mi aspettavo un approccio più scientifico da parte degli sviluppatori, o almeno un uso di un approccio scientifico come riferimento. Qualsiasi benchmark è inutile se non è riproducibile, ed è ancora più inutile se ottenuto in condizioni di laboratorio.
Nella build di WireGuard per Linux, ottiene un vantaggio utilizzando GSO — Generic Segmentation Offloading. Questo consente al client di creare un enorme pacchetto di 64 kilobyte e di cifrarlo/decifrarlo in un solo passaggio. In questo modo, i costi di invocazione e realizzazione delle operazioni crittografiche vengono ridotti. Se desideri massimizzare la larghezza di banda della tua connessione VPN, è una buona idea.
Ma, 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 numerosi pacchetti più piccoli. La dimensione normale di un pacchetto è di 1500 byte. Questo significa che il nostro gigante da 64 kilobyte verrà diviso in 45 pacchetti (1240 byte di informazione e 20 byte di intestazione IP). Poi, per un certo periodo, bloccheranno completamente il funzionamento dell'adattatore di rete, poiché devono essere inviati insieme e simultaneamente. Questo porterà a un innalzamento della priorità, e pacchetti come, ad esempio, VoIP, verranno messi in coda.
In questo modo, l'elevata larghezza di banda di cui WireGuard si vanta così audacemente viene raggiunta a scapito della rete di funzionamento di altre applicazioni. E il team di WireGuard già ha confermato questa è la 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 considerando che la larghezza di banda teorica massima di una connessione Ethernet a un gigabit è di 966 Mbit/s con una dimensione del pacchetto di 1500 byte, meno 20 byte per l'intestazione IP, 8 byte per l'intestazione UDP e 16 byte per l'intestazione di WireGuard stessa. C'è un'altra intestazione IP nel pacchetto incapsulato e un'altra — nel TCP di 20 byte. Quindi, da dove proviene questa larghezza di banda aggiuntiva?
Con i frame di grandi dimensioni e i vantaggi del GSO di cui abbiamo parlato sopra, il massimo teorico con una dimensione del frame di 9000 byte sarà di 1014 Mbit/s. Di solito, tale larghezza di banda è irraggiungibile nella realtà, poiché comporta notevoli difficoltà. Pertanto, posso solo supporre che il test sia stato eseguito utilizzando frame ancora più grossi con un superamento della dimensione di 64 kilobyte, con un massimo teorico di 1023 Mbit/s, supportato solo da alcuni adattatori di rete. Ma questo è assolutamente inapplicabile in condizioni reali, oppure può essere utilizzato solo tra due stazioni direttamente collegate, esclusivamente all'interno di un banco di prova.
Ma poiché il tunnel VPN viene realizzato tra due host tramite una connessione a Internet che non supporta affatto pacchetti di grandi dimensioni, il risultato ottenuto in laboratorio non può essere considerato un riferimento. È semplicemente un risultato di laboratorio irrealizzabile e impraticabile in condizioni di combattimento reali.
Anche seduto nel data center, non riuscirei a trasmettere pacchetti di dimensioni superiori a 9000 byte.
Il criterio di applicabilità nella vita reale è completamente violato e, a mio avviso, l'autore della "misurazione" condotta ha seriamente sminuito se stesso per motivi ovvi.
L'ultimo barlume di speranza
Sul sito di WireGuard si parla molto di contenitori e diventa chiaro a cosa sia realmente destinato.
Una VPN semplice e veloce che non richiede configurazione e può essere distribuita e configurata con strumenti di orchestrazione massivi, come ad esempio quelli di Amazon nel loro cloud. In particolare, Amazon utilizza le più recenti funzionalità hardware di cui ho parlato in precedenza, come AVX512. Questo è fatto per velocizzare il lavoro senza legarsi a x86 o qualsiasi altra architettura.
Ottimizzano la larghezza di banda e i pacchetti le cui dimensioni superano i 9000 byte; questo porta a enormi pacchetti incapsulati per la comunicazione tra contenitori o per operazioni di backup, creazione di snapshot o distribuzione di questi stessi contenitori. Anche gli indirizzi IP dinamici non influenzeranno il funzionamento di WireGuard nel caso dello scenario descritto.
Ben fatto. Un'implementazione brillante e un protocollo molto raffinato, quasi di riferimento.
Ma semplicemente non è adatto al mondo al di fuori del data center di cui si ha il pieno controllo. Se decidi di rischiare e iniziare a utilizzare WireGuard, dovrai affrontare compromessi costanti nello sviluppo e nell'implementazione del protocollo di crittografia.
Conclusione
Non ho difficoltà a concludere che WireGuard non è ancora pronto.
Era stato concepito come una soluzione leggera e rapida a una serie di problemi delle soluzioni già esistenti. Sfortunatamente, a causa di queste soluzioni, ha sacrificato molte funzionalità che sarebbero rilevanti per la maggior parte degli utenti. Per questo motivo, non può sostituire IPsec o OpenVPN.
Affinché WireGuard possa diventare competitivo, deve aggiungere almeno la configurazione dell'indirizzo IP e la configurazione del routing e del DNS. È evidente che sono necessari canali crittografati proprio per questo.
La sicurezza è la mia massima priorità e attualmente non ho ragioni per ritenere che IKE o TLS siano compromessi o rotti. La crittografia moderna è supportata da entrambi e sono stati testati per decenni di utilizzo. Se qualcosa è più nuovo, non significa necessariamente che sia migliore.
La compatibilità funzionale è estremamente importante quando ci si connette a terzi, stazioni che non controlli. IPsec è de facto lo standard e supportato quasi ovunque. E funziona. Nonostante possa sembrare in teoria, WireGuard potrebbe in futuro risultare incompatibile anche con diverse versioni di se stesso.
Qualsiasi protezione crittografica prima o poi viene violata e, di conseguenza, deve essere sostituita o aggiornata.
Negare tutti questi fatti e avere un desiderio cieco di usare WireGuard per collegare il tuo iPhone alla workstation domestica è semplicemente un masterclass nel mettere la testa nella sabbia.
Fonte: habr.com
