Hvers vegna AES-256 lýsir ekki VPN-dulkóðunarsetti
Sett gegnir fjórum hlutverkum: magndulkóðun, heilleika, lyklasetningu og auðkenningu jafningja. Dulmálsnafn nær yfir eitt þeirra, á einu lagi.
Spyrðu hvaða dulkóðun VPN notar og svarið kemur venjulega sem eitt orð: AES-256, eða ChaCha20, eða kannski WireGuard. Það svar nefnir eina einingu á einu lagi, en það sem verndar tenginguna í raun er safn reiknirita sem gegna fjórum mismunandi hlutverkum. Að rugla einingunni saman við uppsetninguna er algengasta mistökið í þessum samræðum og framleiðir samanburð sem ekki er hægt að leysa.
Fjögur verk innan einnar tengingar
Magndulkóðun breytir ljósum texta í dulritaðan texta fyrir gagnarásina og lykillinn er leiddur út í stað þess að vera sendur. Heilleikavörn greinir breytingu, sem er sérstakt verk jafnvel þótt ein smíði geri hvort tveggja. Lyklasetning framleiðir sameiginlegt umferðarefni og auðkenning jafningja ákveður hver er hinum megin. Ef eitt þeirra vantar er tengingin ekki örugg, hversu sterkt sem eftir stendur.
Sumar hannanir sameina tvö hlutverk í eitt. AES-GCM og ChaCha20-Poly1305 eru auðkenndar dulkóðunarsmíðar, svo trúnaður og heilleiki koma saman; AES-CBC ekki, og þarf sérstakan skilaboðaauðkenningarkóða með eigin lykli. Þess vegna les lestur tillögu sem poka af óháðum tölum rangt þær sem voru hannaðar sem pör.
Hlutverkin eru líka á mismunandi lögum, og þess vegna getur sama orðið þýtt mismunandi hluti í tveimur vörum. Blokkdulmál í ESP og blokkdulmál í TLS eru sama frumstæða í mismunandi samningaviðræðum með mismunandi kröfum. Þess vegna getur tilvitnun í frumstæðu án stillingar og lags verið verri en að vitna í ekkert.
Hvers vegna dulmálsnafn segir næstum ekkert
Taktu orðasambandið AES-256 alvarlega um stund: það tilgreinir blokkdulmál og lykilstærð. Það segir ekkert um vinnustillinguna, hvort heilleiki er veittur, hvernig lyklar voru settir eða hvernig jafninginn var auðkenndur. Tvær vörur geta báðar auglýst AES-256 og verið ólíkar í öllu öðru, þar á meðal ein með óauðkenndri stillingu og önnur með AEAD-stillingu og nútímalegum lyklaskiptum.
TLS 1.3 færði þessa aðgreiningu inn í staðalinn, sem er gagnleg leiðrétting fyrir alla sem lærðu eldra orðfærið. Dulmálssettin þess nefna aðeins AEAD og hass, en lyklaskiptahópar og undirskriftarreiknirit eru samin sem sérstakir færibreytur. Þess vegna er ekki hægt að bera saman heiti TLS 1.3 setts við heiti TLS 1.2 setts á jafnréttisgrundvelli, þótt bæði birtist í sama reit í stillingaskrá. Endurskoðandi sem ber saman strengina tvo beint dregur ályktun sem samskiptareglan styður ekki. Lestu líka samda hópinn og undirskriftarfæribreyturnar, annars er samanburðurinn ófullnægjandi.
WireGuard velur gagnstæða leið og fjarlægir samningaviðræður næstum algjörlega: samskiptareglan tilgreinir fast reikniritasafn, svo tvær útfærslur virka saman eða ekki. Það er lögmæt hönnunarákvörðun og þýðir líka að spurningin um hvaða sett WireGuard semur við hefur ekki svar sem er þess virði að bera saman. Ef þú endurskoðar það, lestu forskriftina einu sinni og endurskoðaðu síðan lyklistjórnunina í kringum hana í stað samningaviðræðnanna.
Lagið ákveður orðfærið
Uppsetning IPsec semur tvisvar: IKE-tillaga fyrir stjórnrásina og ESP-umbreyting fyrir gögnin, og þær tvær geta lögmætlega verið ólíkar. Að lesa þá fyrri og gera ráð fyrir að hún lýsi þeirri seinni er algeng uppspretta ruglings við endurskoðun, því stillingaskráin nefnir báðar og sú áhugaverða er seinni.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
Nafn sem er tiltækt í einu bókasafni er ekki sjálfkrafa útfært fyrir aðra gagnaleið. Þess vegna er fullyrðingin um að varan okkar styðji AES-256 veikari en hún hljómar, og þess vegna er rekstrarsamhæfisvandamál venjulega leyst með því að finna viðhaldið sniðmengi í stað þess að virkja hvert gamalt reiknirit á báðum hliðum.
Forskrift TLS 1.3 er skýrasta birt dæmið um aðgreininguna, því hún skilgreinir settið sem par og færir restina í eigin samningaviðræður. Þegar sú mynd er kunnugleg eru IPsec-tillagan og eitt fasta WireGuard-settið lesin sem afbrigði af sömu hugmynd.
Lestu samda niðurstöðu og stöðvaðu svo
Stilling tillaga er ekki sönnun um hvað tveir jafningjar völdu. Lifandi lotan ber svarið og hver algeng útfærsla getur tilkynnt það án pakkagreiningar.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showÍ úttakinu skaltu lesa valin reiknirit í stað boðslistans. Ef svarið er veikara en stefnan ætlaði sér á viðgerðin heima í tillögustillingunni á annarri hliðinni, og misræmi kemur venjulega fram í nútímaútfærslum sem misheppnuð samningaviðræður frekar en hljóðlát niðurfærsla.
Mundu svo hvað settið nær ekki yfir. Leiðir, forritsheimildir, skráning og varðveisla eru aðskildar ákvarðanir með eigin endurskoðun, og samhæf dulkóðunaruppsetning segir ekkert um þær. Dulmálsumræðan er þess virði, en hún svarar þrengri spurningu en sú sem flestir spyrja í raun.
Haltu orðfærinu nákvæmu og röksemdin verður styttri. Sett er safn hlutverka á lagi, dulmál er ein eining, og samda niðurstaðan er það eina sem lýsir tengingunni sem þú hefur í raun. Allt annað í samanburðinum er skraut.