Miks AES-256 ei kirjelda VPN-i krüpteerimiskomplekti
Komplekt täidab neli rolli: hulgkrüpteerimine, terviklikkus, võtmete loomine ja partneri autentimine. Šifri nimi katab neist ühe, ühel kihil.
Küsige, millist krüpteerimist VPN kasutab, ja vastus tuleb tavaliselt ühe sõnaga: AES-256 või ChaCha20 või võib-olla WireGuard. See vastus nimetab ühe kihi üht komponenti, samas kui ühendust tegelikult kaitsev asi on algoritmide kogum, mis täidab nelja erinevat rolli. Komponendi segamine korraldusega on nendes vestlustes kõige levinum viga ja tekitab võrdlusi, mida ei saa lahendada.
Neli tööd ühes ühenduses
Hulgkrüpteerimine muudab avateksti andmekanali jaoks šifreeritud tekstiks ja selle võti tuletatakse, mitte ei edastata. Terviklikkuse kaitse tuvastab muudatuse, mis on eraldi töö isegi siis, kui üks konstruktsioon teeb mõlemat. Võtmete loomine toodab ühise liiklusmaterjali ja partneri autentimine otsustab, kes on teises otsas. Kui üks neist puudub, ei ole ühendus turvaline, ükskõik kui tugev on allesjäänud tükk.
Mõned kavad ühendavad kaks rolli üheks. AES-GCM ja ChaCha20-Poly1305 on autenditud krüpteerimiskonstruktsioonid, seega tulevad konfidentsiaalsus ja terviklikkus koos; AES-CBC ei ole ja vajab eraldi sõnumi autentimiskoodi oma võtmega. Seetõttu loeb ettepaneku lugemine kui sõltumatute arvude koti valesti neid, mis on kavandatud paaridena.
Rollid asuvad ka erinevatel kihtidel, mistõttu võib sama sõna kahes tootes tähendada erinevat. Plokkšifr ESP-s ja plokkšifr TLS-s on sama primitiiv erinevates läbirääkimistes erinevate nõuetega. Seetõttu võib primitiivi tsiteerimine ilma selle režiimi ja kihita olla hullem kui mitte midagi tsiteerida.
Miks šifri nimi ei ütle peaaegu midagi
Võtke fraas AES-256 hetkeks tõsiselt: see tähistab plokkšifrit ja võtme suurust. See ei ütle midagi töörežiimi kohta, kas terviklikkus on tagatud, kuidas võtmed loodi või kuidas partner autenditi. Kaks toodet võivad mõlemad reklaamida AES-256 ja erineda kõiges muus, sealhulgas üks autentimata režiimiga ja teine AEAD-režiimiga ning kaasaegse võtmevahetusega.
TLS 1.3 viis selle eraldamise standardisse, mis on kasulik parandus kõigile, kes õppisid vanemat sõnavara. Selle šifrikomplektid nimetavad ainult AEAD-i ja räsi, samas kui võtmevahetusgrupid ja allkirjaalgoritmid lepitakse kokku eraldi parameetritena. Seetõttu ei saa TLS 1.3 komplekti nime võrrelda TLS 1.2 komplekti nimega võrdsetel alustel, kuigi mõlemad esinevad konfiguratsioonifaili samas väljas. Audiitor, kes võrdleb kahte stringi otse, jõuab järeldusele, mida protokoll ei toeta. Lugege ka läbiräägitud gruppi ja allkirja parameetreid, muidu on võrdlus puudulik.
WireGuard valib vastupidise tee ja eemaldab läbirääkimise peaaegu täielikult: protokoll määrab fikseeritud algoritmikomplekti, seega kaks rakendust kas töötavad koos või mitte. See on seaduslik disainivalik ja tähendab ka seda, et küsimusel, millist komplekti WireGuard läbiräägib, pole võrdlemist väärt vastust. Kui te seda auditeerite, lugege spetsifikatsiooni üks kord ja seejärel auditeerige selle ümber olevat võtmehaldust läbirääkimise asemel.
Kiht määrab sõnavara
IPsec-i juurutamine peab läbirääkimisi kaks korda: IKE ettepanek juhtkanali jaoks ja ESP teisendus andmete jaoks, ja need kaks võivad seaduslikult erineda. Esimese lugemine ja eeldamine, et see kirjeldab teist, on auditil tavaline segaduse allikas, sest konfiguratsioonifail mainib mõlemat ja huvitav on teine.
| 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 |
Ühes teegis saadaval olev nimi ei ole automaatselt rakendatud teise andmetee jaoks. Seetõttu on väide, et meie toode toetab AES-256, nõrgem kui see kõlab, ja seetõttu lahendatakse koostalitlusprobleem tavaliselt hooldatud ühisosa leidmisega, mitte kõigi vanade algoritmide lubamisega mõlemal pool.
TLS 1.3 spetsifikatsioon on selle eraldamise kõige selgem avaldatud näide, sest see määratleb komplekti paarina ja viib ülejäänu nende endi läbirääkimisse. Kui see kuju on tuttav, loetakse IPsec-i ettepanek ja üks fikseeritud WireGuard komplekt sama idee variantidena.
Lugege läbiräägitud tulemust ja siis lõpetage
Konfigureeritud ettepanek ei ole tõestus selle kohta, mille kaks partnerit valisid. Elav sessioon kannab vastust ja iga levinud rakendus saab sellest teatada ilma pakette püüdmata.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showVäljundis lugege valitud algoritme, mitte pakutud loendit. Kui vastus on nõrgem, kui poliitika kavatses, kuulub parandus ühe poole ettepaneku konfiguratsiooni, ja lahknevus ilmneb kaasaegsetes rakendustes tavaliselt ebaõnnestunud läbirääkimisena, mitte vaikse alandamisena.
Seejärel pidage meeles, mida komplekt ei kata. Marsruudid, rakenduste load, logimine ja säilitamine on eraldi otsused oma ülevaatega, ja ühilduv krüptograafiline korraldus ei ütle nende kohta midagi. Šifri arutelu on väärt, kuid vastab kitsamale küsimusele kui see, mida enamik inimesi tegelikult küsib.
Hoidke sõnavara täpne ja argument lüheneb. Komplekt on rollide kogum ühel kihil, šifr on üks komponent, ja läbiräägitud tulemus on ainus, mis kirjeldab ühendust, mis teil tegelikult on. Kõik muu võrdluses on kaunistus.