Miks ei tasu kasutada WireGuardi

Viimasel ajal on WireGuard saanud suurt tähelepanu, see on tegelikult uus "täht" VPN. Kuid kas see on tõepoolest nii hea, nagu tundub? Tahaksin arutada mõningaid tähelepanekuid ja uurida WireGuardi rakendust, et rääkida, miks see ei ole lahendus, mis asendaks IPsec'i või OpenVPN'i.

Selles artiklis soovin ma ümber lükata mõned müüdid [WireGuardi] kohta. Jah, lugemist on palju, nii et kui te pole veel endale tassikest teed või kohvi keetnud, siis nüüd on selleks hea aeg. Samuti tahaksin tänada Peterit minu segaste mõtete korrektuuri eest.

Ma ei püüa diskrediteerida WireGuardi arendajaid, alandada nende pingutusi või ideid. Nende toode on töökindel, kuid minu isiklik arvamus on, et see esitatakse täiesti valel moel — esitatakse kui IPsec'i ja OpenVPN'i asendust, mida tegelikult hetkel ei eksisteeri.

Märkuseks tahan lisada, et WireGuardi sellise positsioneerimise eest vastutavad meedia, kes sellest rääkis, mitte projekt ise või selle loojad.

Viimasel ajal ei ole Linuxi tuuma kohta olnud palju häid uudiseid. Meile on räägitud kohutavatest protsessorite haavatavustest, mis on tarkvaraliselt kõrvaldatud, ja Linus Torvalds rääkis sellest liiga karmilt ja igavalt, arendaja utilitaarses keeles. Plaanija või nulltaseme võrkude virn — need pole samuti liiga arusaadavad teemad läikivates ajakirjades. Ja siis ilmub WireGuard.

Paberil kõlab kõik suurepäraselt: fantaasiatäratavad uued tehnoloogiad.

Aga vaatame seda veidi lähemalt.

WireGuardi tehniline dokumentatsioon

See artikkel põhineb WireGuardi ametlikul dokumentatsioonil, mille kirjutas Jason Donenfeld. Seal seletab ta kontseptsiooni, eesmärke ja tehnilist rakendust [WireGuard] Linuxi tuumas.

Esimene lause ütleb:

WireGuard […] püüab asendada IPsec'i enamikes selle kasutusjuhtumites, samuti teisi populaarseid kasutusruumi ja / või TLS-põhiseid lahendusi, nagu OpenVPN, olles samal ajal turvalisem, tõhusam ja kergemini kasutatav [vahend].

Muidugi on kõikide uute tehnoloogiate peamine eelis nende lihtsus [võrreldes eelkäijatega]. Kuid VPN peab olema samuti efektiivne ja turvaline.

Ja mis siis edasi?

Kui ütlete, et teil [VPN-ist] ei ole seda vaja, siis võib selle lugemise lõpetada. Siiski tahan märkida, et sellised ülesanded on seotud iga teise tunnelitehnoloogiaga.

Kõige huvitavam ülaltoodud tsitaadis peitub sõnades „enamasti“, mis ajakirjanduses ilmselgelt tähelepanuta jäeti. Nii et me oleme seal, kus oleme, selle hooletuse tekitatud kaose tõttu — selles artiklis.

Kas WireGuard on asenduseks minu [IPsec] VPN-ühendusele kahe saidi vahel?

Ei. Siin pole lihtsalt võimalust, et suured tarnijad, nagu Cisco, Juniper ja teised, võtavad oma toodetesse WireGuardi. Nad ei „hüppa mööduvatesse rongidesse“ kui selleks pole mingit suurt vajadust. Hiljem räägin mõningatest põhjustest, miks nad ilmselt ei saa WireGuardi oma toodetesse integreerida, isegi kui nad tahaksid.

Kas WireGuard viib mu RoadWarrior sülearvutist andmekeskusesse?

Ei. Praegu ei ole WireGuardis ellu viidud tohutul hulgal olulisi funktsioone, et see saaks midagi sellist teha. Näiteks ei saa ta kasutada dünaamilisi IP-aadresse tunneliserveri küljel, ja juba sellest piisab, et tervikuni ei sobi.

