HTTPS ja VPN eivät todista asentamaasi pakettia

Päivitys epäonnistuu, ja ketjun ehdotus seuraa tuttua linjaa: liikenne kulkee VPN:n kautta, joten latauksen täytyy olla luotettava, ja allekirjoituksen tarkistusta löysennetään virheen ohittamiseksi. Kaksi erillistä ajatusta on sulautunut yhteen lauseeseen. Salaus suojaa polun päätepisteiden välillä; todennus päättää, tulivatko tavut siltä julkaisijalta, jota tarkoitit. Tunneli antaa ensimmäisen eikä sano toisesta mitään.

Oire on yleensä vahvistusvirhe yhdellä isännällä, yhdessä varastossa, kun kaikki muu päivittyy normaalisti. Tämä muoto kertoo jo, että verkkopolku toimii ja että erimielisyys koskee luottamusta.

Kaksi valvontaa, jotka vastaavat eri kysymyksiin

Siirtoturvallisuus vastaa, kuka on tämän yhteyden toisessa päässä ja voiko joku polulla lukea tai muuttaa sitä. Paketin todennus vastaa, julkaisiko tämän artefaktin se taho, jonka määritit, ja sen on kestettävä lataus peilin kautta, jota et hallitse.

Nämä kysymykset kohtaavat vain reunoilla. Oikea varmenne peilissä todistaa, että peili on peili; se ei todista, että peili sisältää muuttumatonta julkaisijan sisältöä. Allekirjoitettu paketti todistaa, että julkaisija allekirjoitti sen; se ei kerro, että verkko toimitti uusimman version tai että osoittamasi varasto on se, jonka organisaatiosi hyväksyi.

Epäonnistumistila, jonka ihmiset luovat poistamalla tarkistukset käytöstä, on toisen takuun pysyvä menetys yhden onnistuneen latauksen vastineeksi. Tämä vaihtokauppa on näkymätön siihen päivään asti, jolloin sillä on merkitystä.

Mitä apt todella todentaa

APT:n malli on todennettu arkistoketju. Allekirjoitetut julkaisun metatiedot johtavat tarkistussumman kautta paketti-indekseihin, ja ne indeksit johtavat tarkistussumman kautta yksittäisiin pakettitiedostoihin. Ketjun vahvistaminen tekee peilistä epäluotettavan mutta käyttökelpoisen: peili voi tarjoilla mitä haluaa, ja metatietojen allekirjoitus päättää, hyväksyykö APT sen.

Tämä ei tarkoituksella ole sama kuin ylläpitäjän allekirjoituksen tarkistaminen jokaisessa asennetussa paketissa, ja ero selittää, miksi «paketti on allekirjoitettu» ja «arkisto on todennettu» esiintyvät virheraporteissa toistensa sijasta, vaikka ne tarkoittavat eri asioita.

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

Lue päivityksen tuloste, älä vain paluukoodia. APT nimeää varaston, jonka metatiedot epäonnistuivat, ja se nimi on tutkittava raja. Varasto, joka on merkitty luotetuksi ilman allekirjoituksen vahvistusta, tai turvattoman varaston ohitus, on jonkun tekemä kokoonpanopäätös, ja hänen pitäisi pystyä selittämään se.

Tuoreus on taas erillinen ominaisuus. Kelvollisesti allekirjoitettu metatietotiedosto voi olla vanhempi kuin viime viikolla näkemäsi, siksi julkaisun metatiedoissa on vanhenemisaika ja siksi asiakkaan kello-ongelma voi tuottaa vahvistusvirheitä, jotka näyttävät avainongelmilta.

Mitä dnf5 tarkistaa erikseen

RPM-puoli tarjoaa kaksi erillistä kytkintä, ja niiden sekoittaminen tuottaa saman virheluokan toiseen suuntaan. Toinen ohjaa, täytyykö pakettitiedostoissa olla kelvollinen allekirjoitus; toinen ohjaa, täytyykö varaston metatiedot olla allekirjoitettu. Ne voidaan asettaa toisistaan riippumatta, ja järjestelmä voi olla tiukka toisessa ja salliva toisessa.

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

Pakettikysely näyttää, miltä asennetun kopion allekirjoituksen metatiedot näyttävät, mikä on hyödyllinen todellisuustarkistus tiukkuutta väittävää kokoonpanotiedostoa vastaan. Se mitä se ei kerro, on jakelun tuettu käytäntö, ja sitä sinun pitäisi seurata foorumin yleisen «ota GPG käyttöön» -ohjeen sijaan.

Missä kaksi hallintatyökalua eroavat, ero on arkkitehtoninen eikä merkki siitä, että toinen olisi heikompi. Molemmat todentavat julkaisijan sisältöä; ne sijoittavat allekirjoituksen ketjun eri kohtiin.

Mitä tunneli lisää ja mitä ei

VPN voi tarjota vaaditun reitin, pitää päivitysliikenteen poissa epäluotettavasta käyttöverkkosta ja vähentää sitä, mitä paikallinen tarkkailija näkee. Nämä ovat todellisia toiminnallisia etuja, eikä mikään niistä ole julkaisijan todennus.

HTTPS lisää oman takuunsa, ja se on kapeampi kuin tuntuu. Se todentaa TLS-päätepisteen, johon yhdistit. Jos se päätepiste on peili, olet todentanut peilin, et sen tarjoilemaa arkistosältöä. Juuri tämä on tapaus, jota varten allekirjoitettujen metatietojen ketju on olemassa.

Kumpikaan valvonta ei lupaa saatavuutta. Verkko voi evätä toimituksen, eikä todennettu objekti ole automaattisesti uusin. Käytä paketinhallinnan omaa tuoreuskäytäntöä sen sijaan, että päättelet sen lukkokuvakkeen olemassaolosta.

Diagnosoi raja, joka petti

Nimeä vaihe ennen kuin muutat mitään: DNS-selvitys, välityspalvelin tai reitti, TLS-päätepisteen identiteetti, arkiston todennus, paketin allekirjoituksen tarkistukset tai asennus. Jokaisella on erilainen virhemuoto ja erilainen omistaja.

Verkkopolun korjaamiseen ei pitäisi koskaan kuulua tuntemattoman allekirjoitusavaimen julistaminen luotetuksi, varmenteiden sivuuttaminen tai sellaisen varastokokoonpanon hyväksyminen, jota et pyytänyt. Jos avain todella vaihtui, jakelu tai varaston omistaja julkaisee uuden avaimen kanavaa pitkin, jonka voit vahvistaa, ja se on sovellettava korjaus.

Kirjoita ylös, mikä raja petti ja kuka sen omistaa. Seuraava päivitysepäonnistuminen on eri rajalla, ja listan olemassaolo tekee siitä viiden minuutin diagnoosin sen sijaan, että käytäisiin taas väittely siitä, tekeekö tunneli päivityksistä turvallisia.