HTTPS og ein VPN autentiserer ikkje pakken du installerer

Ei oppdatering feilar, og forslaget i tråden følgjer ei kjend linje: trafikken går gjennom ein VPN, så nedlastinga må vere påliteleg, og signaturkontrollen vert lempa for å kome forbi feilen. To åtskilde idear er smelta saman til éi setning. Kryptering verner ein veg mellom endepunkt; autentisering avgjer om byta kom frå utgjevaren du meinte. Ein tunnel gjev det første og seier ingenting om det andre.

Symptomet er vanlegvis ein verifiseringsfeil på éin vert, i eitt lager, medan alt anna oppdaterer seg normalt. Den forma fortel alt at nettverksvegen verkar, og at usemja handlar om tillit.

To kontrollar som svarar på ulike spørsmål

Transporttryggleik svarar på kven som er i den andre enden av denne sambindinga og om nokon på vegen kan lese eller endre henne. Pakkeautentisering svarar på om denne artefakten vart publisert av styresmakta du sette opp, og ho må overleve ei nedlasting gjennom eit spegel du ikkje kontrollerer.

Dei spørsmåla overlappar berre i kantane. Eit korrekt sertifikat på eit spegel beviser at spegelen er spegelen; det beviser ikkje at spegelen held uendra utgjevarinnhald. Ein signert pakke beviser at utgjevaren signerte han; han fortel deg ikkje at nettverket leverte den nyaste versjonen, eller at lageret du peika på er det organisasjonen din godkjende.

Feilmodusen folk lagar ved å slå av kontrollar, er eit varig tap av den andre garantien, i byte mot éi vellukka nedlasting. Den handelen er usynleg til den dagen han betyr noko.

Kva apt faktisk autentiserer

Modellen til APT er ei autentisert arkivkjede. Signerte utgivingsmetadata leier via kontrollsum til pakkeindeksane, og desse indeksane leier via kontrollsum til dei einskilde pakkefilene. Det er verifiseringa av kjeda som gjer eit spegel upåliteleg, men brukande: spegelen kan servere kva han vil, og signaturen på metadataa avgjer om APT godtek det.

Det er med vilje ikkje det same som å sjekke signaturen til ein vedlikehaldar på kvar installert pakke, og skilnaden forklarer kvifor «pakken er signert» og «arkivet er autentisert» vert brukte om einannan i feilrapportar når dei betyr ulike ting.

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

Les utdataa frå oppdateringa, ikkje berre utgangskoden. APT namngjev lageret der metadataa feila, og det namnet er grensa som skal granskast. Eit lager merkt som klarert utan signaturverifisering, eller ei overstyring for eit utrygt lager, er ei oppsettsavgjerd nokon har teke og bør kunne forklare.

Ferskleik er igjen ein eigen eigenskap. Ei gyldig signert metadatafil kan vere eldre enn den du såg førre veke, difor har utgivingsmetadata ein utløpsdato, og difor kan eit klokkeproblem på klienten gje verifiseringsfeil som ser ut som nøkkelproblem.

Kva dnf5 kontrollerer separat

RPM-sida eksponerer to ulike brytarar, og å blande dei gjev same klasse feil i motsett retning. Den eine styrer om pakkefiler må bere ein gyldig signatur; den andre om lagermetadata må vere signerte. Dei kan setjast uavhengig, og eit system kan vere strengt på den eine og ettergjevande på den andre.

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

Pakkeførespurnaden viser korleis signaturmetadataa til den installerte kopien ser ut, noko som er ein nyttig royndomskontroll mot ei oppsettsfil som hevdar strengheit. Det han ikkje fortel deg, er den støtta politikken til distribusjonen, og det er den du bør følgje i staden for ei generell «slå på GPG»-rettleiing frå eit forum.

Der dei to handterarane er ulike, er skilnaden arkitektonisk og ikkje eit teikn på at den eine er svakare. Begge autentiserer utgjevarinnhald; dei plasserer signaturen på ulike punkt i kjeda.

Kva tunnelen tilfører og ikkje tilfører

Ein VPN kan gje ei nødvendig rute, halde oppdateringstrafikk utanfor eit upåliteleg tilgangsnett og redusere det ein lokal observatør ser. Det er reelle driftsfordelar, og ingen av dei er utgjevarautentisering.

HTTPS tilfører si eiga garanti, og ho er smalare enn ho kjennest. Ho autentiserer TLS-endepunktet du kopla til. Om det endepunktet er eit spegel, har du autentisert spegelen, ikkje arkivinnhaldet han serverer. Dette er nettopp tilfellet som kjeda av signerte metadata finst for.

Ingen av kontrollane lovar tilgjenge. Eit nett kan nekte levering, og eit autentisert objekt er ikkje automatisk det nyaste. Bruk ferskleikspolitikken til pakkehandteraren sjølv i staden for å utleie han frå tilstadeværet av eit hengelasikon.

Diagnostiser grensa som feila

Namngje trinnet før du endrar noko: DNS-oppslag, proxyen eller ruta, identiteten til TLS-endepunktet, arkivautentisering, pakkesignaturkontrollar eller installasjon. Kvar har ei eiga feilform og ein eigen eigar.

Reparasjon av ein nettverksveg bør aldri innebere å erklære ein ukjend signeringsnøkkel som klarert, ignorere sertifikat eller godta ein lagerkonfigurasjon du ikkje bad om. Om ein nøkkel faktisk er rotert, publiserer distribusjonen eller lagereigaren den nye nøkkelen gjennom ein kanal du kan verifisere, og det er rettinga som skal brukast.

Skriv ned kva grense som feila og kven som eig henne. Den neste oppdateringsfeilen vil vere ved ei anna grense, og å ha lista gjer det til ein fem minutts diagnose i staden for nok ein diskusjon om korvidt tunnelen gjer oppdateringar trygge.