IPFire'd kasutatakse sageli odavate internetiühenduste puhul, nagu DSL või kaabliühendus. See on mõistlik väikese või keskmise ettevõtte jaoks, kellel ei ole vaja kiiret kiudoptilist ühendust. [Tõlkijalt: ärge unustage, et suhtluse osas on Venemaa ja mõned endised NSVL riigid Euroopast ja USA-st palju ees, kuna me hakkasime oma võrgud ehitama palju hiljem ja koos Etherneti ja kiudoptiliste võrkudega standardina, oli meil lihtsam ümber korraldada. Samades Euroopa või USA riikides on xDSL lairibajuurdepääs kiirusel 3-5 Mbit/s — endiselt üldine norm, samas kui kiudoptiline ühendus maksab meie omadest uskumatult palju. Seetõttu räägib artikli autor DSL- või kaabliühendusest normina, mitte vanana. Kuid DSL, kaabli-, LTE (ja muud traadita juurdepääsu meetodid) omavad dünaamilisi IP-aadresse. Loomulikult muutuvad nad harva, kuid siiski muutuvad.

On olemas alaprojekt nimega «wg-dynamic», mis lisab kasutajateiru, et selle puuduse ületamiseks. Suur probleem ülaltoodud kasutusloost on dünaamilise IPv6-aadressimise süvenemine.

Jaotaja vaatenurgast pole see ka just väga hea. Üks arenduse eesmärke oli säilitada protokolli lihtsus ja puhtus.

Kahjuks on kõik tegelikult muutunud liiga lihtsaks ja primitiivseks, nii et me peame kasutama täiendavat tarkvara, et kogu see konstruktsioon oleks reaalsetes tingimustes kasutatav.

Kas WireGuard on tõesti nii lihtne kasutada?

Hetkel mitte. Ma ei ütle, et WireGuard ei saaks kunagi olema hea alternatiiv kahe punkti vahelise tunnelite loomise jaoks, aga praegu on see lihtsalt toote alfa-versioon.

Aga mis siis tegelikult toimub? Kas IPsec on tõesti keerulisem kasutada?

Ilmselgelt mitte. IPsec-teenuse pakkuja on selle asja läbi mõelnud ja pakub oma toodet koos kasutajaliidesega, näiteks IPFire.

IPsec kaudu VPN-tunneli seadistamiseks on vajalik viis andmekogumit, mis tuleb konfiguratsiooni sisestada: teie enda avalik IP-aadress, vastuvõtva poole avalik IP-aadress, alamsed, mida soovite selle VPN-ühenduse kaudu avalikustada, ja eelkonto võti. Nii et VPN seadistamine toimub mõne minutiga ja see on ühilduv igasuguste tarnijatega.

Kahjuks on selles loos mõned erandid. Igaüks, kes on proovinud luua VPN-tunnelit IPsec kaudu OpenBSD masinasse, mõistab, millest ma räägin. On veel paar valusat näidet, kuid tõeliselt positiivset IPsec-i kasutamise praktikat on palju rohkem.

Protokolli keerukusest

Lõppkasutaja ei peaks protokolli keerukuse pärast muretsema.

Kui me elaksime maailmas, kus see oleks kasutaja jaoks tõeline mure, oleksime juba ammu vabanenud SIP-st, H.323-st, FTP-st ja muudest rohkem kui kümme aastat tagasi loodud protokollidest, mis halvasti toimivad NAT-iga.

On põhjuseid, miks IPsec on keerulisem kui WireGuard: see teeb palju rohkem asju. Näiteks kasutaja autentimine sisselogimise/parooli või SIM-kaardi kaudu EAP abil. Tal on laiendatud võimalus uute krüptograafiliste primitivi lisamiseks.

Aga WireGuardil ei ole seda.

See tähendab, et WireGuard võib mingil hetkel katki minna, kuna üks krüptograafiline primitiiv nõrgeneb või on täielikult kompromiteeritud. Tehnilise dokumentatsiooni autor ütleb selle kohta nii:

