HTTPS en een VPN authenticeren het pakket dat je installeert niet

Een update mislukt, en de suggestie in de thread volgt een bekend spoor: het verkeer gaat door een VPN, dus de download moet wel betrouwbaar zijn, en de handtekeningcontrole wordt versoepeld om de fout te omzeilen. Twee losse ideeën zijn samengesmolten tot één zin. Versleuteling beschermt een pad tussen eindpunten; authenticatie bepaalt of de bytes van de uitgever kwamen die je bedoelde. Een tunnel levert het eerste en zegt niets over het tweede.

Het symptoom is meestal een verificatiefout op één host, in één repository, terwijl al het andere normaal bijwerkt. Die vorm zegt al dat het netwerkpad werkt en dat het meningsverschil over vertrouwen gaat.

Twee controles die verschillende vragen beantwoorden

Transportbeveiliging beantwoordt wie er aan de andere kant van deze verbinding staat en of iemand op het pad die kan lezen of wijzigen. Pakketauthenticatie beantwoordt of dit artefact is gepubliceerd door de autoriteit die je hebt geconfigureerd, en die moet een download via een spiegel doorstaan die je niet beheert.

Die vragen overlappen alleen aan de randen. Een correct certificaat op een spiegel bewijst dat de spiegel de spiegel is; het bewijst niet dat de spiegel ongewijzigde uitgeversinhoud bevat. Een ondertekend pakket bewijst dat de uitgever het heeft ondertekend; het vertelt je niet dat het netwerk de nieuwste versie heeft geleverd of dat de repository die je aanwees de door jouw organisatie goedgekeurde is.

De faalmodus die mensen maken door controles uit te zetten, is een permanent verlies van de tweede garantie, in ruil voor één geslaagde download. Die ruil is onzichtbaar tot de dag dat hij ertoe doet.

Wat apt werkelijk authenticeert

Het model van APT is een geauthenticeerde archiefketen. Ondertekende release-metadata leiden via controlesom naar de pakketindexen, en die indexen leiden via controlesom naar de afzonderlijke pakketbestanden. Het verifiëren van de keten is wat een spiegel onbetrouwbaar maar bruikbaar maakt: de spiegel mag serveren wat hij wil, en de handtekening van de metadata bepaalt of APT het accepteert.

Dat is bewust niet hetzelfde als het controleren van een maintainer-handtekening op elk geïnstalleerd pakket, en het verschil verklaart waarom «het pakket is ondertekend» en «het archief is geauthenticeerd» door elkaar worden gebruikt in bugmeldingen terwijl ze verschillende dingen betekenen.

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

Lees de uitvoer van de update, niet alleen de exitcode. APT noemt de repository waarvan de metadata faalden, en die naam is de grens die je moet onderzoeken. Een repository die zonder handtekeningverificatie als vertrouwd is gemarkeerd, of een override voor een onveilige repository, is een configuratiebeslissing die iemand heeft genomen en zou moeten kunnen uitleggen.

Versheid is weer een aparte eigenschap. Een geldig ondertekend metadatabestand kan ouder zijn dan dat je vorige week zag, daarom dragen release-metadata een vervaldatum en daarom kan een klokprobleem op de client verificatiefouten geven die op sleutelproblemen lijken.

Wat dnf5 apart controleert

De RPM-kant biedt twee verschillende schakelaars, en ze door elkaar halen levert dezelfde klasse fout op in de andere richting. De ene regelt of pakketbestanden een geldige handtekening moeten dragen; de andere of repository-metadata ondertekend moeten zijn. Ze kunnen onafhankelijk worden ingesteld, en een systeem kan streng zijn over de ene en toegeeflijk over de andere.

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

De pakketquery laat zien hoe de handtekeningmetadata van de geïnstalleerde kopie eruitzien, wat een nuttige werkelijkheidstoets is tegen een configuratiebestand dat strengheid beweert. Wat het je niet vertelt, is het ondersteunde beleid van de distributie, en dat zou je moeten volgen in plaats van een algemene «schakel GPG in»-instructie van een forum.

Waar de twee beheerders verschillen, is het verschil architectonisch en geen teken dat de ene zwakker is. Beide authenticeren uitgeversinhoud; ze plaatsen de handtekening op verschillende punten in de keten.

Wat de tunnel toevoegt en wat niet

Een VPN kan een vereiste route leveren, updateverkeer buiten een onbetrouwbaar toegangsnetwerk houden en verminderen wat een lokale waarnemer ziet. Dat zijn echte operationele voordelen, en geen ervan is uitgeverauthenticatie.

HTTPS voegt zijn eigen garantie toe, en die is smaller dan hij voelt. Het authenticeert het TLS-eindpunt waarmee je verbonden bent. Als dat eindpunt een spiegel is, heb je de spiegel geauthenticeerd, niet de archiefinhoud die hij serveert. Dit is precies het geval waarvoor de keten van ondertekende metadata bestaat.

Geen van beide controles belooft beschikbaarheid. Een netwerk kan levering weigeren, en een geauthenticeerd object is niet automatisch het nieuwste. Gebruik het versheidsbeleid van de pakketbeheerder zelf in plaats van het af te leiden uit de aanwezigheid van een slotpictogram.

Diagnosticeer de grens die faalde

Benoem de fase voordat je iets verandert: DNS-resolutie, de proxy of route, de identiteit van het TLS-eindpunt, archiefauthenticatie, pakkethandtekeningcontroles of installatie. Elk heeft een eigen foutvorm en een eigen eigenaar.

Het repareren van een netwerkpad zou nooit mogen inhouden dat je een onbekende ondertekeningssleutel vertrouwd verklaart, certificaten negeert of een repository-configuratie accepteert die je niet hebt gevraagd. Als een sleutel echt is geroteerd, publiceert de distributie of de repository-eigenaar de nieuwe sleutel via een kanaal dat je kunt verifiëren, en dat is de correctie die moet worden toegepast.

Schrijf op welke grens faalde en wie hem bezit. De volgende updatefout zal bij een andere grens zijn, en de lijst hebben maakt er een diagnose van vijf minuten van in plaats van nog een discussie over of de tunnel updates veilig maakt.