HTTPS og en VPN autentiserer ikke pakken du installerer

En oppdatering feiler, og forslaget i tråden følger en kjent linje: trafikken går gjennom en VPN, så nedlastingen må være pålitelig, og signaturkontrollen lempes for å komme forbi feilen. To atskilte ideer er smeltet sammen til én setning. Kryptering beskytter en vei mellom endepunkter; autentisering avgjør om bytene kom fra utgiveren du mente. En tunnel gir det første og sier ingenting om det andre.

Symptomet er vanligvis en verifiseringsfeil på én vert, i ett lager, mens alt annet oppdateres normalt. Den formen forteller allerede at nettverksveien virker, og at uenigheten handler om tillit.

To kontroller som svarer på forskjellige spørsmål

Transportsikkerhet svarer på hvem som er i den andre enden av denne forbindelsen og om noen på veien kan lese eller endre den. Pakkeautentisering svarer på om denne artefakten ble publisert av myndigheten du konfigurerte, og den må overleve en nedlasting gjennom et speil du ikke kontrollerer.

Disse spørsmålene overlapper bare i kantene. Et korrekt sertifikat på et speil beviser at speilet er speilet; det beviser ikke at speilet inneholder uendret utgiverinnhold. En signert pakke beviser at utgiveren signerte den; den forteller deg ikke at nettverket leverte den nyeste versjonen, eller at lageret du pekte på er det organisasjonen din godkjente.

Feilmodusen folk lager ved å slå av kontroller, er et permanent tap av den andre garantien, i bytte mot én vellykket nedlasting. Den handelen er usynlig til den dagen den betyr noe.

Hva apt faktisk autentiserer

APT-modellen er en autentisert arkivkjede. Signerte utgivelsesmetadata leder via kontrollsum til pakkeindeksene, og disse indeksene leder via kontrollsum til de enkelte pakkefilene. Det er verifiseringen av kjeden som gjør et speil upålitelig, men brukbart: speilet kan servere hva det vil, og signaturen på metadataene avgjør om APT godtar det.

Det er med vilje ikke det samme som å sjekke en vedlikeholders signatur på hver installert pakke, og forskjellen forklarer hvorfor «pakken er signert» og «arkivet er autentisert» brukes om hverandre i feilrapporter når de betyr forskjellige ting.

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

Les utdataene fra oppdateringen, ikke bare utgangskoden. APT navngir lageret der metadataene feilet, og det navnet er grensen som skal undersøkes. Et lager merket som klarert uten signaturverifisering, eller en overstyring for et usikkert lager, er en konfigurasjonsbeslutning noen har tatt og bør kunne forklare.

Ferskhet er igjen en egen egenskap. En gyldig signert metadatafil kan være eldre enn den du så forrige uke, derfor har utgivelsesmetadata en utløpsdato, og derfor kan et klokkeproblem på klienten gi verifiseringsfeil som ser ut som nøkkelproblemer.

Hva dnf5 kontrollerer separat

RPM-siden eksponerer to forskjellige brytere, og å forveksle dem gir samme klasse feil i motsatt retning. Den ene styrer om pakkefiler må bære en gyldig signatur; den andre styrer om lagermetadata må være signert. De kan settes uavhengig, og et system kan være strengt på den ene og ettergivende på den andre.

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

Pakkeforespørselen viser hvordan signaturmetadataene til den installerte kopien ser ut, noe som er en nyttig virkelighetssjekk mot en konfigurasjonsfil som hevder strenghet. Det den ikke forteller deg, er distribusjonens støttede policy, og det er den du bør følge i stedet for en generell «aktiver GPG»-instruks fra et forum.

Der de to håndtererne er forskjellige, er forskjellen arkitektonisk og ikke et tegn på at den ene er svakere. Begge autentiserer utgiverinnhold; de plasserer signaturen på forskjellige punkter i kjeden.

Hva tunnelen tilfører og ikke tilfører

En VPN kan gi en nødvendig rute, holde oppdateringstrafikk utenfor et upålitelig tilgangsnett og redusere det en lokal observatør ser. Det er reelle driftsfordeler, og ingen av dem er utgiverautentisering.

HTTPS tilfører sin egen garanti, og den er smalere enn den føles. Den autentiserer TLS-endepunktet du koblet til. Hvis det endepunktet er et speil, har du autentisert speilet, ikke arkivinnholdet det serverer. Dette er nettopp tilfellet som kjeden av signerte metadata finnes for.

Ingen av kontrollene lover tilgjengelighet. Et nett kan nekte levering, og et autentisert objekt er ikke automatisk det nyeste. Bruk pakkehåndtererens egen ferskhetspolicy i stedet for å utlede den fra tilstedeværelsen av et hengelåsikon.

Diagnostiser grensen som feilet

Navngi trinnet før du endrer noe: DNS-oppslag, proxyen eller ruten, identiteten til TLS-endepunktet, arkivautentisering, pakkesignaturkontroller eller installasjon. Hver har en egen feilform og en egen eier.

Reparasjon av en nettverksvei bør aldri innebære å erklære en ukjent signeringsnøkkel som klarert, ignorere sertifikater eller godta en lagerkonfigurasjon du ikke ba om. Hvis en nøkkel faktisk er rotert, publiserer distribusjonen eller lagereieren den nye nøkkelen gjennom en kanal du kan verifisere, og det er rettelsen som skal brukes.

Skriv ned hvilken grense som feilet og hvem som eier den. Den neste oppdateringsfeilen vil være ved en annen grense, og å ha listen gjør det til en fem minutters diagnose i stedet for nok en diskusjon om hvorvidt tunnelen gjør oppdateringer trygge.