Oluline on märkida, et WireGuard on krüptograafiliselt isekindel. Tal puudub teadlikult šifrite ja protokollide paindlikkus. Kui aluspõhised primitiivid avastatakse tõsised vead, tuleb kõik lõpp-punktid uuendada. Nagu näha on, on SLL/TLS pideva haavatavuste voog suurendanud šifrimise paindlikkust tohutult.

Viimane lause on täiesti õige.

Konsensuse saavutamine selle üle, millist šifrit kasutada, muudab IKE ja TLS tüüpi protokollid üle keeruliseks. Liialt keeruliseks? Jah, TLS/SSL puhul esinevad haavatavused piisavalt sageli ja nendele ei ole alternatiive.

Tegelikest probleemidest kõrvalehoidmine

Kujutage ette, et teil on VPN-server 200 aktiivse kliendiga, kuskil üle maailma. See on täiesti tavaline kasutusstsenaarium. Kui peate šifrit vahetama, peate värskendama kõik WireGuardi kopeerid nende sülearvutites, nutitelefonides jne. Samas kasuks toimetamine. See on sõna otseses mõttes võimatu. Administraatorid, kes proovivad seda teha, vajavad kuude kaupa, et rakendada vajalikke konfiguratsioone, ja keskmistele ettevõtetele võib selle korraldamine võtta aastaid.

IPsec ja OpenVPN pakuvad krüptode kokkuleppimise funktsiooni. Seetõttu pärast seda, kui olete uue šifri sisse lülitanud, töötab ka vana veel mõnda aega. Tänu sellele saavad praegused kliendid uuendada uuele versioonile. Kui värskendus on rakendatud, lülitate lihtsalt viidatud šifri välja. Ja kõik! Olete valmis! Ja kliendid ei märkagi seda isegi.

Tegelikkuses on see väga levinud juhtum suurte rakenduste jaoks ja isegi OpenVPN kogeb selles mõningaid raskusi. Tagasiühilduvus on oluline, ja kuigi te kasutate nõrgemat šifrit, ei tähenda see paljude jaoks äritegevuse lõpetamist. Kuna see põhjustab sadade klientide töö seiskumise, kuna nad ei suuda oma tööd teha.

WireGuardi meeskond on muutnud oma protokolli lihtsamaks, kuid täiesti sobimatuks inimestele, kellel pole pidevat kontrolli oma tunnelite kahte äärt üle. Minu kogemuse järgi on selline stsenaarium kõige levinum.

Krüptograafia!

Aga mis see huvitav uus krüptimine on, mida WireGuard kasutab?

WireGuard kasutab võtmevahetuseks Curve25519, krüpteerimiseks ChaCha20 ja andmete autentimiseks Poly1305. Samuti kasutab see häkkide võtmete jaoks SipHash'i ja räsimiseks BLAKE2.

ChaCha20-Poly1305 on standardiseeritud IPsec'i ja OpenVPN'i jaoks (TLS-i kaudu).

On ilmne, et Daniel Bernstein'i väljatöötatud lahendust kasutatakse väga sageli. BLAKE2 on BLAKE'i järgija, mis oli SHA-3 finaalis, kuid ei võitnud oma sarnasuse tõttu SHA-2-ga. Kui SHA-2 oleks häkitud, oleks suur tõenäosus, et ka BLAKE kompromittitakse.

IPsec ja OpenVPN ei vaja SipHash'i oma disaini tõttu. Seega on ainus asi, mida praegu ei saa kasutada, BLAKE2, ja isegi see vaid seni, kuni see ei ole standardiseeritud. See pole suur puudus, sest VPN-id kasutavad HMAC-i, et tagada integriteet, mis peetakse isegi MD5-ga kasutamisel tugevaks lahenduseks.

Nii olen ma jõudnud järeldusele, et peaaegu kõikides VPN-ides kasutatakse praktiliselt sama krüptograafiliste tööriistade kogumit. Seetõttu ei ole WireGuard ei enam ega vähem turvaline kui kõik teised asjakohased tooted, kui tegemist on edastatavate andmete krüptimise või integriteediga.

