WireGuard sta guadagnando molta attenzione ultimamente, infatti è la nuova stella tra le VPN. Ma è bravo come sembra? Vorrei discutere alcune osservazioni e rivedere l'implementazione di WireGuard per spiegare perché non è una soluzione per sostituire IPsec o OpenVPN.
In questo articolo, vorrei sfatare alcuni dei miti [su WireGuard]. Sì, ci vorrà molto tempo per leggere, quindi se non ti sei preparato una tazza di tè o caffè, allora è il momento di farlo. Vorrei anche ringraziare Peter per aver corretto i miei pensieri caotici.
Non mi pongo l'obiettivo di screditare gli sviluppatori di WireGuard, svalutando i loro sforzi o le loro idee. Il loro prodotto funziona, ma personalmente penso che sia presentato in modo completamente diverso da quello che è realmente: viene presentato come un sostituto di IPsec e OpenVPN, che in realtà semplicemente non esiste ora.
Come nota, vorrei aggiungere che la responsabilità di tale posizionamento di WireGuard ricade sui media che ne hanno parlato, e non sul progetto stesso o sui suoi creatori.
Non ci sono state molte buone notizie sul kernel Linux ultimamente. Quindi, ci è stato detto delle mostruose vulnerabilità del processore, che sono state livellate dal software, e Linus Torvalds ne ha parlato in modo troppo sgarbato e noioso, nel linguaggio utilitaristico dello sviluppatore. Anche uno scheduler o uno stack di rete di livello zero non sono argomenti molto chiari per le riviste patinate. Ed ecco che arriva WireGuard.
Sulla carta, sembra tutto fantastico: una nuova entusiasmante tecnologia.
Ma vediamolo un po' più da vicino.
Libro bianco WireGuard
Questo articolo è basato su scritto da Jason Donenfeld. Lì spiega il concetto, lo scopo e l'implementazione tecnica di [WireGuard] nel kernel Linux.
La prima frase recita:
WireGuard […] mira a sostituire sia IPsec nella maggior parte dei casi d'uso sia altre popolari soluzioni basate su spazio utente e/o TLS come OpenVPN pur essendo più sicuro, performante e più facile da usare [strumento].
Naturalmente, il vantaggio principale di tutte le nuove tecnologie è il loro alleviare [rispetto ai predecessori]. Ma dovrebbe esserlo anche una VPN efficace e sicuro.
E qual è il prossimo?
Se dici che questo non è ciò di cui hai bisogno [da una VPN], puoi terminare qui la lettura. Tuttavia, noterò che tali attività sono impostate per qualsiasi altra tecnologia di tunneling.
La più interessante della citazione di cui sopra risiede nelle parole "nella maggior parte dei casi", che, ovviamente, sono state ignorate dalla stampa. E così, siamo dove siamo finiti a causa del caos creato da questa negligenza - in questo articolo.
WireGuard sostituirà la mia VPN site-to-site [IPsec]?
NO. Semplicemente non c'è alcuna possibilità che grandi fornitori come Cisco, Juniper e altri acquistino WireGuard per i loro prodotti. Non "saltano sui treni in transito" in movimento a meno che non ci sia un grande bisogno di farlo. Più avanti, esaminerò alcuni dei motivi per cui probabilmente non saranno in grado di integrare i loro prodotti WireGuard anche se lo volessero.
WireGuard porterà il mio RoadWarrior dal mio laptop al data center?
NO. Al momento, WireGuard non ha implementato un numero enorme di funzionalità importanti per poter fare qualcosa del genere. Ad esempio, non può utilizzare indirizzi IP dinamici sul lato server del tunnel, e questo da solo interrompe l'intero scenario di tale utilizzo del prodotto.
IPFire viene spesso utilizzato per collegamenti Internet economici, come connessioni DSL o via cavo. Questo ha senso per le piccole o medie imprese che non necessitano di fibra veloce. [Nota del traduttore: non dimenticare che in termini di comunicazione, la Russia e alcuni paesi della CSI sono molto più avanti dell'Europa e degli Stati Uniti, perché abbiamo iniziato a costruire le nostre reti molto più tardi e con l'avvento delle reti Ethernet e in fibra ottica come standard, è stato più facile per noi ricostruire. Negli stessi paesi dell'UE o degli Stati Uniti, l'accesso a banda larga xDSL a una velocità di 3-5 Mbps è ancora la norma generale e una connessione in fibra ottica costa denaro irrealistico per i nostri standard. Pertanto, l'autore dell'articolo parla di connessione DSL o via cavo come norma, e non tempi antichi.] Tuttavia, DSL, cavo, LTE (e altri metodi di accesso wireless) hanno indirizzi IP dinamici. Certo, a volte non cambiano spesso, ma cambiano.
C'è un sottoprogetto chiamato , che aggiunge un demone dello spazio utente per superare questa lacuna. Un enorme problema con lo scenario utente sopra descritto è l'aggravamento dell'indirizzamento dinamico IPv6.
Anche dal punto di vista del distributore tutto questo non sembra molto buono. Uno degli obiettivi di progettazione era mantenere il protocollo semplice e pulito.
Sfortunatamente, tutto questo è diventato in realtà troppo semplice e primitivo, quindi dobbiamo utilizzare software aggiuntivo affinché l'intero progetto sia fattibile nell'uso reale.
WireGuard è così facile da usare?
Non ancora. Non sto dicendo che WireGuard non sarà mai una buona alternativa per il tunneling tra due punti, ma per ora è solo una versione alfa del prodotto che dovrebbe essere.
Ma allora cosa fa concretamente? IPsec è davvero molto più difficile da mantenere?
Ovviamente no. Il fornitore IPsec ha pensato a questo e spedisce il proprio prodotto insieme a un'interfaccia, come IPFire.
Per impostare un tunnel VPN su IPsec, avrai bisogno di cinque set di dati che dovrai inserire nella configurazione: il tuo indirizzo IP pubblico, l'indirizzo IP pubblico della parte ricevente, le sottoreti che vuoi rendere pubbliche attraverso questa connessione VPN e la chiave precondivisa. Pertanto, la VPN viene configurata in pochi minuti ed è compatibile con qualsiasi fornitore.
Sfortunatamente, ci sono alcune eccezioni a questa storia. Chiunque abbia provato a eseguire il tunneling su IPsec verso una macchina OpenBSD sa di cosa sto parlando. Ci sono un altro paio di esempi dolorosi, ma in realtà ci sono molte, molte più buone pratiche per l'utilizzo di IPsec.
Sulla complessità del protocollo
L'utente finale non deve preoccuparsi della complessità del protocollo.
Se vivessimo in un mondo in cui questa era una vera preoccupazione dell'utente, allora ci saremmo sbarazzati di SIP, H.323, FTP e altri protocolli creati più di dieci anni fa che non funzionano bene con NAT.
Ci sono ragioni per cui IPsec è più complesso di WireGuard: fa molte più cose. Ad esempio, l'autenticazione dell'utente utilizzando un login / password o una scheda SIM con EAP. Ha una capacità estesa di aggiungere nuovi .
E WireGuard non ce l'ha.
E questo significa che WireGuard ad un certo punto si romperà, perché una delle primitive crittografiche si indebolirà o sarà completamente compromessa. L'autore della documentazione tecnica dice questo:
Vale la pena notare che WireGuard è crittograficamente supponente. Manca deliberatamente la flessibilità di cifrari e protocolli. Se vengono rilevati buchi gravi nelle primitive sottostanti, sarà necessario aggiornare tutti gli endpoint. Come puoi vedere dal flusso continuo di vulnerabilità SLL/TLS, la flessibilità della crittografia è ora aumentata enormemente.
L'ultima frase è assolutamente corretta.
Raggiungere il consenso su quale crittografia utilizzare rende protocolli come IKE e TLS di più complesso. Troppo complicato? Sì, le vulnerabilità sono abbastanza comuni in TLS/SSL e non esiste alternativa.
Sull'ignorare i problemi reali
Immagina di avere un server VPN con 200 client di combattimento da qualche parte nel mondo. Questo è un caso d'uso piuttosto standard. Se devi modificare la crittografia, devi fornire l'aggiornamento a tutte le copie di WireGuard su questi laptop, smartphone e così via. Contemporaneamente consegnare. È letteralmente impossibile. Gli amministratori che tentano di farlo impiegheranno mesi per implementare le configurazioni richieste e un'azienda di medie dimensioni impiegherà letteralmente anni per realizzare un simile evento.
IPsec e OpenVPN offrono una funzione di negoziazione della cifratura. Pertanto, per qualche tempo dopo il quale attivi la nuova crittografia, funzionerà anche quella vecchia. Ciò consentirà ai clienti attuali di eseguire l'aggiornamento alla nuova versione. Dopo che l'aggiornamento è stato implementato, devi semplicemente disattivare la crittografia vulnerabile. E questo è tutto! Pronto! sei favolosa! I clienti non se ne accorgeranno nemmeno.
Questo è in realtà un caso molto comune per le grandi distribuzioni e anche OpenVPN ha qualche difficoltà con questo. La compatibilità con le versioni precedenti è importante e, anche se si utilizza una crittografia più debole, per molti questo non è un motivo per chiudere un'attività. Perché paralizzerà il lavoro di centinaia di clienti a causa dell'impossibilità di svolgere il proprio lavoro.
Il team di WireGuard ha reso il proprio protocollo più semplice, ma completamente inutilizzabile per le persone che non hanno un controllo costante su entrambi i peer nel proprio tunnel. Nella mia esperienza, questo è lo scenario più comune.
Crittografia!
Ma cos'è questa nuova interessante crittografia utilizzata da WireGuard?
WireGuard utilizza Curve25519 per lo scambio di 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 (su TLS).
È ovvio che lo sviluppo di Daniel Bernstein viene utilizzato molto spesso. BLAKE2 è il successore di BLAKE, un finalista SHA-3 che non ha vinto a causa della sua somiglianza con SHA-2. Se SHA-2 dovesse essere violato, c'erano buone possibilità che anche BLAKE venisse compromesso.
IPsec e OpenVPN non hanno bisogno di SipHash a causa del loro design. Quindi l'unica cosa che attualmente non può essere utilizzata con loro è BLAKE2, e questo solo fino a quando non sarà standardizzato. Questo non è un grosso svantaggio, perché le VPN utilizzano HMAC per creare integrità, che è considerata una soluzione forte anche in combinazione con MD5.
Quindi sono giunto alla conclusione che quasi lo stesso set di strumenti crittografici viene utilizzato in tutte le VPN. Pertanto, WireGuard non è né più né meno sicuro di qualsiasi altro prodotto attuale quando si tratta di crittografia o integrità dei dati trasmessi.
Ma anche questa non è la cosa più importante, a cui vale la pena prestare attenzione secondo la documentazione ufficiale del progetto. Dopotutto, la cosa principale è la velocità.
WireGuard è più veloce di altre soluzioni VPN?
In breve: no, non più veloce.
ChaCha20 è un cifrario a flusso più facile da implementare nel software. Crittografa un bit alla volta. I protocolli di blocco come AES crittografano un blocco 128 bit alla volta. Sono necessari molti più transistor per implementare il supporto hardware, quindi i processori più grandi sono dotati di AES-NI, un'estensione del set di istruzioni che esegue alcune delle attività del processo di crittografia per accelerarlo.
Ci si aspettava che AES-NI non sarebbe mai entrato negli smartphone [ma lo ha fatto - ca. per.]. Per questo, ChaCha20 è stato sviluppato come alternativa leggera e a risparmio energetico. Pertanto, potrebbe essere una novità per te che ogni smartphone che puoi acquistare oggi abbia una sorta di accelerazione AES e funzioni più velocemente e con un consumo energetico inferiore con questa crittografia rispetto a ChaCha20.
Ovviamente, quasi tutti i processori desktop/server acquistati negli ultimi due anni hanno AES-NI.
Pertanto, mi aspetto che AES superi ChaCha20 in ogni singolo scenario. La documentazione ufficiale di WireGuard menziona che con AVX512, ChaCha20-Poly1305 supererà AES-NI, ma questa estensione del set di istruzioni sarà disponibile solo su CPU più grandi, il che ancora una volta non aiuterà con hardware più piccolo e più mobile, che sarà sempre più veloce con AES - N.I.
Non sono sicuro che questo potesse essere previsto durante lo sviluppo di WireGuard, ma oggi il fatto che sia inchiodato alla sola crittografia è già un inconveniente che potrebbe non pregiudicare molto bene il suo funzionamento.
IPsec ti consente di scegliere liberamente quale crittografia è la migliore per il tuo caso. E, naturalmente, questo è necessario se, ad esempio, desideri trasferire 10 o più gigabyte di dati tramite una connessione VPN.
Problemi di integrazione in Linux
Sebbene WireGuard abbia scelto un moderno protocollo di crittografia, questo causa già molti problemi. E così, invece di utilizzare ciò che è supportato dal kernel out of the box, l'integrazione di WireGuard è stata ritardata per anni a causa della mancanza di queste primitive in Linux.
Non sono del tutto sicuro di quale sia la situazione su altri sistemi operativi, ma probabilmente non è molto diversa da quella su Linux.
Che aspetto ha la realtà?
Sfortunatamente, ogni volta che un cliente mi chiede di configurare una connessione VPN per loro, mi imbatto nel problema 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, questo non è qualcosa che dovrebbe essere utilizzato nel 2020.
Per lo scambio di chiavi sempre Viene utilizzato RSA, uno strumento lento ma abbastanza sicuro.
I miei clienti sono associati alle autorità doganali e ad altre organizzazioni e istituzioni governative, nonché a grandi società i cui nomi sono conosciuti in tutto il mondo. Usano tutti un modulo di richiesta creato decenni fa e la possibilità di utilizzare SHA-512 semplicemente non è mai stata aggiunta. Non posso dire che in qualche modo influisca chiaramente sul progresso tecnologico, ma ovviamente rallenta il processo aziendale.
Mi addolora vederlo perché IPsec supporta le curve ellittiche dal 2005. Curve25519 è anche più recente e disponibile per l'uso. Esistono anche alternative ad AES come Camellia e ChaCha20, ma ovviamente non tutte sono supportate dai principali fornitori come Cisco e altri.
E le persone ne approfittano. Ci sono molti kit Cisco, ci sono molti kit progettati per funzionare con Cisco. Sono leader di mercato in questo segmento e non sono molto interessati a nessun tipo di innovazione.
Sì, la situazione [nel segmento aziendale] è terribile, ma non vedremo alcun cambiamento grazie a WireGuard. I fornitori probabilmente non vedranno mai problemi di prestazioni con gli strumenti e la crittografia che stanno già utilizzando, non vedranno alcun problema con IKEv2 e quindi non cercano alternative.
In generale, hai mai pensato di abbandonare Cisco?
Punti di riferimenti
E ora passiamo ai benchmark dalla documentazione di WireGuard. Sebbene questa [documentazione] non sia un articolo scientifico, mi aspettavo comunque che gli sviluppatori adottassero un approccio più scientifico o utilizzassero un approccio scientifico come riferimento. Eventuali benchmark sono inutili se non possono essere riprodotti, e ancor più inutili quando sono ottenuti in laboratorio.
Nella build Linux di WireGuard, sfrutta l'utilizzo di GSO - Generic Segmentation Offloading. Grazie a lui, il client crea un enorme pacchetto di 64 kilobyte e lo crittografa / decrittografa in una volta sola. Pertanto, il costo di invocare e implementare le operazioni crittografiche è ridotto. Se vuoi massimizzare il throughput della tua connessione VPN, questa è una buona idea.
Ma, come al solito, la realtà non è così semplice. L'invio di un pacchetto così grande a una scheda di rete richiede che venga suddiviso in molti pacchetti più piccoli. La normale dimensione di invio è di 1500 byte. Cioè, il nostro gigante di 64 kilobyte sarà diviso in 45 pacchetti (1240 byte di informazioni e 20 byte dell'intestazione IP). Quindi, per un po ', bloccheranno completamente il lavoro della scheda di rete, perché devono essere inviati insieme e contemporaneamente. Di conseguenza, questo porterà a un salto di priorità e i pacchetti come VoIP, ad esempio, verranno messi in coda.
Pertanto, l'elevato throughput che WireGuard afferma con tanta audacia viene ottenuto a costo di rallentare il networking di altre applicazioni. E il team di WireGuard lo è già questa è la mia conclusione.
Ma andiamo avanti.
Secondo i benchmark nella documentazione tecnica, la connessione mostra un throughput di 1011 Mbps.
Impressionante.
Ciò è particolarmente impressionante per il fatto che il throughput teorico massimo di una singola connessione Gigabit Ethernet è di 966 Mbps 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 il WireGuard stesso. C'è un'altra intestazione IP nel pacchetto incapsulato e un'altra in TCP per 20 byte. Quindi da dove viene questa larghezza di banda extra?
Con frame enormi e i vantaggi di GSO di cui abbiamo parlato sopra, il massimo teorico per una dimensione di frame di 9000 byte sarebbe 1014 Mbps. Di solito tale produttività è irraggiungibile nella realtà, perché è associata a grandi difficoltà. Pertanto, posso solo presumere che il test sia stato eseguito utilizzando frame sovradimensionati ancora più grandi di 64 kilobyte con un massimo teorico di 1023 Mbps, supportato solo da alcuni adattatori di rete. Ma questo è assolutamente inapplicabile in condizioni reali, oppure può essere utilizzato solo tra due stazioni collegate direttamente, esclusivamente all'interno del banco prova.
Ma poiché il tunnel VPN viene inoltrato tra due host utilizzando una connessione Internet che non supporta affatto i jumbo frame, il risultato ottenuto sul banco non può essere preso come punto di riferimento. Questo è semplicemente un risultato di laboratorio irrealistico che è impossibile e inapplicabile in condizioni di combattimento reali.
Anche seduto nel data center, non sono riuscito a trasferire frame più grandi di 9000 byte.
Il criterio di applicabilità nella vita reale è assolutamente violato e, a mio avviso, l'autore della "misurazione" effettuata si è seriamente screditato per ovvie ragioni.
Ultimo barlume di speranza
Il sito Web WireGuard parla molto di container e diventa chiaro a cosa è realmente destinato.
Una VPN semplice e veloce che non richiede alcuna configurazione e può essere implementata e configurata con enormi strumenti di orchestrazione come Amazon ha nel proprio cloud. Nello specifico, Amazon utilizza le ultime funzionalità hardware che ho menzionato in precedenza, come l'AVX512. Questo viene fatto per velocizzare il lavoro e non essere legato a x86 oa qualsiasi altra architettura.
Ottimizzano il throughput e i pacchetti più grandi di 9000 byte: questi saranno enormi frame incapsulati per consentire ai contenitori di comunicare tra loro o per operazioni di backup, creazione di istantanee o distribuzione di questi stessi contenitori. Anche gli indirizzi IP dinamici non influiranno in alcun modo sul funzionamento di WireGuard nel caso dello scenario che ho descritto.
Ben fatto. Implementazione brillante e protocollo molto sottile, quasi di riferimento.
Ma semplicemente non si adatta a un mondo al di fuori di un data center che controlli completamente. Se corri il rischio e inizi a utilizzare WireGuard, dovrai scendere a compromessi costanti nella progettazione e nell'implementazione del protocollo di crittografia.
conclusione
È facile per me concludere che WireGuard non è ancora pronto.
È stato concepito come una soluzione leggera e rapida a una serie di problemi con soluzioni esistenti. Sfortunatamente, per il bene di queste soluzioni, ha sacrificato molte funzionalità che saranno rilevanti per la maggior parte degli utenti. Ecco perché non può sostituire IPsec o OpenVPN.
Affinché WireGuard diventi competitivo, deve aggiungere almeno un'impostazione dell'indirizzo IP e una configurazione di routing e DNS. Ovviamente, questo è lo scopo dei canali crittografati.
La sicurezza è la mia massima priorità e in questo momento non ho motivo di credere che IKE o TLS siano in qualche modo compromessi o rotti. La crittografia moderna è supportata in entrambi e sono stati dimostrati da decenni di funzionamento. Solo perché qualcosa è più recente non significa che sia migliore.
L'interoperabilità è estremamente importante quando comunichi con terze parti di cui non controlli le stazioni. IPsec è lo standard de facto ed è supportato quasi ovunque. E lavora. E non importa come sembri, in teoria, WireGuard in futuro potrebbe non essere compatibile anche con versioni diverse di se stesso.
Qualsiasi protezione crittografica prima o poi viene interrotta e, di conseguenza, deve essere sostituita o aggiornata.
Negare tutti questi fatti e voler ciecamente utilizzare WireGuard per connettere il tuo iPhone alla tua workstation domestica è solo una lezione di perfezionamento per mettere la testa sotto la sabbia.
Fonte: habr.com