Pam nad yw AES-256 yn disgrifio pecyn amgryptio VPN
Mae pecyn yn llenwi pedair rôl: amgryptio swmp, cyfanrwydd, sefydlu allweddi a dilysu’r cyfoed. Mae enw seiffr yn cynnwys un ohonynt, ar un haen.
Gofynnwch pa amgryptio y mae VPN yn ei ddefnyddio ac mae’r ateb fel arfer yn dod yn un gair: AES-256, neu ChaCha20, neu efallai WireGuard. Mae’r ateb hwnnw’n enwi un elfen o un haen, tra mai’r hyn sy’n amddiffyn y cysylltiad mewn gwirionedd yw set o algorithmau sy’n llenwi pedair rôl wahanol. Cymysgu’r elfen â’r trefniant yw’r camgymeriad mwyaf cyffredin yn y sgyrsiau hyn, ac mae’n cynhyrchu cymariaethau na ellir eu datrys.
Pedair swydd o fewn un cysylltiad
Mae amgryptio swmp yn troi testun clir yn destun seiffr ar gyfer sianel y data, ac mae ei allwedd yn cael ei deillio yn hytrach na’i throsglwyddo. Mae amddiffyn cyfanrwydd yn canfod newid, sy’n swydd ar wahân hyd yn oed pan fo un adeiladwaith yn gwneud y ddau. Mae sefydlu allweddi yn cynhyrchu’r deunydd traffig a rennir, ac mae dilysu’r cyfoed yn penderfynu pwy sydd ar y pen arall. Os oes un yn eisiau, nid yw’r cysylltiad yn ddiogel, waeth pa mor gryf yw’r darn sy’n weddill.
Mae rhai cynlluniau’n cyfuno dwy rôl yn un. Mae AES-GCM a ChaCha20-Poly1305 yn adeiladweithiau amgryptio dilysedig, felly daw cyfrinachedd a chyfanrwydd gyda’i gilydd; nid yw AES-CBC felly, ac mae angen cod dilysu neges ar wahân gyda’i allwedd ei hun. Felly mae darllen cynnig fel bag o rifau annibynnol yn darllen yn anghywir y rhai a gynlluniwyd fel parau.
Mae’r rolau hefyd ar haenau gwahanol, a dyna pam y gall yr un gair olygu gwahanol bethau mewn dau gynnyrch. Mae seiffr bloc yn ESP a seiffr bloc yn TLS yr un primitive mewn trafodaethau gwahanol â gofynion gwahanol. Felly gall dyfynnu primitive heb ei fodd a’i haen fod yn waeth na pheidio â dyfynnu dim.
Pam nad yw enw seiffr yn dweud fawr ddim
Cymerwch yr ymadrodd AES-256 o ddifrif am eiliad: mae’n nodi seiffr bloc a maint allwedd. Nid yw’n dweud dim am y modd gweithredu, a yw cyfanrwydd yn cael ei ddarparu, sut y sefydlwyd allweddi neu sut y dilyswyd y cyfoed. Gall dau gynnyrch ill dau hysbysebu AES-256 a gwahaniaethu ym mhob peth arall, gan gynnwys un sy’n ei baru â modd heb ei ddilysu ac un arall sy’n defnyddio modd AEAD gyda chyfnewid allweddi modern.
Gwnaeth TLS 1.3 symud y gwahanu hwn i’r safon, sy’n gywiriad defnyddiol i unrhyw un a ddysgodd yr eirfa hŷn. Mae ei becynnau seiffr yn enwi’r AEAD a’r hash yn unig, tra bod grwpiau cyfnewid allweddi a algorithmau llofnod yn cael eu trafod fel paramedrau ar wahân. Felly nid yw enw pecyn TLS 1.3 yn gymharol ag enw pecyn TLS 1.2 ar sail gyfartal, er bod y ddau’n ymddangos yn yr un maes o ffeil ffurfweddu. Mae archwiliwr sy’n cymharu’r ddwy linyn yn uniongyrchol yn dod i gasgliad nad yw’r protocol yn ei gefnogi. Darllenwch y grŵp a drafodwyd a’r paramedrau llofnod hefyd, neu mae’r gymhariaeth yn anghyflawn.
Mae WireGuard yn dewis y ffordd arall ac yn dileu trafodaeth bron yn gyfan gwbl: mae’r protocol yn nodi set sefydlog o algorithmau, felly mae dau weithrediad naill ai’n cydweithio neu ddim. Mae hynny’n ddewis dylunio dilys, ac mae hefyd yn golygu nad oes ateb gwerth ei gymharu i’r cwestiwn pa becyn y mae WireGuard yn ei drafod. Os ydych yn ei archwilio, darllenwch y manyleb unwaith ac yna archwiliwch y rheolaeth allweddi o’i chwmpas yn lle’r drafodaeth.
Yr haen sy’n penderfynu’r eirfa
Mae defnydd IPsec yn trafod ddwywaith: cynnig IKE ar gyfer y sianel reoli a thrawsnewidiad ESP ar gyfer y data, a gall y ddau fod yn wahanol yn ddilys. Darllen y cyntaf a thybio ei fod yn disgrifio’r ail yw ffynhonnell gyffredin o ddryswch yn ystod archwiliad, oherwydd mae’r ffeil ffurfweddu’n sôn am y ddau a’r un diddorol yw’r ail.
| 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 |
Nid yw enw sydd ar gael mewn un llyfrgell yn cael ei weithredu’n awtomatig ar gyfer llwybr data arall. Felly mae’r datganiad bod ein cynnyrch yn cefnogi AES-256 yn wannach nag y mae’n swnio, a dyna pam mae problem rhyngweithredu fel arfer yn cael ei datrys trwy ddod o hyd i’r croestoriad a gynhelir yn lle galluogi pob algorithm hen ar y ddwy ochr.
Manyleb TLS 1.3 yw’r enghraifft gyhoeddedig gliriaf o’r gwahanu, oherwydd mae’n diffinio’r pecyn fel pâr ac yn symud y gweddill i’w drafodaeth ei hun. Unwaith y bydd y siâp hwnnw’n gyfarwydd, mae cynnig IPsec a’r un set sefydlog WireGuard yn darllen fel amrywiadau ar yr un syniad.
Darllenwch y canlyniad a drafodwyd, yna stopiwch
Nid yw cynnig wedi’i ffurfweddu’n dystiolaeth o’r hyn a ddewisodd dau gyfoed. Mae’r sesiwn fyw yn cario’r ateb, a gall pob gweithrediad prif ffrwd ei adrodd heb ddal pecynnau.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show
Yn yr allbwn darllenwch yr algorithmau a ddewiswyd yn lle’r rhestr a gynigiwyd. Os yw’r ateb yn wannach nag y bwriadodd y polisi, mae’r cywiriad yn perthyn i ffurfweddiad y cynnig ar un ochr, ac mae anghysondeb fel arfer yn ymddangos mewn gweithrediadau modern fel trafodaeth wedi methu yn hytrach nag israddio distaw.
Yna cofiwch beth nad yw’r pecyn yn ei gynnwys. Llwybrau, caniatâd cymwysiadau, cofnodi a chadwraeth yn benderfyniadau ar wahân â’u hadolygiad eu hunain, ac nid yw trefniant cryptograffig cydnaws yn dweud dim amdanynt. Mae’r drafodaeth am y seiffr yn werth ei chael, ond mae’n ateb cwestiwn culach na’r un y mae’r rhan fwyaf o bobl yn ei ofyn mewn gwirionedd.
Cadwch yr eirfa’n fanwl a bydd y ddadl yn byrhau. Mae pecyn yn set o rolau ar haen, mae seiffr yn un elfen, a’r canlyniad a drafodwyd yw’r unig beth sy’n disgrifio’r cysylltiad sydd gennych mewn gwirionedd. Mae popeth arall yn y gymhariaeth yn addurn.