Kuid isegi mitte see ei ole peamine, millele tasub tähelepanu juhtida vastavalt projekti ametlikule dokumentatsioonile. Peamine on kiirus.

Kas WireGuard on kiirem kui muud VPN lahendused?

Lühidalt: ei, ta ei ole kiirem.

ChaCha20 on voogkrüptimine, mida on kergem tarkvarasse rakendada. See krüpteerib ühte bitti korraga. Plokkrakendused, nagu AES, krüpteerivad 128 bitti korraga. Riistvaratoe rakendamiseks on vajalik palju rohkem transistorite, seetõttu varustatakse suuremad protsessorid AES-NI - käsukomplekti laiendiga, mis täidab mõningaid krüptimise ülesandeid selle kiirendamiseks.

Ootasin, et AES-NI ei jõua kunagi nutitelefonidesse [aga see jõudis, — toimetaja märkus]. Selleks töötati välja ChaCha20 — kerge ja energiasäästlik alternatiiv, mis on sõbralikum akule. Seetõttu võib teid üllatada, et iga nutitelefon, mille te täna osta saate, sisaldab mingisugust AES-i kiirendust ja töötab selle krüptimisega kiiremini ning väiksema energiatarbimisega kui ChaCha20.

Ilmselt on praktiliselt igas lauaarvuti / serveri protsessoris, mis on viimasel paaril aastal ostetud, olemas AES-NI.

Seega ootan, et AES ületab ChaCha20 igas eraldi stsenaariumis. WireGuardi ametlikus dokumentatsioonis mainitakse, et AVX512 tõttu ületab ChaCha20-Poly1305 AES-NI-d, kuid see käskluste komplekt on saadaval ainult suurtes protsessorites, mis ei aita väiksemaid ja mobiilseid seadmeid, mis töötavad alati kiiremini AES-NI-ga.

Ma ei ole kindel, kas seda oleks olnud võimalik prognoosida WireGuardi väljatöötamisel, kuid täna on tõsiasi, et see on naelutatud ühte krüptimise vormi — see on juba puudus, mis ei pruugi selle toimimist hästi mõjutada.

IPsec võimaldab vabalt valida, milline krüptimine sobib teie vajadustele kõige paremini. Ja muidugi on see vajalik, kui soovite näiteks edastada 10 ja enam gigabaiti andmeid VPN-ühenduse kaudu.

Probleemid Linuxi integreerimisel

Kuigi WireGuard valis kaasaegse krüptimisprotokolli, tekitab see juba hulga probleeme. Ja nüüd, selle asemel, et kasutada seda, mis on Linuxi tuumaga vaikimisi toetatud, on WireGuardi integreerimist edasi lükatud aastaid, kuna neid primitiive ei olnud Linuxis.

Ma ei ole täiesti kindel, milline on seis teiste operatsioonisüsteemide puhul, kuid tõenäoliselt ei erine see olukord Linuxist kuigi palju.

Milline on reaalsus?

Kahjuks, iga kord, kui klient palub mul seadistada VPN-ühenduse, puutun kokku sellega, et nad kasutavad aegunud autentimisandmeid ja krüptimist. 3DES koos MD5-ga on endiselt levinud praktika, samuti AES-256 ja SHA1. Ja kuigi viimane on veidi parem — see ei ole see, millega peaks 2020. aastal töötama.

Võtmete vahetamiseks alati kasutatakse RSA-d — aeglane, kuid piisavalt turvaline tööriist.

Minu kliendid tegelevad tolli organitega ja teiste riigiasutuste ning asutustega, samuti suurte ettevõtetega, mille nimesid tuntakse üle kogu maailma. Kõik nad kasutavad taotlemisvormi, mis loodi kümneid aastaid tagasi, ning SHA-512 kasutamise võimalust pole kunagi lisatud. Ma ei saa öelda, et see mõjutab kuidagi tehnoloogilist arengut, kuid see aeglustab kindlasti ettevõtte protsesse.

