WireGuard ha estat cridant molta atenció últimament, de fet, és la nova estrella entre les VPN. Però és tan bo com sembla? M'agradaria discutir algunes observacions i revisar la implementació de WireGuard per explicar per què no és una solució per substituir IPsec o OpenVPN.
En aquest article, m'agradaria desmentir alguns dels mites [al voltant de WireGuard]. Sí, trigarà molt a llegir-lo, així que si no us heu preparat una tassa de te o cafè, és hora de fer-ho. També m'agradaria donar les gràcies a Peter per corregir els meus pensaments caòtics.
No em poso l'objectiu de desacreditar els desenvolupadors de WireGuard, devaluant els seus esforços o idees. El seu producte funciona, però personalment crec que es presenta completament diferent del que és realment: es presenta com un reemplaçament d'IPsec i OpenVPN, que de fet simplement no existeixen ara.
Com a nota, m'agradaria afegir que la responsabilitat d'aquest posicionament de WireGuard recau en els mitjans de comunicació que n'han parlat, i no en el propi projecte o els seus creadors.
Darrerament no hi ha gaires bones notícies sobre el nucli Linux. Així doncs, se'ns va parlar de les monstruoses vulnerabilitats del processador, que van ser anivellades pel programari, i Linus Torvalds en va parlar amb massa grollera i avorriment, en el llenguatge utilitari del desenvolupador. Un programador o una pila de xarxa de nivell zero tampoc són temes molt clars per a les revistes brillants. I aquí ve WireGuard.
Sobre el paper, tot sona genial: una nova tecnologia emocionant.
Però mirem-ho una mica més de prop.
Llibre blanc WireGuard
Aquest article es basa en escrit per Jason Donenfeld. Allà explica el concepte, el propòsit i la implementació tècnica de [WireGuard] al nucli Linux.
La primera frase diu:
WireGuard […] pretén substituir tant IPsec en la majoria dels casos d'ús com altres solucions populars basades en espais d'usuari i/o TLS com OpenVPN, alhora que és més segura, eficient i més fàcil d'utilitzar [eina].
Per descomptat, el principal avantatge de totes les noves tecnologies és la seva simplicitat [en comparació amb els predecessors]. Però una VPN també ho hauria de ser eficient i segur.
Aleshores, què passa?
Si dieu que això no és el que necessiteu [d'una VPN], podeu acabar la lectura aquí. Tanmateix, notaré que aquestes tasques s'estableixen per a qualsevol altra tecnologia de túnel.
El més interessant de la cita anterior rau en les paraules "en la majoria dels casos", que, per descomptat, van ser ignorades per la premsa. I així, som on vam acabar a causa del caos creat per aquesta negligència -en aquest article.
WireGuard substituirà la meva VPN de lloc a lloc [IPsec]?
No. Simplement no hi ha cap possibilitat que grans venedors com Cisco, Juniper i altres adquireixin WireGuard per als seus productes. No "salten sobre trens que passen" en moviment tret que hi hagi una gran necessitat de fer-ho. Més endavant, repassaré alguns dels motius pels quals probablement no podran incorporar els seus productes WireGuard encara que ho vulguin.
WireGuard portarà el meu RoadWarrior del meu portàtil al centre de dades?
No. Ara mateix, WireGuard no té un gran nombre de funcions importants implementades perquè pugui fer alguna cosa com això. Per exemple, no pot utilitzar adreces IP dinàmiques al costat del servidor del túnel, i això només trenca tot l'escenari d'aquest ús del producte.
IPFire s'utilitza sovint per a enllaços d'Internet barats, com ara connexions DSL o per cable. Això té sentit per a les petites o mitjanes empreses que no necessiten fibra ràpida. [Nota del traductor: no oblideu que pel que fa a la comunicació, Rússia i alguns països de la CEI estan molt per davant d'Europa i els Estats Units, perquè vam començar a construir les nostres xarxes molt més tard i amb l'arribada de les xarxes Ethernet i de fibra òptica com a estàndard, ens va ser més fàcil reconstruir. Als mateixos països de la UE o els EUA, l'accés de banda ampla xDSL a una velocitat de 3-5 Mbps segueix sent la norma general, i una connexió de fibra òptica costa diners poc realistes segons els nostres estàndards. Per tant, l'autor de l'article parla de la connexió DSL o per cable com a norma, i no de temps antics.] Tanmateix, DSL, cable, LTE (i altres mètodes d'accés sense fil) tenen adreces IP dinàmiques. Per descomptat, de vegades no canvien sovint, però sí que canvien.
Hi ha un subprojecte anomenat , que afegeix un dimoni d'espai d'usuari per superar aquesta deficiència. Un gran problema amb l'escenari d'usuari descrit anteriorment és l'agreujament de l'adreçament IPv6 dinàmic.
Des del punt de vista del distribuïdor, tot això tampoc es veu molt bé. Un dels objectius del disseny era mantenir el protocol senzill i net.
Malauradament, tot això s'ha tornat massa senzill i primitiu, de manera que hem d'utilitzar programari addicional per tal que tot aquest disseny sigui viable en un ús real.
És tan fàcil d'utilitzar WireGuard?
Encara no. No dic que WireGuard mai serà una bona alternativa per fer túnels entre dos punts, però de moment només és una versió alfa del producte que se suposa que és.
Però llavors què fa realment? IPsec és realment molt més difícil de mantenir?
Evidentment que no. El venedor d'IPsec ha pensat en això i envia el seu producte juntament amb una interfície, com ara IPFire.
Per configurar un túnel VPN a través d'IPsec, necessitareu cinc conjunts de dades que haureu d'introduir a la configuració: la vostra pròpia adreça IP pública, l'adreça IP pública de la part receptora, les subxarxes que voleu fer públiques mitjançant aquesta connexió VPN i clau prèviament compartida. Així, la VPN es configura en qüestió de minuts i és compatible amb qualsevol proveïdor.
Malauradament, hi ha algunes excepcions a aquesta història. Qualsevol que hagi intentat fer un túnel per IPsec a una màquina OpenBSD sap de què estic parlant. Hi ha un parell d'exemples més dolorosos, però de fet, hi ha moltes i moltes més bones pràctiques per utilitzar IPsec.
Sobre la complexitat del protocol
L'usuari final no s'ha de preocupar per la complexitat del protocol.
Si visquéssim en un món on això fos una preocupació real de l'usuari, llavors ens hauríem desfet del SIP, H.323, FTP i altres protocols creats fa més de deu anys que no funcionen bé amb NAT.
Hi ha raons per les quals IPsec és més complex que WireGuard: fa moltes més coses. Per exemple, l'autenticació d'usuari mitjançant un inici de sessió/contrasenya o una targeta SIM amb EAP. Té una capacitat ampliada per afegir nous .
I WireGuard no té això.
I això vol dir que WireGuard es trencarà en algun moment, perquè una de les primitives criptogràfiques es debilitarà o quedarà completament compromesa. L'autor de la documentació tècnica diu això:
Val la pena assenyalar que WireGuard té una opinió criptogràfica. No té deliberadament la flexibilitat de xifratge i protocols. Si es troben forats greus a les primitives subjacents, caldrà actualitzar tots els punts finals. Com podeu veure a partir del flux continu de vulnerabilitats SLL/TLS, la flexibilitat del xifratge ha augmentat enormement.
L'última frase és absolutament correcta.
Arribar a un consens sobre quin xifratge utilitzar fa protocols com IKE i TLS més complex. Massa complicat? Sí, les vulnerabilitats són força comunes a TLS/SSL i no hi ha alternativa.
En ignorar els problemes reals
Imagineu que teniu un servidor VPN amb 200 clients de combat a tot el món. Aquest és un cas d'ús bastant estàndard. Si heu de canviar el xifratge, haureu de lliurar l'actualització a totes les còpies de WireGuard en aquests ordinadors portàtils, telèfons intel·ligents, etc. Simultàniament lliurar. És literalment impossible. Els administradors que intentin fer-ho trigaran mesos a desplegar les configuracions necessàries i, literalment, una empresa mitjana trigarà anys a aconseguir aquest esdeveniment.
IPsec i OpenVPN ofereixen una funció de negociació de xifrat. Per tant, durant un temps després del qual activeu el xifratge nou, l'antic també funcionarà. Això permetrà als clients actuals actualitzar a la nova versió. Després de llançar l'actualització, només cal que desactiveu el xifratge vulnerable. I ja està! A punt! ets preciosa! Els clients ni tan sols ho notaran.
En realitat, aquest és un cas molt comú per a grans desplegaments, i fins i tot OpenVPN té algunes dificultats amb això. La compatibilitat enrere és important i, tot i que utilitzeu un xifratge més feble, per a molts, aquest no és un motiu per tancar un negoci. Perquè paralitzarà la feina de centenars de clients per la impossibilitat de fer la seva feina.
L'equip de WireGuard ha fet que el seu protocol sigui més senzill, però completament inutilitzable per a persones que no tenen un control constant sobre els dos companys del seu túnel. Segons la meva experiència, aquest és l'escenari més comú.
Criptografia!
Però, què és aquest nou xifratge interessant que utilitza WireGuard?
WireGuard utilitza Curve25519 per a l'intercanvi de claus, ChaCha20 per a l'encriptació i Poly1305 per a l'autenticació de dades. També funciona amb SipHash per a claus hash i BLAKE2 per hash.
ChaCha20-Poly1305 està estandarditzat per a IPsec i OpenVPN (a través de TLS).
És obvi que el desenvolupament de Daniel Bernstein s'utilitza molt sovint. BLAKE2 és el successor de BLAKE, un finalista SHA-3 que no va guanyar per la seva similitud amb SHA-2. Si s'hagués de trencar SHA-2, hi havia moltes possibilitats que BLAKE també es veiés compromès.
IPsec i OpenVPN no necessiten SipHash a causa del seu disseny. Així que l'únic que actualment no es pot utilitzar amb ells és BLAKE2, i això només fins que s'estandarditzi. Això no és un gran inconvenient, perquè les VPN utilitzen HMAC per crear integritat, que es considera una solució sòlida fins i tot juntament amb MD5.
Així que vaig arribar a la conclusió que s'utilitza gairebé el mateix conjunt d'eines criptogràfiques a totes les VPN. Per tant, WireGuard no és ni més ni menys segur que qualsevol altre producte actual pel que fa a l'encriptació o la integritat de les dades transmeses.
Però fins i tot això no és el més important, que val la pena parar atenció segons la documentació oficial del projecte. Després de tot, el més important és la velocitat.
WireGuard és més ràpid que altres solucions VPN?
En resum: no, no més ràpid.
ChaCha20 és un xifratge de flux que és més fàcil d'implementar al programari. Xifra un bit a la vegada. Els protocols de bloc com AES xifren un bloc de 128 bits alhora. Es necessiten molts més transistors per implementar el suport de maquinari, de manera que els processadors més grans inclouen AES-NI, una extensió de conjunt d'instruccions que realitza algunes de les tasques del procés de xifratge per accelerar-lo.
S'esperava que AES-NI mai entraria als telèfons intel·ligents [però ho va fer, aprox. per.]. Per això, el ChaCha20 es va desenvolupar com una alternativa lleugera i d'estalvi de bateria. Per tant, us pot ser una notícia que tots els telèfons intel·ligents que podeu comprar avui tenen algun tipus d'acceleració AES i funcionen més ràpid i amb un consum d'energia menor amb aquest xifratge que amb ChaCha20.
Òbviament, gairebé tots els processadors d'escriptori/servidor comprats en els últims dos anys tenen AES-NI.
Per tant, espero que AES superi el ChaCha20 en tots els escenaris. La documentació oficial de WireGuard esmenta que amb AVX512, ChaCha20-Poly1305 superarà a AES-NI, però aquesta extensió de conjunt d'instruccions només estarà disponible en CPU més grans, cosa que de nou no ajudarà amb un maquinari més petit i mòbil, que sempre serà més ràpid amb AES. - N.I.
No sé si això es podria haver previst durant el desenvolupament de WireGuard, però avui el fet que estigui clavat només en el xifratge ja és un inconvenient que potser no afecta gaire el seu funcionament.
IPsec us permet triar lliurement quin xifratge és millor per al vostre cas. I, per descomptat, això és necessari si, per exemple, voleu transferir 10 o més gigabytes de dades mitjançant una connexió VPN.
Problemes d'integració a Linux
Tot i que WireGuard ha escollit un protocol de xifratge modern, això ja provoca molts problemes. Per tant, en comptes d'utilitzar el que és compatible amb el nucli fora de la caixa, la integració de WireGuard s'ha retardat durant anys a causa de la manca d'aquestes primitives a Linux.
No estic del tot segur de quina és la situació en altres sistemes operatius, però probablement no sigui gaire diferent que a Linux.
Com és la realitat?
Malauradament, cada vegada que un client em demana que configureu una connexió VPN per a ells, em trobo amb el problema que utilitzen credencials i xifratge obsolets. 3DES juntament amb MD5 encara és una pràctica habitual, igual que AES-256 i SHA1. I tot i que aquest últim és una mica millor, això no és una cosa que s'hauria d'utilitzar el 2020.
Per a l'intercanvi de claus sempre S'utilitza RSA, una eina lenta però bastant segura.
Els meus clients estan associats amb autoritats duaneres i altres organitzacions i institucions governamentals, així com amb grans corporacions els noms de les quals són coneguts a tot el món. Tots utilitzen un formulari de sol·licitud que es va crear fa dècades i la possibilitat d'utilitzar SHA-512 simplement no es va afegir mai. No puc dir que d'alguna manera afecti clarament el progrés tecnològic, però òbviament frena el procés corporatiu.
Em fa pena veure-ho perquè IPsec admet corbes el·líptiques des del 2005. Curve25519 també és més recent i està disponible per al seu ús. També hi ha alternatives a AES com Camellia i ChaCha20, però òbviament no totes són compatibles amb els principals venedors com Cisco i altres.
I la gent ho aprofita. Hi ha molts kits de Cisco, hi ha molts kits dissenyats per funcionar amb Cisco. Són líders del mercat en aquest segment i no estan molt interessats en cap tipus d'innovació.
Sí, la situació [en el segment corporatiu] és terrible, però no veurem cap canvi a causa de WireGuard. Probablement, els venedors mai no veuran cap problema de rendiment amb les eines i el xifratge que ja estan utilitzant, no veuran cap problema amb IKEv2 i, per tant, no busquen alternatives.
En general, heu pensat mai a abandonar Cisco?
Punts de referència
I ara passem als punts de referència de la documentació de WireGuard. Tot i que aquesta [documentació] no és un article científic, encara esperava que els desenvolupadors adoptessin un enfocament més científic o utilitzessin un enfocament científic com a referència. Qualsevol punt de referència és inútil si no es pot reproduir, i encara més quan s'obtenen al laboratori.
A la versió Linux de WireGuard, aprofita l'ús de GSO - Generic Segmentation Offloading. Gràcies a ell, el client crea un paquet enorme de 64 kilobytes i el xifra/desxifra d'una vegada. Així, es redueix el cost d'invocar i implementar operacions criptogràfiques. Si voleu maximitzar el rendiment de la vostra connexió VPN, aquesta és una bona idea.
Però, com és habitual, la realitat no és tan senzilla. L'enviament d'un paquet tan gran a un adaptador de xarxa requereix que es talli en molts paquets més petits. La mida d'enviament normal és de 1500 bytes. És a dir, el nostre gegant de 64 kilobytes estarà dividit en 45 paquets (1240 bytes d'informació i 20 bytes de la capçalera IP). Aleshores, durant un temps, bloquejaran completament el treball de l'adaptador de xarxa, perquè s'han d'enviar junts i alhora. Com a resultat, això comportarà un salt de prioritat i paquets com ara VoIP, per exemple, es posaran a la cua.
Així, l'alt rendiment que WireGuard afirma amb tanta valentia s'aconsegueix a costa de frenar la connexió en xarxa d'altres aplicacions. I l'equip de WireGuard ja ho és aquesta és la meva conclusió.
Però seguim endavant.
Segons els punts de referència de la documentació tècnica, la connexió mostra un rendiment de 1011 Mbps.
Impressionant.
Això és especialment impressionant pel fet que el rendiment màxim teòric d'una única connexió Gigabit Ethernet és de 966 Mbps amb una mida de paquet de 1500 bytes menys 20 bytes per a la capçalera IP, 8 bytes per a la capçalera UDP i 16 bytes per a la capçalera de el mateix WireGuard. Hi ha una capçalera IP més al paquet encapsulat i una altra a TCP per a 20 bytes. Llavors, d'on prové aquest ample de banda addicional?
Amb fotogrames enormes i els avantatges de GSO dels quals hem parlat anteriorment, el màxim teòric per a una mida de fotograma de 9000 bytes seria de 1014 Mbps. En general, aquest rendiment és inassolible en realitat, perquè està associat a grans dificultats. Per tant, només puc suposar que la prova es va realitzar utilitzant fotogrames de gran mida encara més grossos de 64 kilobytes amb un màxim teòric de 1023 Mbps, que només són compatibles amb alguns adaptadors de xarxa. Però això és absolutament inaplicable en condicions reals, o només es pot utilitzar entre dues estacions connectades directament, exclusivament dins del banc de proves.
Però com que el túnel VPN es reenvia entre dos amfitrions mitjançant una connexió a Internet que no admet en absolut trames jumbo, el resultat aconseguit al banc no es pot prendre com a referència. Aquest és simplement un assoliment de laboratori poc realista que és impossible i inaplicable en condicions de combat reals.
Fins i tot assegut al centre de dades, no vaig poder transferir fotogrames de més de 9000 bytes.
Es vulnera absolutament el criteri d'aplicabilitat a la vida real i, com crec, l'autor de la "mesura" realitzada es va desacreditar seriosament per raons òbvies.
Últim esclat d'esperança
El lloc web de WireGuard parla molt de contenidors i queda clar a què es destina realment.
Una VPN senzilla i ràpida que no requereix cap configuració i que es pot desplegar i configurar amb eines d'orquestració massives com Amazon té al seu núvol. Concretament, Amazon utilitza les últimes funcions de maquinari que he esmentat anteriorment, com ara l'AVX512. Això es fa per accelerar el treball i no estar lligat a x86 o cap altra arquitectura.
Optimitzen el rendiment i els paquets de més de 9000 bytes: seran grans marcs encapsulats perquè els contenidors es comuniquin entre ells o per a operacions de còpia de seguretat, crear instantànies o desplegar aquests mateixos contenidors. Fins i tot les adreces IP dinàmiques no afectaran el funcionament de WireGuard de cap manera en el cas de l'escenari que vaig descriure.
Ben jugat. Implementació brillant i protocol molt prim, gairebé de referència.
Però simplement no encaixa en un món fora d'un centre de dades que controleu completament. Si us arrisqueu i comenceu a utilitzar WireGuard, haureu de comprometre constantment el disseny i la implementació del protocol de xifratge.
Sortida
És fàcil per a mi concloure que WireGuard encara no està preparat.
Va ser concebut com una solució lleugera i ràpida a una sèrie de problemes amb les solucions existents. Malauradament, pel bé d'aquestes solucions, va sacrificar moltes funcions que seran rellevants per a la majoria dels usuaris. És per això que no pot substituir IPsec o OpenVPN.
Perquè WireGuard sigui competitiu, ha d'afegir almenys una configuració d'adreça IP i una configuració d'encaminament i DNS. Òbviament, per això serveixen els canals xifrats.
La seguretat és la meva principal prioritat, i ara mateix no tinc cap motiu per creure que IKE o TLS estiguin compromesos o trencats d'alguna manera. Ambdós admeten el xifratge modern i s'han demostrat amb dècades de funcionament. Que alguna cosa sigui més nova no vol dir que sigui millor.
La interoperabilitat és extremadament important quan us comuniqueu amb tercers les estacions dels quals no controleu. IPsec és l'estàndard de facto i s'admet gairebé a tot arreu. I treballa. I no importa com sembli, en teoria, WireGuard en el futur pot no ser compatible fins i tot amb diferents versions de si mateix.
Qualsevol protecció criptogràfica es trenca tard o d'hora i, en conseqüència, s'ha de substituir o actualitzar.
Negar tots aquests fets i voler cegament utilitzar WireGuard per connectar el vostre iPhone a la vostra estació de treball de casa és només una classe magistral per ficar el cap a la sorra.
Font: www.habr.com
