Miksi AES-256 ei kuvaa VPN-salauspakettia
Paketti täyttää neljä roolia: massasalaus, eheys, avainten muodostus ja vastapuolen todentaminen. Salauksen nimi kattaa niistä yhden, yhdellä kerroksella.
Kysy, mitä salausta VPN käyttää, ja vastaus tulee yleensä yhtenä sanana: AES-256, tai ChaCha20, tai ehkä WireGuard. Se vastaus nimeää yhden kerroksen yhden komponentin, kun taas se, mikä todella suojaa yhteyttä, on joukko algoritmeja, jotka täyttävät neljä eri roolia. Komponentin sekoittaminen järjestelyyn on näissä keskusteluissa yleisin virhe, ja se tuottaa vertailuja, joita ei voi ratkaista.
Neljä työtä yhdessä yhteydessä
Massasalaus muuttaa selkokielisen tekstin salakirjoitukseksi datakanavaa varten, ja sen avain johdetaan eikä sitä siirretä. Eheyden suojaus havaitsee muutoksen, mikä on erillinen työ, vaikka yksi rakenne tekisi molemmat. Avainten muodostus tuottaa jaetun liikennemateriaalin, ja vastapuolen todentaminen päättää, kuka on toisessa päässä. Jos jokin niistä puuttuu, yhteys ei ole turvallinen, riippumatta siitä, kuinka vahva jäljelle jäävä osa on.
Jotkin suunnitelmat yhdistävät kaksi roolia yhdeksi. AES-GCM ja ChaCha20-Poly1305 ovat todennettuja salausrakenteita, joten luottamuksellisuus ja eheys tulevat yhdessä; AES-CBC ei ole, ja se tarvitsee erillisen viestin todennuskoodin omalla avaimellaan. Siksi ehdotuksen lukeminen itsenäisten lukujen säkkinä lukee väärin ne, jotka suunniteltiin pareiksi.
Roolit ovat myös eri kerroksissa, minkä vuoksi sama sana voi tarkoittaa eri asioita kahdessa tuotteessa. Lohkosalaus ESP:ssä ja lohkosalaus TLS:ssä ovat sama primitiivi eri neuvotteluissa eri vaatimuksin. Siksi primitiivin mainitseminen ilman sen tilaa ja kerrosta voi olla pahempaa kuin ei mitään.
Miksi salauksen nimi ei kerro juuri mitään
Ota ilmaus AES-256 hetkeksi vakavasti: se yksilöi lohkosalauksen ja avaimen koon. Se ei kerro mitään toimintatilasta, siitä tarjotaanko eheys, miten avaimet muodostettiin tai miten vastapuoli todennettiin. Kaksi tuotetta voivat molemmat mainostaa AES-256:ta ja erota kaikessa muussa, mukaan lukien yksi, joka yhdistää sen todentamattomaan tilaan, ja toinen, joka käyttää AEAD-tilaa ja nykyaikaista avaintenvaihtoa.
TLS 1.3 nosti tämän erottelun standardiin, mikä on hyödyllinen korjaus kaikille, jotka oppivat vanhemman sanaston. Sen salauspaketit nimeävät vain AEAD:n ja tiivisteen, kun taas avaintenvaihtoryhmät ja allekirjoitusalgoritmit neuvotellaan erillisinä parametreina. Siksi TLS 1.3 -paketin nimi ei ole vertailukelpoinen TLS 1.2 -paketin nimen kanssa tasapuolisesti, vaikka molemmat esiintyvät samassa määritystiedoston kentässä. Auditoija, joka vertaa kahta merkkijonoa suoraan, tekee johtopäätöksen, jota protokolla ei tue. Lue myös neuvoteltu ryhmä ja allekirjoitusparametrit, muuten vertailu on puutteellinen.
WireGuard valitsee vastakkaisen tien ja poistaa neuvottelun lähes kokonaan: protokolla määrittää kiinteän algoritmijoukon, joten kaksi toteutusta joko toimii yhdessä tai ei. Se on laillinen suunnitteluvalinta, ja se tarkoittaa myös, että kysymyksellä, mitä pakettia WireGuard neuvottelee, ei ole vertailun arvoista vastausta. Jos auditoit sitä, lue määrittely kerran ja auditoi sitten sen ympärillä oleva avaintenhallinta neuvottelun sijaan.
Kerros päättää sanaston
IPsec-käyttöönotto neuvottelee kahdesti: IKE-ehdotus ohjauskanavalle ja ESP-muunnos datalle, ja ne voivat laillisesti erota. Ensimmäisen lukeminen ja olettaminen, että se kuvaa toista, on yleinen sekaannuksen lähde auditoinnissa, koska määritystiedosto mainitsee molemmat ja kiinnostava on toinen.
| 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 |
Yhdessä kirjastossa saatavilla oleva nimi ei ole automaattisesti toteutettu toista datapolkua varten. Siksi väite, että tuotteemme tukee AES-256:ta, on heikompi kuin miltä se kuulostaa, ja siksi yhteentoimivuusongelma ratkaistaan yleensä löytämällä ylläpidetty leikkaus sen sijaan, että otettaisiin käyttöön kaikki vanhat algoritmit molemmilla puolilla.
TLS 1.3:n määrittely on erottelun selkein julkaistu esimerkki, koska se määrittelee paketin parina ja siirtää loput omaan neuvotteluunsa. Kun tämä muoto on tuttu, IPsec-ehdotus ja yksi kiinteä WireGuard-joukko luetaan saman idean muunnelmiksi.
Lue neuvoteltu tulos ja pysähdy sitten
Määritetty ehdotus ei ole todiste siitä, mitä kaksi osapuolta valitsi. Elävä istunto kantaa vastauksen, ja mikä tahansa tavallinen toteutus voi raportoida sen kaappaamatta paketteja.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showLue tulosteesta valitut algoritmit etkä tarjottua luetteloa. Jos vastaus on heikompi kuin käytäntö tarkoitti, korjaus kuuluu toisen osapuolen ehdotuksen määritykseen, ja eroavuus näkyy nykyaikaisissa toteutuksissa yleensä epäonnistuneena neuvotteluna eikä hiljaisena alentamisena.
Muista sitten, mitä paketti ei kata. Reitit, sovellusten käyttöoikeudet, kirjaus ja säilytys ovat erillisiä päätöksiä omine tarkastuksineen, eikä yhteensopiva salausjärjestely kerro niistä mitään. Salauksesta keskusteleminen on vaivan arvoista, mutta se vastaa kapeampaan kysymykseen kuin se, jonka useimmat todella esittävät.
Pidä sanasto täsmällisenä, niin argumentti lyhenee. Paketti on joukko rooleja kerroksella, salaus on yksi komponentti, ja neuvoteltu tulos on ainoa asia, joka kuvaa yhteyttä, joka sinulla todella on. Kaikki muu vertailussa on koristelua.