On valus sellele vaadata, sest IPsec toetab elliptilisi kõveraid umbes alates 2005. aastast. Curve25519 on samuti uuem ja kasutamiseks saadaval. Samuti on alternatiive AES-ile, nagu Camellia ja ChaCha20, kuid ilmselgelt ei toeta kõik neist suured tarnijad, nagu Cisco ja teised.

Ja inimesed kasutavad seda. On palju Cisco komplekte, on palju komplekte, mis on loodud töötama koos Cisco-ga. Nad on turuliidrid selles segmendis ega ole eriti huvitatud innovatsioonidest.

Jah, [korporatiivse segmendi] olukord on kohutav, kuid me ei näe WireGuard'i tõttu mingeid muudatusi. Tootjad tõenäoliselt kunagi ei tuvastanud juba kasutatava tööriistade ja krüptimisega seotud jõudlusprobleeme, ei näe probleeme IKEv2 kasutamisel — ja seetõttu nad ei otsi alternatiive.

Kas olete kunagi mõelnud Cisco-st loobumisele?

Benkmarkid

Ja nüüd liigume WireGuard dokumentatsioonist pärinevate benchmarkide juurde. Kuigi see [dokumentatsioon] ei ole teadusartikel, ootasime siiski arendajatelt teaduslikumat lähenemist või teadusliku lähenemise kasutamist etalonina. Iga benchamrk on kasututu, kui seda ei saa taasesitada, ning veelgi enam on nad kasutud, kui need on saadud laboritingimustes.

WireGuard'i Linuxi versioonis saavutab see eelist, kasutades GSO-d — Generic Segmentation Offloading. Selle abil loob klient tohutu 64 kilobaiti suuruse paketi ja krüpteerib/dekrypteerib selle ühe korra. Seega väheneb krüptograafiliste operatsioonide kutsumise ja teostamise kulu. Kui soovite maksimeerida oma VPN-ühenduse läbilaskevõimet — on see hea mõte.

Kuid nagu ikka, tegelikkus pole kaugeltki nii lihtne. Suure paketi saatmine võrgukaardile nõuab, et see jagataks paljuski väiksemateks pakkideks. Tavaline saatmismaht on 1500 baiti. See tähendab, et meie 64 kilobaiti suur hiiglane jagatakse 45 pakkideks (1240 baiti teavet ja 20 baiti IP-pealkirja). Siis blokeerivad nad mõneks ajaks täielikult võrguadapteri töö, kuna nad peavad olema saadetud koos ja üheaegselt. See toob lõpuks kaasa prioriteedi tõusu, ja sellised paketid nagu VoIP pannakse ootejärjekorda.

Nii et WireGuardi poolt nii julgelt kuulutatud kõrge läbilaskevõime saavutatakse teiste rakenduste võrgu töö aeglustamise kaudu. Ja WireGuardi meeskond on juba kinnitanud minu järeldus.

Aga liigume edasi.

Tehnilise dokumentatsiooni testide kohaselt näitab ühendus läbilaskevõimet 1011 Mbit/s.

Muljetavaldav.

See on eriti muljetavaldav, arvestades, et ühe gigabitise Ethernet-ühenduse maksimaalne teoreetiline läbilaskevõime on 966 Mbit/s, kui paketi suurus on 1500 baiti minus 20 baiti IP-pealkirjale, 8 baiti UDP-pealkirjale ja 16 baiti WireGuardi enda pealkirjale. On veel üks IP-pealkiri kapseldatud paketis ja veel üks 20 baiti TCP pealkirja jaoks. Kust see lisaläbilaskevõime siis tuli?

Suurte raamide ja GSO eelistega, millest oleme eespool rääkinud, on teoreetiline maksimum 9000 baiti raami puhul 1014 Mbit/s. Tavaline läbilaskevõime on reaalsuses tavaliselt saavutatav, kuna see on seotud suurte raskustega. Seega võin vaid oletada, et katse viidi läbi veelgi suuremate raamidega, ületades 64 kilobaiti suuruse teoreetilise maksimumiga 1023 Mbit/s, mida toetavad ainult mõned võrgukaardid. Kuid see ei ole absoluutselt rakendatav reaalses elus, vaid võib olla ainult kahe otse ühendatud jaamaga, ainult testimise raames.

