WireGuard a câștigat multă atenție în ultima vreme, de fapt este noua vedetă printre VPN-uri. Dar este la fel de bun pe cât pare? Aș dori să discut câteva observații și să revizuiesc implementarea WireGuard pentru a explica de ce nu este o soluție pentru a înlocui IPsec sau OpenVPN.
În acest articol, aș dori să dezminți unele dintre miturile [în jurul WireGuard]. Da, va dura mult timp să citești, așa că dacă nu ți-ai făcut singur o ceașcă de ceai sau cafea, atunci este timpul să o faci. De asemenea, aș dori să-i mulțumesc lui Peter pentru că mi-a corectat gândurile haotice.
Nu mi-am propus să-i discreditez pe dezvoltatorii WireGuard, să le devalorizez eforturile sau ideile. Produsul lor funcționează, dar personal cred că este prezentat complet diferit de ceea ce este în realitate - este prezentat ca un înlocuitor pentru IPsec și OpenVPN, care de fapt pur și simplu nu există acum.
Ca o notă, aș dori să adaug că responsabilitatea pentru o astfel de poziționare a WireGuard revine mass-media care a vorbit despre aceasta, și nu proiectul în sine sau creatorii săi.
Nu au fost prea multe vești bune despre kernel-ul Linux în ultima vreme. Așadar, ni s-a spus despre vulnerabilitățile monstruoase ale procesorului, care au fost nivelate de software, iar Linus Torvalds a vorbit despre asta prea grosolan și plictisitor, în limbajul utilitar al dezvoltatorului. Un planificator sau o stivă de rețea de nivel zero nu sunt, de asemenea, subiecte foarte clare pentru revistele lucioase. Și iată că vine WireGuard.
Pe hârtie, totul sună grozav: o nouă tehnologie interesantă.
Dar să ne uităm puțin mai atent.
Hârtie albă WireGuard
Acest articol se bazează pe scris de Jason Donenfeld. Acolo explică conceptul, scopul și implementarea tehnică a [WireGuard] în nucleul Linux.
Prima propoziție spune:
WireGuard […] își propune să înlocuiască atât IPsec în majoritatea cazurilor de utilizare, cât și alte soluții populare bazate pe spațiu de utilizator și/sau TLS, cum ar fi OpenVPN, fiind în același timp mai sigur, performant și mai ușor de utilizat [instrument].
Desigur, principalul avantaj al tuturor noilor tehnologii este lor ușura [comparativ cu predecesorii]. Dar ar trebui să fie și un VPN eficient si sigur.
Deci, ce urmează?
Dacă spuneți că nu este ceea ce aveți nevoie [de la un VPN], atunci puteți încheia lectura aici. Cu toate acestea, voi observa că astfel de sarcini sunt stabilite pentru orice altă tehnologie de tunel.
Cel mai interesant dintre citatul de mai sus constă în cuvintele „în majoritatea cazurilor”, care, desigur, au fost ignorate de presă. Și așa, suntem acolo unde am ajuns din cauza haosului creat de această neglijență – în acest articol.
WireGuard va înlocui VPN-ul meu [IPsec] de la site la site?
Nu. Pur și simplu nu există nicio șansă ca furnizori mari, cum ar fi Cisco, Juniper și alții, să cumpere WireGuard pentru produsele lor. Ei nu „sar în trenurile care trec” în mișcare decât dacă este o nevoie mare de a face acest lucru. Mai târziu, voi trece peste câteva dintre motivele pentru care probabil că nu vor putea să-și introducă produsele WireGuard la bord, chiar dacă și-ar dori.
Va duce WireGuard RoadWarrior-ul meu de pe laptop la centrul de date?
Nu. În acest moment, WireGuard nu are un număr mare de caracteristici importante implementate pentru ca acesta să poată face așa ceva. De exemplu, nu poate folosi adrese IP dinamice pe partea serverului de tunel și numai acest lucru distruge întregul scenariu al unei astfel de utilizări a produsului.
IPFire este adesea folosit pentru conexiuni de internet ieftine, cum ar fi DSL sau conexiuni prin cablu. Acest lucru are sens pentru întreprinderile mici sau mijlocii care nu au nevoie de fibră rapidă. [Notă a traducătorului: nu uitați că în ceea ce privește comunicarea, Rusia și unele țări CSI sunt cu mult înaintea Europei și a Statelor Unite, pentru că am început să ne construim rețelele mult mai târziu și odată cu apariția rețelelor Ethernet și fibră optică ca un standard, ne-a fost mai ușor să reconstruim. În aceleași țări din UE sau SUA, accesul xDSL în bandă largă la o viteză de 3-5 Mbps este încă norma generală, iar o conexiune prin fibră optică costă niște bani nerealişti conform standardelor noastre. Prin urmare, autorul articolului vorbește despre DSL sau conexiunea prin cablu ca normă, și nu despre vremuri străvechi.] Cu toate acestea, DSL, cablu, LTE (și alte metode de acces wireless) au adrese IP dinamice. Desigur, uneori nu se schimbă des, dar se schimbă.
Există un subproiect numit , care adaugă un daemon userspace pentru a depăși acest neajuns. O problemă uriașă cu scenariul utilizatorului descris mai sus este agravarea adresei IPv6 dinamice.
Nici din punctul de vedere al distribuitorului toate acestea nu arată prea bine. Unul dintre obiectivele de proiectare a fost acela de a menține protocolul simplu și curat.
Din păcate, toate acestea au devenit de fapt prea simple și primitive, astfel încât trebuie să folosim software suplimentar pentru ca întregul design să fie viabil în utilizare reală.
Este WireGuard atât de ușor de utilizat?
Nu încă. Nu spun că WireGuard nu va fi niciodată o alternativă bună pentru tunelare între două puncte, dar deocamdată este doar o versiune alfa a produsului care ar trebui să fie.
Dar atunci ce face de fapt? Este chiar atât de greu de întreținut IPsec?
Evident nu. Furnizorul IPsec s-a gândit la acest lucru și își livrează produsul împreună cu o interfață, cum ar fi IPFire.
Pentru a configura un tunel VPN prin IPsec, veți avea nevoie de cinci seturi de date pe care va trebui să le introduceți în configurație: propria dvs. adresă IP publică, adresa IP publică a părții destinatare, subrețelele prin care doriți să le faceți publice. această conexiune VPN și cheia pre-partajată. Astfel, VPN-ul este configurat în câteva minute și este compatibil cu orice furnizor.
Din păcate, există câteva excepții de la această poveste. Oricine a încercat să facă un tunel prin IPsec la o mașină OpenBSD știe despre ce vorbesc. Mai sunt câteva exemple dureroase, dar, de fapt, există multe, multe practici bune pentru utilizarea IPsec.
Despre complexitatea protocolului
Utilizatorul final nu trebuie să-și facă griji cu privire la complexitatea protocolului.
Dacă am trăi într-o lume în care aceasta era o preocupare reală a utilizatorului, atunci am fi scăpat de SIP, H.323, FTP și alte protocoale create cu mai bine de zece ani în urmă care nu funcționează bine cu NAT.
Există motive pentru care IPsec este mai complex decât WireGuard: face mult mai multe lucruri. De exemplu, autentificarea utilizatorului folosind un login/parolă sau o cartelă SIM cu EAP. Are o capacitate extinsă de a adăuga noi .
Și WireGuard nu are asta.
Și asta înseamnă că WireGuard se va rupe la un moment dat, deoarece una dintre primitivele criptografice se va slăbi sau va fi complet compromisă. Autorul documentației tehnice spune așa:
Este demn de remarcat faptul că WireGuard are opinie criptografică. Îi lipsește în mod deliberat flexibilitatea cifrurilor și a protocoalelor. Dacă se găsesc găuri serioase în primitivele subiacente, toate punctele finale vor trebui actualizate. După cum puteți vedea din fluxul continuu de vulnerabilități SLL/TLS, flexibilitatea criptării a crescut acum enorm.
Ultima propoziție este absolut corectă.
Atingerea consensului cu privire la ce criptare să folosească creează protocoale precum IKE și TLS mai mult complex. Prea complicat? Da, vulnerabilitățile sunt destul de comune în TLS/SSL și nu există nicio alternativă la ele.
Despre ignorarea problemelor reale
Imaginați-vă că aveți un server VPN cu 200 de clienți de luptă undeva în lume. Acesta este un caz de utilizare destul de standard. Dacă trebuie să modificați criptarea, trebuie să livrați actualizarea tuturor copiilor WireGuard de pe aceste laptopuri, smartphone-uri și așa mai departe. Simultan livra. Este literalmente imposibil. Administratorii care încearcă să facă acest lucru vor dura luni pentru a implementa configurațiile necesare și, literalmente, o companie de dimensiune medie va dura ani pentru a realiza un astfel de eveniment.
IPsec și OpenVPN oferă o funcție de negociere a cifrului. Prin urmare, pentru un timp după care porniți noua criptare, va funcționa și cea veche. Acest lucru va permite clienților actuali să facă upgrade la noua versiune. După ce actualizarea este lansată, pur și simplu dezactivați criptarea vulnerabilă. Si asta e! Gata! esti superba! Clienții nici nu vor observa.
Acesta este de fapt un caz foarte comun pentru implementări mari și chiar și OpenVPN are unele dificultăți în acest sens. Compatibilitatea inversă este importantă și, chiar dacă utilizați o criptare mai slabă, pentru mulți, acesta nu este un motiv pentru a închide o afacere. Pentru că va paraliza munca a sute de clienți din cauza incapacității de a-și face treaba.
Echipa WireGuard și-a făcut protocolul mai simplu, dar complet inutilizabil pentru persoanele care nu au control constant asupra ambilor colegi din tunelul lor. Din experiența mea, acesta este cel mai frecvent scenariu.
Criptografie!
Dar ce este această nouă criptare interesantă pe care o folosește WireGuard?
WireGuard folosește Curve25519 pentru schimbul de chei, ChaCha20 pentru criptare și Poly1305 pentru autentificarea datelor. De asemenea, funcționează cu SipHash pentru cheile hash și BLAKE2 pentru hashing.
ChaCha20-Poly1305 este standardizat pentru IPsec și OpenVPN (prin TLS).
Este evident că dezvoltarea lui Daniel Bernstein este folosită foarte des. BLAKE2 este succesorul lui BLAKE, un finalist SHA-3 care nu a câștigat din cauza asemănării sale cu SHA-2. Dacă SHA-2 ar fi spart, existau șanse mari ca și BLAKE să fie compromis.
IPsec și OpenVPN nu au nevoie de SipHash datorită designului lor. Deci singurul lucru care nu poate fi folosit în prezent cu ele este BLAKE2 și asta doar până când este standardizat. Acesta nu este un mare dezavantaj, deoarece VPN-urile folosesc HMAC pentru a crea integritate, care este considerată o soluție puternică chiar și împreună cu MD5.
Așa că am ajuns la concluzia că aproape același set de instrumente criptografice este folosit în toate VPN-urile. Prin urmare, WireGuard nu este mai mult sau mai puțin sigur decât orice alt produs actual atunci când vine vorba de criptare sau de integritatea datelor transmise.
Dar chiar și acesta nu este cel mai important lucru, căruia merită să acordați atenție conform documentației oficiale a proiectului. La urma urmei, principalul lucru este viteza.
Este WireGuard mai rapid decât alte soluții VPN?
Pe scurt: nu, nu mai repede.
ChaCha20 este un cifr de flux care este mai ușor de implementat în software. Se criptează câte un bit. Protocoalele de blocare precum AES criptează un bloc pe 128 de biți odată. Sunt necesare mult mai multe tranzistoare pentru implementarea suportului hardware, astfel încât procesoarele mai mari vin cu AES-NI, o extensie de set de instrucțiuni care îndeplinește unele dintre sarcinile procesului de criptare pentru a-l accelera.
Era de așteptat ca AES-NI să nu intre niciodată în smartphone-uri [dar a făcut-o - aprox. pe.]. Pentru aceasta, ChaCha20 a fost dezvoltat ca o alternativă ușoară, care economisește baterie. Prin urmare, s-ar putea să vă spună că fiecare smartphone pe care îl puteți cumpăra astăzi are un fel de accelerare AES și rulează mai rapid și cu un consum mai mic de energie cu această criptare decât cu ChaCha20.
Evident, aproape fiecare procesor desktop/server cumpărat în ultimii doi ani are AES-NI.
Prin urmare, mă aștept ca AES să depășească ChaCha20 în fiecare scenariu. Documentația oficială WireGuard menționează că cu AVX512, ChaCha20-Poly1305 va depăși AES-NI, dar această extensie de set de instrucțiuni va fi disponibilă doar pe procesoarele mai mari, ceea ce din nou nu va ajuta cu hardware mai mic și mai mobil, care va fi întotdeauna mai rapid cu AES. - N.I.
Nu sunt sigur dacă acest lucru ar fi putut fi prevăzut în timpul dezvoltării WireGuard, dar astăzi faptul că este țintuit doar de criptare este deja un dezavantaj care poate să nu-i afecteze foarte bine funcționarea.
IPsec vă permite să alegeți în mod liber care criptare este cea mai bună pentru cazul dvs. Și, desigur, acest lucru este necesar dacă, de exemplu, doriți să transferați 10 sau mai mulți gigaocteți de date printr-o conexiune VPN.
Probleme de integrare în Linux
Deși WireGuard a ales un protocol de criptare modern, acesta provoacă deja o mulțime de probleme. Și astfel, în loc să folosească ceea ce este susținut de kernel din cutie, integrarea WireGuard a fost amânată de ani de zile din cauza lipsei acestor primitive în Linux.
Nu sunt pe deplin sigur care este situația pe alte sisteme de operare, dar probabil că nu este mult diferită față de Linux.
Cum arată realitatea?
Din păcate, de fiecare dată când un client îmi cere să configurez o conexiune VPN pentru ei, mă confrunt cu problema că folosesc acreditări și criptare învechite. 3DES împreună cu MD5 este încă o practică obișnuită, la fel ca și AES-256 și SHA1. Și deși acesta din urmă este puțin mai bun, acesta nu este ceva care ar trebui folosit în 2020.
Pentru schimbul de chei mereu Este folosit RSA - un instrument lent, dar destul de sigur.
Clienții mei sunt asociați cu autoritățile vamale și cu alte organizații și instituții guvernamentale, precum și cu mari corporații ale căror nume sunt cunoscute în întreaga lume. Toți folosesc un formular de solicitare care a fost creat cu zeci de ani în urmă, iar capacitatea de a utiliza SHA-512 pur și simplu nu a fost adăugată niciodată. Nu pot spune că afectează cumva clar progresul tehnologic, dar evident că încetinește procesul corporativ.
Mă doare să văd asta, deoarece IPsec acceptă curbele eliptice din 2005. Curve25519 este, de asemenea, mai nouă și disponibilă pentru utilizare. Există, de asemenea, alternative la AES precum Camellia și ChaCha20, dar evident că nu toate sunt acceptate de furnizori importanți precum Cisco și alții.
Și oamenii profită de asta. Există multe kituri Cisco, există multe kituri concepute pentru a funcționa cu Cisco. Sunt lideri de piață pe acest segment și nu sunt foarte interesați de niciun fel de inovație.
Da, situația [în segmentul corporativ] este teribilă, dar nu vom vedea nicio schimbare din cauza WireGuard. Furnizorii probabil că nu vor vedea niciodată probleme de performanță cu instrumentele și criptarea pe care le folosesc deja, nu vor vedea probleme cu IKEv2 și, prin urmare, nu caută alternative.
În general, te-ai gândit vreodată să renunți la Cisco?
Benchmark-uri
Și acum să trecem la benchmark-urile din documentația WireGuard. Deși această [documentație] nu este un articol științific, mă așteptam totuși ca dezvoltatorii să adopte o abordare mai științifică sau să folosească o abordare științifică ca referință. Orice repere sunt inutile dacă nu pot fi reproduse și cu atât mai inutile când sunt obținute în laborator.
În versiunea Linux a WireGuard, acesta profită de utilizarea GSO - Generic Segmentation Offloading. Datorită lui, clientul creează un pachet uriaș de 64 de kiloocteți și îl criptează/decriptează dintr-o singură mișcare. Astfel, costul de invocare și implementare a operațiunilor criptografice este redus. Dacă doriți să maximizați debitul conexiunii VPN, aceasta este o idee bună.
Dar, ca de obicei, realitatea nu este atât de simplă. Trimiterea unui pachet atât de mare la un adaptor de rețea necesită tăierea acestuia în multe pachete mai mici. Dimensiunea normală de trimitere este de 1500 de octeți. Adică, gigantul nostru de 64 de kilobytes va fi împărțit în 45 de pachete (1240 de octeți de informații și 20 de octeți de antet IP). Apoi, pentru un timp, vor bloca complet funcționarea adaptorului de rețea, deoarece trebuie trimise împreună și deodată. Ca rezultat, acest lucru va duce la un salt de prioritate, iar pachetele precum VoIP, de exemplu, vor fi puse în coadă.
Astfel, debitul mare pe care WireGuard îl pretinde cu atâta îndrăzneală este atins cu prețul încetinirii conectării în rețea a altor aplicații. Și echipa WireGuard este deja aceasta este concluzia mea.
Dar să mergem mai departe.
Conform benchmark-urilor din documentația tehnică, conexiunea arată un throughput de 1011 Mbps.
Impresionant.
Acest lucru este deosebit de impresionant datorită faptului că debitul maxim teoretic al unei singure conexiuni Gigabit Ethernet este de 966 Mbps cu o dimensiune a pachetului de 1500 de octeți minus 20 de octeți pentru antetul IP, 8 octeți pentru antetul UDP și 16 octeți pentru antetul de însuși WireGuard. Mai există un antet IP în pachetul încapsulat și altul în TCP pentru 20 de octeți. Deci, de unde a venit această lățime de bandă suplimentară?
Cu cadre uriașe și beneficiile GSO despre care am vorbit mai sus, maximul teoretic pentru o dimensiune a cadrului de 9000 de octeți ar fi 1014 Mbps. De obicei, un astfel de debit este de neatins în realitate, deoarece este asociat cu mari dificultăți. Astfel, pot doar să presupun că testul a fost efectuat folosind cadre supradimensionate și mai groase de 64 de kiloocteți cu un maxim teoretic de 1023 Mbps, care este suportat doar de unele adaptoare de rețea. Dar acest lucru este absolut inaplicabil în condiții reale, sau poate fi folosit doar între două stații conectate direct, exclusiv în cadrul bancului de testare.
Dar din moment ce tunelul VPN este transmis între două gazde folosind o conexiune la Internet care nu acceptă deloc cadre jumbo, rezultatul obținut pe banc nu poate fi luat drept etalon. Aceasta este pur și simplu o realizare de laborator nerealistă care este imposibilă și inaplicabilă în condiții reale de luptă.
Chiar și stând în centrul de date, nu am putut transfera cadre mai mari de 9000 de octeți.
Criteriul de aplicabilitate în viața reală este încălcat absolut și, după cum cred, autorul „măsurătorii” efectuate s-a discreditat serios din motive evidente.
Ultima licărire de speranță
Site-ul WireGuard vorbește mult despre containere și devine clar pentru ce este destinat cu adevărat.
Un VPN simplu și rapid care nu necesită configurare și poate fi implementat și configurat cu instrumente masive de orchestrare precum Amazon le are în cloud. Mai exact, Amazon folosește cele mai recente caracteristici hardware pe care le-am menționat mai devreme, cum ar fi AVX512. Acest lucru se face pentru a accelera munca și pentru a nu fi legat de x86 sau de orice altă arhitectură.
Ele optimizează debitul și pachetele mai mari de 9000 de octeți - acestea vor fi cadre uriașe încapsulate pentru ca containerele să comunice între ele sau pentru operațiuni de backup, crearea de instantanee sau implementarea acestor containere. Nici măcar adresele IP dinamice nu vor afecta în niciun fel funcționarea WireGuard în cazul scenariului pe care l-am descris.
Bine jucat. Implementare genială și protocol foarte subțire, aproape de referință.
Dar pur și simplu nu se potrivește într-o lume din afara unui centru de date pe care îl controlați complet. Dacă vă asumați riscul și începeți să utilizați WireGuard, va trebui să faceți compromisuri constante în proiectarea și implementarea protocolului de criptare.
Producție
Îmi este ușor să trag concluzia că WireGuard nu este încă gata.
A fost conceput ca o soluție ușoară și rapidă la o serie de probleme cu soluțiile existente. Din păcate, de dragul acestor soluții, a sacrificat multe funcții care vor fi relevante pentru majoritatea utilizatorilor. De aceea nu poate înlocui IPsec sau OpenVPN.
Pentru ca WireGuard să devină competitiv, trebuie să adauge cel puțin o setare de adresă IP și o configurație de rutare și DNS. Evident, pentru asta sunt canalele criptate.
Securitatea este prioritatea mea principală și în acest moment nu am niciun motiv să cred că IKE sau TLS sunt cumva compromise sau rupte. Criptarea modernă este acceptată în ambele și au fost dovedite prin decenii de funcționare. Doar pentru că ceva este mai nou nu înseamnă că este mai bun.
Interoperabilitatea este extrem de importantă atunci când comunicați cu terțe părți ale căror stații nu le controlați. IPsec este standardul de facto și este acceptat aproape peste tot. Și lucrează. Și indiferent de cum arată, în teorie, WireGuard în viitor ar putea să nu fie compatibil chiar și cu diferite versiuni ale lui.
Orice protecție criptografică este ruptă mai devreme sau mai târziu și, în consecință, trebuie înlocuită sau actualizată.
A nega toate aceste fapte și a dori orbește să folosești WireGuard pentru a-ți conecta iPhone-ul la stația de lucru de acasă este doar o clasă de master în a-ți băga capul în nisip.
Sursa: www.habr.com