În ultima vreme, WireGuard a atras multă atenție, devenind practic o nouă „stea” printre VPN. Dar este el atât de bun pe cât pare? Aș dori să discut câteva observații și să analizez implementarea WireGuard pentru a explica de ce nu este o soluție care să înlocuiască IPsec sau OpenVPN.
În acest articol, aș dori să desființez câteva mituri [în jurul WireGuard]. Da, va trebui să citești mult, așa că, dacă nu ți-ai făcut încă o ceașcă de ceai sau cafea, acum este momentul să o faci. De asemenea, aș dori să-i mulțumesc lui Peter pentru corectarea gândurilor mele haotice.
Nu îmi propun să discreditez dezvoltatorii WireGuard, să devalorizez eforturile sau ideile lor. Produsul lor este funcțional, dar consider că este prezentat complet diferit față de ceea ce este în realitate - ca o înlocuire a IPsec și OpenVPN, care de fapt nu există acum.
Aș dori să menționez că responsabilitatea pentru această poziționare a WireGuard o poartă mass-media care a vorbit despre el, nu proiectul sau creatorii săi.
În ultima vreme, nu au fost multe vești bune legate de nucleul Linux. Ni s-au prezentat astfel de vulnerabilități monstruoase ale procesorului, care au fost neutralizate prin metode software, iar Linus Torvalds a discutat despre acestea într-un mod prea grosolan și plictisitor, utilizând un limbaj utilitar de dezvoltator. Planificatorul sau stiva de rețea de nivel zero nu sunt teme foarte ușor de înțeles pentru revistele de specialitate. Și aici apare WireGuard.
Pe hârtie, totul sună grozav: o nouă tehnologie captivantă.
Dar să o privim puțin mai atent.
Documentația tehnică WireGuard
Acest articol se bazează pe documentația oficială WireGuard, scrisă de Jason Donenfeld. Acolo el 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țiul utilizatorului și/sau TLS, cum ar fi OpenVPN, fiind totodată un [instrument] mai sigur, mai performant și mai ușor de folosit.
Desigur, principalul avantaj al tuturor noilor tehnologii este simplicitatea [în comparație cu predecesorii]. Dar VPN-ul trebuie să fie de asemenea eficient și sigur.
Și ce urmează?
Dacă spuneți că nu aveți nevoie de [VPN] acesta, atunci aici se poate încheia lectura. Totuși, aș observa că astfel de sarcini sunt adesea întâlnite în fața oricărei alte tehnologii de tunelare.
Ceea ce este cel mai interesant din citatul de mai sus se află în cuvintele „în cele mai multe cazuri”, care, desigur, au fost ignorate de presă. Și iată-ne, acolo unde ne aflăm din cauza haosului creat de această neglijență — în acest articol.
Va deveni WireGuard o înlocuire pentru VPN-ul meu [IPsec] între site-uri?
Nu. Pur și simplu nu există șanse ca marii furnizori, cum ar fi Cisco, Juniper și alții, să adopte WireGuard pentru produsele lor. Ei nu „sar în trenurile care trec pe lângă” fără un motiv întemeiat. Mai târziu, voi explica câteva motive pentru care este puțin probabil să integreze WireGuard în produsele lor, chiar dacă și-ar dori.
Va transfera WireGuard RoadWarrior-ul meu de pe laptop la centrul de date?
Nu. În acest moment, WireGuard nu dispune de un număr semnificativ de funcții esențiale pentru a realiza ceva similar. De exemplu, nu poate folosi adrese IP dinamice pe partea serverului tunelului, iar acest lucru strică întregul scenariu de utilizare a produsului.
IPFire este adesea folosit pentru canale de internet ieftine, cum ar fi DSL sau conexiuni de cablu. Acest lucru are sens pentru micile sau mediile afaceri, care nu necesită fibră optică rapidă. [Nota translatorului: nu trebuie să uităm că, în ceea ce privește conectivitatea, Rusia și unele țări din CSI sunt cu mult înaintea Europei și a SUA, deoarece am început să ne construim rețelele mult mai târziu și, odată cu venirea Ethernet-ului și a rețelelor de fibră optică ca standard, ne-a fost mai ușor să ne adaptăm. În aceleași țări din UE sau SUA, accesul lățimii de bandă xDSL la viteze de 3-5 Mbps — este încă norma generală, iar conexiunea de fibră optică costă niște sume imposibile pentru standardele noastre. De aceea autorul articolului vorbește despre conexiuni DSL sau de cablu, ca fiind norma, și nu o relicvă învechită.] Totuși, conexiunile DSL, de cablu, LTE (și alte metode de acces wireless) au adrese IP dinamice. Desigur, deși se schimbă, acest lucru nu se întâmplă des, dar totuși se schimbă.
Există un subproiect numit „wg-dynamic”, care adaugă un demon de spațiu utilizator pentru a depăși această deficiență. O mare problemă a scenariului utilizatorului descris mai sus este agravarea situației prin adresarea dinamică IPv6.
Din perspectiva distribuitorului, totul acesta nu arată foarte bine. Una dintre obiectivele dezvoltării a fost menținerea simplității și clarității protocolului.
Din păcate, toate acestea au devenit în realitate prea simple și primitive, astfel că trebuie să utilizăm software suplimentar pentru ca întreaga construcție să fie viabilă în condiții de utilizare reală.
Este WireGuard atât de simplu de folosit?
Deocamdată nu. Nu spun că WireGuard nu va fi vreodată o alternativă bună pentru tunelarea între două puncte, dar deocamdată este doar o versiune alfa a produsului care ar trebui să devină.
Dar ce face el de fapt? Este IPsec într-adevăr atât de complex în exploatare?
Evident că nu. Furnizorul IPsec a gândit acest aspect și își livrează produsul împreună cu un interfață, de exemplu, cu IPFire.
Pentru a seta un tunel VPN prin IPsec, aveți nevoie de cinci seturi de date care trebuie introduse în configurație: adresa dvs. IP publică, adresa IP publică a părții receptor, subrețelele pe care doriți să le faceți accesibile prin această conexiune VPN și cheia pre-shared. Astfel, VPN-ul se configurează în câteva minute și este compatibil cu orice furnizor.
Din păcate, în această poveste există câteva excepții. Oricine a încercat să tunelizeze un VPN prin IPsec la o mașină pe OpenBSD înțelege despre ce vorbesc. Există și câteva exemple dureroase, dar în realitate, practica pozitivă a utilizării IPsec este mult, mult mai vastă.
Despre complexitatea protocolului
Consumatorul final nu ar trebui să se preocupe de complexitatea protocolului.
Dacă am trăi într-o lume în care aceasta ar fi o reală îngrijorare pentru utilizator, ne-am fi scăpat demult de SIP, H.323, FTP și alte protocoale create acum mai bine de zece ani, care funcționează prost cu NAT.
Există motive pentru care IPsec este mai complex decât WireGuard: acesta face mult mai multe lucruri. De exemplu, autentificarea utilizatorului folosind login/parola sau SIM cu EAP. Are o capacitate extinsă de a adăuga noi primitivi criptografici.
Iar WireGuard nu are acest lucru.
Și asta înseamnă că WireGuard se va defecta în vreun moment, deoarece unul dintre primitivele criptografice se va slăbi sau va fi complet compromis. Autorul documentației tehnice spune acest lucru astfel:
Este important de menționat că WireGuard este criptografic autoîncrezător. Îi lipsește intenționat flexibilitatea algoritmilor și protocoalelor de criptare. Dacă în primitivele de bază vor fi descoperite breșe serioase, toate punctele finale vor necesita actualizare. Așa cum se vede din fluxul continuu de vulnerabilități SLL/TLS, flexibilitatea criptării a crescut enorm în prezent.
Ultima propoziție este absolut corectă.
Atingerea consensului cu privire la ce criptare să folosești face ca protocoalele de tip IKE și TLS peste să fie complicate. Prea complicate? Da, în TLS/SSL vulnerabilitățile apar destul de frecvent și nu există alternative.
Despre ignorarea problemelor reale
Imaginați-vă că aveți un server VPN cu 200 de clienți activi, în diverse colțuri ale lumii. Acesta este un scenariu de utilizare destul de standard. Dacă va trebui să schimbați criptarea, va trebui să livrați actualizări pe toate instanțele WireGuard de pe aceste laptopuri, smartphone-uri și așa mai departe. În același timp, să livrați. Acest lucru este practic imposibil. Administratorii care vor încerca să facă acest lucru vor necesita luni întregi pentru a desfășura configurațiile necesare, iar companiile medii vor avea nevoie de ani întregi pentru a duce la bun sfârșit o astfel de activitate.
IPsec și OpenVPN oferă o funcție de negociere a criptării. Prin urmare, o vreme, după ce activați noua criptare, vechea va funcționa în continuare. Datorită acestui fapt, clienții actuali vor putea să se actualizeze la noua versiune. După ce actualizarea a fost desfășurată, pur și simplu veți dezactiva criptarea vulnerabilă. Și gata! Sunteți uimitori! Și clienții nici nu vor observa.
De fapt, acesta este un caz foarte comun pentru desfășurări mari, iar chiar și OpenVPN întâmpină unele dificultăți în acest sens. Compatibilitatea înapoi este importantă și, deși utilizați criptare mai slabă, pentru mulți acest lucru nu devine un motiv pentru închiderea afacerii. Pentru că ar duce la paralizia activității sute de clienți din cauza incapacității de a-și îndeplini sarcinile.
Echipa WireGuard a simplificat protocolul său, dar este complet neadecvat pentru persoanele care nu au control constant asupra ambelor noduri ale tunelului lor. Din experiența mea, acest scenariu este cel mai comun.
Criptografie!
Dar ce este acest nou tip de criptare interesant pe care îl 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 clar că dezvoltarea lui Daniel Bernstein este utilizată foarte des. BLAKE2 este succesorul lui BLAKE, finalista SHA-3, care nu a câștigat din cauza asemănării cu SHA-2. Dacă SHA-2 ar fi fost compromis, ar fi existat o mare șansă ca și BLAKE să fie afectat.
IPsec și OpenVPN nu necesită SipHash datorită designului lor. Astfel, singurul lucru care nu poate fi folosit în prezent cu acestea este BLAKE2, și aceasta doar până nu va fi standardizat. Nu este o mare neajuns, deoarece VPN-urile folosesc HMAC pentru a asigura integritatea, ceea ce este considerat o soluție robustă chiar și combinată cu MD5.
Așadar, am ajuns la concluzia că toate VPN-urile folosesc practic aceleași seturi de instrumente criptografice. Prin urmare, WireGuard nu este mai sigur și nici mai puțin sigur decât orice alt produs relevant când vine vorba de criptarea sau integritatea datelor transmise.
Dar chiar și aceasta nu este cea mai importantă observație, conform documentației oficiale a proiectului. Ceea ce contează cu adevărat este viteza.
Este WireGuard mai rapid decât celelalte soluții VPN?
Pe scurt: nu, nu este mai rapid.
ChaCha20 este un cifru de flux, care este mai ușor de implementat în software. Criptează un bit de fiecare dată. Protocoalele pe bloc, cum ar fi AES, criptează blocuri de 128 de biți deodată. Implementarea suportului hardware necesită mult mai mulți transistori, astfel încât procesoarele mai mari vin cu AES-NI — o extensie a setului de instrucțiuni care efectuează anumite sarcini ale procesului de criptare pentru a-l accelera.
Se aștepta ca AES-NI să nu ajungă niciodată în smartphone-uri [dar a ajuns, — nota trad.]. Pentru aceasta a fost dezvoltat ChaCha20 — ca o alternativă ușoară și economică, care economisește bateria. De aceea, s-ar putea să fie o noutate pentru tine că fiecare smartphone pe care poți să-l achiziționezi astăzi are o formă de accelerare pentru AES și funcționează cu această criptare mai repede și cu un consum de energie mai mic decât cu ChaCha20.
Este evident că practic fiecare procesor pentru PC-uri desktop / servere cumpărat în ultimii câțiva ani are AES-NI.
Prin urmare, mă aștept ca AES să depășească ChaCha20 în fiecare scenariu specific. În documentația oficială WireGuard se menționează că datorită AVX512, ChaCha20-Poly1305 va depăși AES-NI, dar această extensie de set de instrucțiuni va fi disponibilă doar pe procesoare mari, ceea ce din nou nu va ajuta la echipamentele mai mici și mobile, care vor funcționa întotdeauna mai rapid cu AES-NI.
Nu sunt sigur dacă acest lucru a fost prevăzut la dezvoltarea WireGuard, dar azi faptul că este „constrâns” la o singură criptare reprezintă deja un dezavantaj care ar putea afecta performanța sa.
IPsec permite alegerea liberă a criptării care se potrivește cel mai bine cazului tău. Și, desigur, este necesar dacă, de exemplu, dorești să transferi 10 sau mai multe gigaocteți de date printr-o conexiune VPN.
Probleme de integrare în Linux
Deși WireGuard a ales un protocol de criptare modern, acest lucru deja cauza o mulțime de probleme. Iar în loc să folosească ceea ce este suportat nativ de kernel, integrarea WireGuard a fost amânată ani de zile din cauza lipsei acestor primitive în Linux.
Nu sunt pe deplin la curent cu situația în celelalte sisteme de operare, dar probabil că nu este foarte diferită de situația de pe Linux.
Cum arată realitatea?
Din păcate, de fiecare dată când un client mă întreabă să-i configurez o conexiune VPN, mă confrunt cu faptul că folosește date de autentificare și criptare învechite. 3DES împreună cu MD5 — este încă o practică comună, la fel ca AES-256 și SHA1. Și deși ultimul este puțin mai bun — aceasta nu este o alegere pe care ar trebui să o faci în 2020.
Pentru schimbul de chei întotdeauna se folosește RSA — un instrument lent, dar suficient de sigur.
Clienții mei colaborează cu autoritățile vamale și alte organizații guvernamentale, precum și cu corporații mari, al căror nume este cunoscut în întreaga lume. Toți utilizează un formular de cerere care a fost creat cu decenii în urmă, iar posibilitatea de a folosi SHA-512 pur și simplu nu a fost niciodată adăugată. Nu pot spune că acest lucru afectează în mod evident progresul tehnologic, dar este evident că încetinește procesele corporative.
Îmi pare rău să văd asta, deoarece IPsec suportă curbe eliptice de la anii 2005. Curve25519 este de asemenea mai nou și disponibil pentru utilizare. Există și alternative la AES, cum ar fi Camellia și ChaCha20, dar evident, nu toate sunt suportate de marii furnizori, precum Cisco și alții.
Și oamenii le folosesc. Există multe seturi Cisco, există o mulțime de kituri create pentru a funcționa cu Cisco. Aceștia sunt liderii pieței în acest segment și nu sunt foarte interesați de inovații.
Da, situația [în segmentul corporativ] este groaznică, dar nu vom vedea nicio schimbare din cauza WireGuard. Producătorii probabil că nu vor identifica niciodată probleme de performanță cu instrumentele și criptarea deja utilizate, nu vor observa probleme în utilizarea IKEv2 - și din acest motiv, nu caută alternative.
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 de la dezvoltatori la o abordare mai științifică sau la utilizarea unei metode științifice ca etalon. Orice benchmark este inutil dacă nu poate fi reprodus, și devine și mai inutil când este obținut în condiții de laborator.
În versiunea WireGuard pentru Linux, beneficiază de avantajul utilizării GSO – Generic Segmentation Offloading. Datorită acestuia, clientul creează un pachet uriaș de 64 de kilobyte și îl criptează/decriptează într-o singură trecere. Astfel, costurile apelului și implementarea operațiunilor criptografice sunt reduse. Dacă doriți să maximizați lățimea de bandă a conexiunii VPN, aceasta este o idee bună.
Dar, așa cum se întâmplă de obicei, în realitate, lucrurile nu sunt atât de simple. Trimiterea unui pachet atât de mare la adaptoarele de rețea necesită ca acesta să fie tăiat în multe pachete mai mici. Dimensiunea obișnuită a unui pachet este de 1500 de biți. Așadar, gigantul nostru de 64 de kilobiți va fi împărțit în 45 de pachete (1240 de biți de informație și 20 de biți pentru capul IP). Apoi, pentru o vreme, acestea vor bloca complet funcționarea adaptoarelor de rețea, deoarece trebuie trimise împreună și simultan. În cele din urmă, acest lucru va duce la o creștere a priorității, iar pachetele precum VoIP vor fi plasate în așteptare.
Astfel, lățimea de bandă mare, despre care WireGuard afirmă atât de îndrăzneț, este obținută prin încetinirea funcționării rețelei altor aplicații. Și echipa WireGuard deja a confirmat acesta este concluzia mea.
Dar haideți să mergem mai departe.
Conform benchmark-urilor din documentația tehnică, conexiunea arată o lățime de bandă de 1011 Mbit/s.
Impresionant.
Acest lucru este deosebit de impresionant având în vedere că lățimea de bandă teoretică maximă a unei conexiuni Ethernet de un gigabit este de 966 Mbit/s cu un pachet de 1500 de biți minus 20 de biți pentru capul IP, 8 biți pentru capul UDP și 16 biți pentru capul WireGuard. Există încă un cap IP în pachetul încapsulat și încă un alt cap TCP de 20 de biți. Așadar, de unde provine această lățime de bandă suplimentară?
Cu cadre mari și avantajele GSO despre care am vorbit mai sus, maximul teoretic cu dimensiunea cadrelor de 9000 de biți va fi de 1014 Mbit/s. În general, o astfel de lățime de bandă nu este realizabilă în realitate, deoarece este asociată cu mari dificultăți. Așadar, pot doar să presupun că testul a fost efectuat folosind cadre și mai mari cu o dimensiune depășită de 64 de kilobiți și un maxim teoretic de 1023 Mbit/s, susținut doar de anumite adaptoare de rețea. Dar aceasta este complet inaplicabilă în condiții reale sau poate fi utilizată doar între două stații conectate direct între ele, exclusiv în cadrul unui banc de testare.
Însă, deoarece tunelul VPN este realizat între două gazde printr-o conexiune de internet care, în general, nu suportă cadre mari, rezultatul obținut în laborator nu poate fi considerat un standard. Este pur și simplu o realizare experimentală nerealistă, imposibil de aplicat în condiții reale de luptă.
Chiar și fiind în centrul de date, nu aș putea transfera cadre mai mari de 9000 de octeți.
Criteriul aplicabilității în viața reală este complet încălcat și, după părerea mea, autorul „măsurătorii” realizate s-a discreditat serios din motive evidente.
Ultima rază de speranță
Pe site-ul WireGuard se discută mult despre containere, iar scopul său devine clar.
Un VPN simplu și rapid, care nu necesită configurare și poate fi desfășurat și configurat prin instrumente masive de orchestrare, precum cele de la Amazon în cloud-ul lor. În mod special, Amazon folosește cele mai noi funcții hardware despre care am menționat anterior, cum ar fi AVX512. Acest lucru se face pentru a accelera performanța și a nu fi limitat la x86 sau orice altă arhitectură.
Ei optimizează lățimea de bandă și pachetele, al căror dimensiune depășește 9000 de octeți — ceea ce rezultă în cadre enorme încapsulate pentru comunicarea între containere, sau pentru operațiuni de backup, crearea de snapshot-uri sau desfășurarea acestor containere. Chiar și adresele IP dinamice nu vor afecta funcționarea WireGuard în scenariul descris de mine.
Bine jucat. O implementare strălucită și un protocol foarte fin, aproape ideal.
Dar nu se potrivește cu adevărat cu lumea dincolo de centrul de date complet controlat de tine. Dacă îți asumi riscul și începi să folosești WireGuard, va trebui să faci compromisuri constante în dezvoltarea și implementarea protocolului de criptare.
Ieșire
Nu îmi este greu să concluzionez că WireGuard nu este pregătit încă.
Acesta a fost gândit ca o soluție ușoară și rapidă pentru o serie de probleme ale soluțiilor existente. Din păcate, în numele acestor soluții, a sacrificat multe funcții care ar 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 setări pentru adresa IP și configurația de rutare și DNS. Este evident că pentru aceasta sunt necesare canale criptate.
Securitatea este prioritatea mea principală, și în prezent nu am motive să cred că IKE sau TLS sunt compromise sau defecte. Criptarea modernă este susținută în ambele protocoale și au fost verificate de zeci de ani de exploatare. Ceva mai nou nu înseamnă automat că este mai bun.
Compatibilitatea funcțională este extrem de importantă atunci când interacționezi cu terțe părți ale căror stații nu le controlezi. IPsec este în mod de facto standardul și este susținut aproape peste tot. Și funcționează. Și, deși poate părea teoretic, WireGuard ar putea fi, în viitor, incompatibil chiar și cu diferite versiuni ale propriei sale actualizări.
Orice protecție criptografică va fi, mai devreme sau mai târziu, spartă și, prin urmare, trebuie înlocuită sau actualizată.
Negarea tuturor acestor fapte și dorința oarbă de a utiliza WireGuard pentru a conecta iPhone-ul tău la stația de lucru de acasă este pur și simplu un masterclass în a-ți băga capul în nisip.
Sursa: habr.com