Kuna VPN-tunnel edastatakse kahe hosti vahel internetiühenduse kaudu, mis ei toeta suuri raame, ei saa saavutatud tulemust võtta mõõdupuudena. See on lihtsalt ebareaalne laboratoorne saavutus, mis pole rakendatav reaalses lahinguolukorras.

Käivitusandmesalves istudes ei saaks ma edastada raame, mille suurus ületab 9000 baiti.

Tegeliku kasutuse korralduse kriteerium on absoluutselt rikutud ja ma arvan, et autor, kes tegi selle 'mõõtmise', diskrediteeris end selgelt arusaamatutel põhjustel.

Viimane lootusekiir.

WireGuardi saidil räägitakse palju konteineritest, ja on selge, mille jaoks ta tegelikult on mõeldud.

Lihtne ja kiire VPN, mis ei vaja seadistamist ning saab olla juurutatud ja konfigureeritud massiliste orkestreerimistööriistadega, nagu Amazon oma pilves. Konkreetsemalt kasutab Amazon uusimaid riistvarafunktsioone, millest ma varem mainisin, näiteks AVX512. Seda tehakse töö kiirendamiseks ja mitte kinni pidamiseks x86 või mõnest muust arhitektuurist.

Nad optimeerivad ribalaiust ja pakette, mille suurus ületab 9000 baiti — need on tohutud kapseldatud raamidevahelised suheldes konteineritega või varukoopiate tegemiseks, snapshotide loomiseks või nende samade konteinerite juurutamiseks. Isegi dünaamilised IP-aadressid ei mõjuta WireGuardi tööd mulle kirjeldatud stsenaariumi korral.

Mitte paha mängitud. Silmapaistev teostus ja väga õhuke, peaaegu ideaalne protokoll.

Kuid see ei sobi lihtsalt maailmasse, mis on väljaspool täielikult teie kontrolli all olevat andmekeskust. Kui riskite ja hakkate WireGuardi kasutama, peate pidevalt kompromisse tegema krüpteerimisprotokolli arendamisel ja rakendamisel.

Kokkuvõte

Ei ole raske järeldada, et WireGuard ei ole veel valmis.

See oli mõeldud kergema ja kiire lahendusena mitme probleemiga olemasolevates lahendustes. Kahjuks on ta nende lahenduste nimel ohverdanud mitmeid funktsioone, mis on enamikule kasutajatest olulised. Seetõttu ei saa ta asendada IPsec-i või OpenVPN-i.

Ette WireGuard oleks konkurentsivõimeline, peab see lisama vähemalt IP-aadressi seadistuse ja marsruutimise ning DNS-i konfiguratsiooni. Ilmselgelt on just selleks vajalikud krüpteeritud kanalid.

Turvalisus on minu peamine prioriteet ja praegu ei ole mul põhjust arvata, et IKE või TLS oleks mingil kombel kompromiteeritud või katki. Kaasaegne krüpteerimine on mõlemas olemas ja neid on testitud aastakümnete jooksul. See, et midagi on uuem, ei tähenda, et see on parem.

Funktsionaalne ühilduvus on äärmiselt oluline, kui ühendate kolmandate osapooltega, kelle jaamad ei ole teie kontrolli all. IPsec on de facto standard ja seda toetatakse praktiliselt igal pool. Ja see töötab. Kuigi teoorias võib WireGuard tulevikus olla isegi ühilduv erinevate oma versioonidega.

Iga krüptograafiline kaitse murrab varem või hiljem ja seega peab see olema asendatud või uuendatud.

Nende faktide eitamine ja pime soov kasutada WireGuard'i oma iPhone'i ühendamiseks koduse tööjaamaga on lihtsalt meistriteos pea liiva alla peitmisel.

Allikas: habr.com