WireGuard het die afgelope tyd baie aandag gekry, in werklikheid is dit die nuwe ster onder VPN’s. Maar is hy so goed soos hy lyk? Ek wil graag 'n paar waarnemings bespreek en die implementering van WireGuard hersien om te verduidelik hoekom dit nie 'n oplossing is om IPsec of OpenVPN te vervang nie.
In hierdie artikel wil ek sommige van die mites [rondom WireGuard] ontken. Ja, dit sal lank neem om te lees, so as jy nie vir jou 'n koppie tee of koffie gemaak het nie, dan is dit tyd om dit te doen. Ek wil ook vir Peter dankie sê vir die regstelling van my chaotiese gedagtes.
Ek stel nie vir myself die doel om die ontwikkelaars van WireGuard te diskrediteer, hul pogings of idees te devalueer nie. Hul produk werk, maar persoonlik dink ek dat dit heeltemal anders aangebied word as wat dit werklik is - dit word aangebied as 'n plaasvervanger vir IPsec en OpenVPN, wat in werklikheid eenvoudig nie nou bestaan nie.
As 'n nota wil ek byvoeg dat die verantwoordelikheid vir so 'n posisionering van WireGuard by die media lê wat daaroor gepraat het, en nie die projek self of sy skeppers nie.
Daar was die afgelope tyd nie veel goeie nuus oor die Linux-kern nie. So, ons is vertel van die monsteragtige kwesbaarhede van die verwerker, wat deur sagteware gelykgemaak is, en Linus Torvalds het te onbeskof en vervelig daaroor gepraat in die utilitaristiese taal van die ontwikkelaar. 'n Skeduleerder of 'n nulvlak-netwerkstapel is ook nie baie duidelike onderwerpe vir glanstydskrifte nie. En hier kom WireGuard.
Op papier klink dit alles wonderlik: 'n opwindende nuwe tegnologie.
Maar kom ons kyk bietjie nader daarna.
WireGuard wit papier
Hierdie artikel is gebaseer op geskryf deur Jason Donenfeld. Daar verduidelik hy die konsep, doel en tegniese implementering van [WireGuard] in die Linux-kern.
Die eerste sin lui:
WireGuard […] poog om beide IPsec in die meeste gebruiksgevalle en ander gewilde gebruikersruimte en/of TLS-gebaseerde oplossings soos OpenVPN te vervang, terwyl dit veiliger, doeltreffender en makliker is om te gebruik [hulpmiddel].
Natuurlik, die grootste voordeel van alle nuwe tegnologie is hul eenvoud [in vergelyking met voorgangers]. Maar 'n VPN moet ook wees doeltreffend en veilig.
So, wat is volgende?
As jy sê dat dit nie is wat jy nodig het nie [van 'n VPN], dan kan jy die lees hier beëindig. Ek sal egter daarop let dat sulke take vir enige ander tonneltegnologie gestel word.
Die interessantste van bogenoemde aanhaling lê in die woorde "in die meeste gevalle", wat natuurlik deur die pers geïgnoreer is. En so, ons is waar ons beland het weens die chaos wat deur hierdie nalatigheid geskep is – in hierdie artikel.
Sal WireGuard my [IPsec] werf-tot-werf VPN vervang?
Geen. Daar is eenvoudig geen kans dat groot verskaffers soos Cisco, Juniper en ander WireGuard vir hul produkte sal koop nie. Hulle "spring nie op verbygaande treine" terwyl hulle beweeg, tensy daar 'n groot behoefte is om dit te doen. Ek sal later oor sommige van die redes gaan waarom hulle waarskynlik nie hul WireGuard-produkte aan boord sal kan kry nie, al wou hulle.
Sal WireGuard my RoadWarrior van my skootrekenaar na die datasentrum neem?
Geen. Op die oomblik het WireGuard nie 'n groot aantal belangrike kenmerke wat geïmplementeer is sodat dit so iets kan doen nie. Dit kan byvoorbeeld nie dinamiese IP-adresse aan die tonnelbedienerkant gebruik nie, en dit alleen breek die hele scenario van sodanige gebruik van die produk.
IPFire word dikwels gebruik vir goedkoop internetverbindings, soos DSL- of kabelverbindings. Dit maak sin vir klein of medium ondernemings wat nie vinnige vesel nodig het nie. [Nota van die vertaler: moenie vergeet dat Rusland en sommige GOS-lande wat kommunikasie betref, ver voor Europa en die Verenigde State is nie, want ons het heelwat later begin bou aan ons netwerke en met die koms van Ethernet en optieseveselnetwerke as 'n standaard was dit vir ons makliker om te herbou. In dieselfde lande van die EU of die VSA is xDSL-breëbandtoegang teen 'n spoed van 3-5 Mbps steeds die algemene norm, en 'n optieseveselverbinding kos 'n bietjie onrealistiese geld volgens ons standaarde. Daarom praat die skrywer van die artikel van DSL of kabelverbinding as die norm, en nie antieke tye nie.] DSL, kabel, LTE (en ander draadlose toegangsmetodes) het egter dinamiese IP-adresse. Natuurlik verander hulle soms nie gereeld nie, maar hulle verander wel.
Daar is 'n subprojek genaamd , wat 'n gebruikersruimte-demoon byvoeg om hierdie tekortkoming te oorkom. 'n Groot probleem met die gebruikersscenario wat hierbo beskryf word, is die verergering van dinamiese IPv6-adressering.
Uit die oogpunt van die verspreider lyk dit alles ook nie baie goed nie. Een van die ontwerpdoelwitte was om die protokol eenvoudig en skoon te hou.
Ongelukkig het dit alles eintlik te eenvoudig en primitief geword, sodat ons addisionele sagteware moet gebruik sodat hierdie hele ontwerp in werklike gebruik lewensvatbaar kan wees.
Is WireGuard so maklik om te gebruik?
Nog nie. Ek sê nie dat WireGuard nooit 'n goeie alternatief sal wees om tussen twee punte te tonnel nie, maar vir nou is dit net 'n alfa-weergawe van die produk wat dit veronderstel is om te wees.
Maar wat doen hy dan eintlik? Is IPsec regtig soveel moeiliker om te onderhou?
Duidelik nie. Die IPsec-verskaffer het hieraan gedink en stuur hul produk saam met 'n koppelvlak, soos met IPFire.
Om 'n VPN-tonnel oor IPsec op te stel, sal jy vyf stelle data nodig hê wat jy in die konfigurasie sal moet invoer: jou eie openbare IP-adres, die publieke IP-adres van die ontvangende party, die subnette waardeur jy publiek wil maak hierdie VPN-verbinding en vooraf-gedeelde sleutel. Die VPN word dus binne minute opgestel en is versoenbaar met enige verskaffer.
Ongelukkig is daar 'n paar uitsonderings op hierdie storie. Enigiemand wat probeer het om oor IPsec na 'n OpenBSD-masjien te tonnel, weet waarvan ek praat. Daar is nog 'n paar pynlike voorbeelde, maar in werklikheid is daar baie, baie meer goeie praktyke vir die gebruik van IPsec.
Oor protokol kompleksiteit
Die eindgebruiker hoef nie bekommerd te wees oor die kompleksiteit van die protokol nie.
As ons in 'n wêreld geleef het waar dit 'n werklike bekommernis van die gebruiker was, dan sou ons ontslae geraak het van SIP, H.323, FTP en ander protokolle wat meer as tien jaar gelede geskep is wat nie goed met NAT werk nie.
Daar is redes waarom IPsec meer kompleks is as WireGuard: dit doen baie meer dinge. Byvoorbeeld, gebruikersverifikasie met behulp van 'n aanmelding / wagwoord of 'n SIM-kaart met EAP. Dit het 'n uitgebreide vermoë om nuwe by te voeg .
En WireGuard het dit nie.
En dit beteken dat WireGuard een of ander tyd sal breek, want een van die kriptografiese primitiewe sal verswak of heeltemal gekompromitteer word. Die skrywer van die tegniese dokumentasie sê dit:
Dit is opmerklik dat WireGuard kriptografies eiesinnig is. Dit ontbreek doelbewus die buigsaamheid van syfers en protokolle. As ernstige gate in onderliggende primitiewe gevind word, sal alle eindpunte opgedateer moet word. Soos u kan sien uit die voortdurende stroom van SLL/TLS-kwesbaarhede, het die buigsaamheid van enkripsie nou geweldig toegeneem.
Die laaste sin is absoluut korrek.
Om konsensus te bereik oor watter enkripsie om te gebruik, maak protokolle soos IKE en TLS meer kompleks. Te ingewikkeld? Ja, kwesbaarhede is redelik algemeen in TLS/SSL, en daar is geen alternatief daarvoor nie.
Om werklike probleme te ignoreer
Stel jou voor dat jy 'n VPN-bediener het met 200 gevegskliënte iewers regoor die wêreld. Dit is 'n redelik standaard gebruiksgeval. As jy die enkripsie moet verander, moet jy die opdatering aan alle kopieë van WireGuard op hierdie skootrekenaars, slimfone, ensovoorts lewer. Terselfdertyd lewer. Dit is letterlik onmoontlik. Administrateurs wat dit probeer doen, sal maande neem om die vereiste konfigurasies te ontplooi, en dit sal letterlik 'n mediumgrootte maatskappy jare neem om so 'n gebeurtenis af te handel.
IPsec en OpenVPN bied ‘n syferonderhandelingsfunksie. Daarom, vir 'n geruime tyd waarna jy die nuwe enkripsie aanskakel, sal die ou een ook werk. Dit sal huidige kliënte in staat stel om op te gradeer na die nuwe weergawe. Nadat die opdatering uitgerol is, skakel jy eenvoudig die kwesbare enkripsie af. En dit is dit! Klaar! jy is pragtig! Kliënte sal dit nie eers agterkom nie.
Dit is eintlik 'n baie algemene geval vir groot ontplooiings, en selfs OpenVPN het 'n bietjie probleme hiermee. Terugwaartse verenigbaarheid is belangrik, en al gebruik u swakker enkripsie, is dit vir baie nie 'n rede om 'n besigheid te sluit nie. Want dit sal die werk van honderde kliënte lamlê weens die onvermoë om hul werk te doen.
Die WireGuard-span het hul protokol eenvoudiger gemaak, maar heeltemal onbruikbaar vir mense wat nie konstant beheer oor albei eweknieë in hul tonnel het nie. In my ervaring is dit die mees algemene scenario.
Kriptografie!
Maar wat is hierdie interessante nuwe enkripsie wat WireGuard gebruik?
WireGuard gebruik Curve25519 vir sleuteluitruiling, ChaCha20 vir enkripsie en Poly1305 vir dataverifikasie. Dit werk ook met SipHash vir hash-sleutels en BLAKE2 vir hash.
ChaCha20-Poly1305 is gestandaardiseer vir IPsec en OpenVPN (oor TLS).
Dit is duidelik dat die ontwikkeling van Daniel Bernstein baie gereeld gebruik word. BLAKE2 is die opvolger van BLAKE, 'n SHA-3-finalis wat nie gewen het nie weens sy ooreenkoms met SHA-2. As SHA-2 gebreek sou word, was daar 'n goeie kans dat BLAKE ook gekompromitteer sou word.
IPsec en OpenVPN het nie SipHash nodig nie weens hul ontwerp. So die enigste ding wat tans nie met hulle gebruik kan word nie, is BLAKE2, en dit is net totdat dit gestandaardiseer is. Dit is nie 'n groot nadeel nie, want VPN's gebruik HMAC om integriteit te skep, wat selfs in samewerking met MD5 as 'n sterk oplossing beskou word.
Ek het dus tot die gevolgtrekking gekom dat byna dieselfde stel kriptografiese gereedskap in alle VPN’s gebruik word. Daarom is WireGuard nie meer of minder veilig as enige ander huidige produk wanneer dit kom by enkripsie of die integriteit van versendte data nie.
Maar selfs dit is nie die belangrikste ding wat die moeite werd is om aandag te gee volgens die amptelike dokumentasie van die projek nie. Die belangrikste ding is immers spoed.
Is WireGuard vinniger as ander VPN-oplossings?
Kortom: nee, nie vinniger nie.
ChaCha20 is 'n stroomsyfer wat makliker is om in sagteware te implementeer. Dit enkripteer een bietjie op 'n slag. Blokprotokolle soos AES enkripteer 'n blok 128 bisse op 'n slag. Baie meer transistors word benodig om hardeware-ondersteuning te implementeer, so groter verwerkers kom met AES-NI, 'n instruksiestel-uitbreiding wat sommige van die take van die enkripsieproses uitvoer om dit te bespoedig.
Daar is verwag dat AES-NI nooit in slimfone sou kom nie [maar dit het - ongeveer. per.]. Hiervoor is die ChaCha20 ontwikkel as 'n liggewig, batterybesparende alternatief. Daarom kan dit vir jou as nuus kom dat elke slimfoon wat jy vandag kan koop een of ander AES-versnelling het en vinniger en met laer kragverbruik met hierdie enkripsie werk as met ChaCha20.
Natuurlik het omtrent elke rekenaar-/bedienerverwerker wat die afgelope paar jaar gekoop is, AES-NI.
Daarom verwag ek dat AES in elke scenario beter sal presteer as ChaCha20. WireGuard se amptelike dokumentasie noem dat ChaCha512-Poly20 met AVX1305 beter as AES-NI sal presteer, maar hierdie instruksiestel-uitbreiding sal slegs op groter SVE's beskikbaar wees, wat weereens nie sal help met kleiner en meer mobiele hardeware nie, wat altyd vinniger sal wees met AES - N.I.
Ek is nie seker of dit tydens die ontwikkeling van WireGuard voorsien kon word nie, maar vandag is die feit dat dit alleen aan enkripsie vasgespyker is reeds 'n nadeel wat dalk nie die werking daarvan baie goed beïnvloed nie.
Met IPsec kan u vrylik kies watter enkripsie die beste vir u geval is. En dit is natuurlik nodig as u byvoorbeeld 10 of meer gigagrepe data deur 'n VPN-verbinding wil oordra.
Integrasiekwessies in Linux
Alhoewel WireGuard 'n moderne enkripsieprotokol gekies het, veroorsaak dit reeds baie probleme. En dus, in plaas daarvan om te gebruik wat deur die kern uit die boks ondersteun word, is die integrasie van WireGuard vir jare vertraag weens die gebrek aan hierdie primitiewe in Linux.
Ek is nie heeltemal seker wat die situasie op ander bedryfstelsels is nie, maar dit is waarskynlik nie veel anders as op Linux nie.
Hoe lyk die werklikheid?
Ongelukkig, elke keer as 'n kliënt my vra om 'n VPN-verbinding vir hulle op te stel, kry ek die probleem dat hulle verouderde geloofsbriewe en enkripsie gebruik. 3DES in samewerking met MD5 is steeds algemene praktyk, net soos AES-256 en SHA1. En hoewel laasgenoemde effens beter is, is dit nie iets wat in 2020 gebruik behoort te word nie.
Vir sleutelruil altyd RSA word gebruik - 'n stadige maar redelik veilige hulpmiddel.
My kliënte word geassosieer met doeane-owerhede en ander regeringsorganisasies en -instellings, asook met groot korporasies wie se name oor die hele wêreld bekend is. Hulle gebruik almal 'n versoekvorm wat dekades gelede geskep is, en die vermoë om SHA-512 te gebruik is eenvoudig nooit bygevoeg nie. Ek kan nie sê dat dit op een of ander manier duidelik tegnologiese vooruitgang beïnvloed nie, maar natuurlik vertraag dit die korporatiewe proses.
Dit maak my seer om dit te sien, want IPsec ondersteun al sedert 2005 elliptiese kurwes. Curve25519 is ook nuwer en beskikbaar vir gebruik. Daar is ook alternatiewe vir AES soos Camellia en ChaCha20, maar natuurlik word nie almal deur groot verskaffers soos Cisco en ander ondersteun nie.
En mense trek voordeel daaruit. Daar is baie Cisco-stelle, daar is baie kits wat ontwerp is om met Cisco te werk. Hulle is markleiers in hierdie segment en stel nie baie belang in enige soort innovasie nie.
Ja, die situasie [in die korporatiewe segment] is verskriklik, maar ons sal geen veranderinge sien as gevolg van WireGuard nie. Verkopers sal waarskynlik nooit enige prestasieprobleme sien met die gereedskap en enkripsie wat hulle reeds gebruik nie, sal geen probleme met IKEv2 sien nie, en daarom soek hulle nie alternatiewe nie.
In die algemeen, het jy al ooit daaraan gedink om Cisco te laat vaar?
Maatstawwe
En kom ons gaan nou oor na die maatstawwe uit die WireGuard-dokumentasie. Alhoewel hierdie [dokumentasie] nie 'n wetenskaplike artikel is nie, het ek steeds van die ontwikkelaars verwag om 'n meer wetenskaplike benadering te volg, of 'n wetenskaplike benadering as verwysing te gebruik. Enige maatstawwe is nutteloos as dit nie gereproduseer kan word nie, en selfs meer nutteloos wanneer dit in die laboratorium verkry word.
In die Linux-bou van WireGuard maak dit voordeel uit die gebruik van GSO - Generic Segmentation Offloading. Danksy hom skep die kliënt 'n groot pakkie van 64 kilogrepe en enkripteer / dekripteer dit in een slag. Dus word die koste om kriptografiese bewerkings aan te roep en te implementeer verminder. As u die deurset van u VPN-verbinding wil maksimeer, is dit 'n goeie idee.
Maar soos gewoonlik is die werklikheid nie so eenvoudig nie. Om so 'n groot pakkie na 'n netwerkadapter te stuur, vereis dat dit in baie kleiner pakkies gesny word. Die normale stuurgrootte is 1500 grepe. Dit wil sê, ons reus van 64 kilogrepe sal verdeel word in 45 pakkies (1240 grepe inligting en 20 grepe van die IP-kopskrif). Dan sal hulle vir 'n rukkie die werk van die netwerkadapter heeltemal blokkeer, want hulle moet saam en dadelik gestuur word. As gevolg hiervan sal dit lei tot 'n prioriteitsprong, en pakkies soos VoIP, byvoorbeeld, sal in 'n tou staan.
Dus, die hoë deurset wat WireGuard so vrymoedig beweer, word behaal ten koste van die verlangsaming van die netwerk van ander toepassings. En die WireGuard-span is reeds dit is my gevolgtrekking.
Maar kom ons gaan aan.
Volgens die maatstawwe in die tegniese dokumentasie toon die verbinding 'n deurset van 1011 Mbps.
Indrukwekkend.
Dit is veral indrukwekkend as gevolg van die feit dat die maksimum teoretiese deurset van 'n enkele Gigabit Ethernet-verbinding 966 Mbps is met 'n pakkiegrootte van 1500 grepe minus 20 grepe vir die IP-kop, 8 grepe vir die UDP-kop en 16 grepe vir die kop van die WireGuard self. Daar is nog een IP-opskrif in die ingekapselde pakkie en nog een in TCP vir 20 grepe. So waar het hierdie ekstra bandwydte vandaan gekom?
Met groot rame en die voordele van GSO waaroor ons hierbo gepraat het, sou die teoretiese maksimum vir 'n raamgrootte van 9000 grepe 1014 Mbps wees. Gewoonlik is sulke deurset in werklikheid onbereikbaar, omdat dit met groot probleme gepaard gaan. Ek kan dus net aanneem dat die toets uitgevoer is met nog vetter oorgrootte rame van 64 kilogrepe met 'n teoretiese maksimum van 1023 Mbps, wat slegs deur sommige netwerkadapters ondersteun word. Maar dit is absoluut ontoepasbaar in werklike toestande, of kan slegs tussen twee direk gekoppelde stasies gebruik word, uitsluitlik binne die toetsbank.
Maar aangesien die VPN-tonnel tussen twee gashere aangestuur word deur 'n internetverbinding te gebruik wat glad nie jumbo-rame ondersteun nie, kan die resultaat wat op die bank behaal word, nie as 'n maatstaf geneem word nie. Dit is bloot 'n onrealistiese laboratoriumprestasie wat onmoontlik en ontoepasbaar is in werklike gevegstoestande.
Selfs as ek in die datasentrum gesit het, kon ek nie rame groter as 9000 grepe oordra nie.
Die kriterium van toepaslikheid in die werklike lewe word absoluut geskend en, soos ek dink, het die skrywer van die "meting" wat uitgevoer is, homself ernstig gediskrediteer om ooglopende redes.
Laaste sprankie hoop
Die WireGuard-webwerf praat baie oor houers en dit word duidelik waarvoor dit regtig bedoel is.
'N Eenvoudige en vinnige VPN wat geen konfigurasie vereis nie en kan ontplooi en gekonfigureer word met massiewe orkestrasie-instrumente soos Amazon in hul wolk het. Spesifiek, Amazon gebruik die nuutste hardeware-kenmerke wat ek vroeër genoem het, soos die AVX512. Dit word gedoen om die werk te bespoedig en nie aan x86 of enige ander argitektuur gekoppel te wees nie.
Hulle optimaliseer deurset en pakkies groter as 9000 grepe - dit sal groot ingekapselde rame wees vir houers om met mekaar te kommunikeer, of vir rugsteunbewerkings, die skep van foto's of die ontplooiing van dieselfde houers. Selfs dinamiese IP-adresse sal op geen manier die werking van WireGuard beïnvloed in die geval van die scenario wat ek beskryf het nie.
Goed gespeel. Briljante implementering en baie dun, amper verwysingsprotokol.
Maar dit pas net nie in 'n wêreld buite 'n datasentrum wat jy heeltemal beheer nie. As jy die risiko neem en WireGuard begin gebruik, sal jy voortdurend kompromieë moet aangaan in die ontwerp en implementering van die enkripsieprotokol.
Output
Dit is vir my maklik om tot die gevolgtrekking te kom dat WireGuard nog nie gereed is nie.
Dit is ontwerp as 'n liggewig en vinnige oplossing vir 'n aantal probleme met bestaande oplossings. Ongelukkig het hy ter wille van hierdie oplossings baie kenmerke opgeoffer wat vir die meeste gebruikers relevant sal wees. Dit is hoekom dit nie IPsec of OpenVPN kan vervang nie.
Om vir WireGuard mededingend te word, moet dit ten minste 'n IP-adresinstelling en 'n roetering en DNS-konfigurasie byvoeg. Dit is natuurlik waarvoor geënkripteerde kanale is.
Sekuriteit is my topprioriteit, en op die oomblik het ek geen rede om te glo dat IKE of TLS op een of ander manier gekompromitteer of gebreek is nie. Moderne enkripsie word in albei ondersteun, en dit is deur dekades se werking bewys. Net omdat iets nuwer is, beteken dit nie dat dit beter is nie.
Interoperabiliteit is uiters belangrik wanneer jy met derde partye kommunikeer wie se stasies jy nie beheer nie. IPsec is die de facto standaard en word byna oral ondersteun. En hy werk. En maak nie saak hoe dit lyk nie, in teorie sal WireGuard in die toekoms dalk nie versoenbaar wees nie, selfs met verskillende weergawes van homself.
Enige kriptografiese beskerming word vroeër of later verbreek en moet dienooreenkomstig vervang of bygewerk word.
Om al hierdie feite te ontken en blindelings WireGuard te wil gebruik om jou iPhone aan jou tuiswerkstasie te koppel, is net 'n meesterklas om jou kop in die sand te steek.
Bron: will.com