HTTPS en ’n VPN verifieer nie die pakket wat jy installeer nie

’n Opdatering misluk, en die voorstel in die draad volg bekende lyne: die verkeer gaan deur ’n VPN, dus moet die aflaai betroubaar wees, en die handtekeningkontrole word verslap om verby die fout te kom. Twee afsonderlike idees is in een sin saamgevoeg. Versleuteling beskerm ’n pad tussen eindpunte; verifikasie besluit of die grepe van die uitgewer kom wat jy bedoel het. ’n Tonnel voorsien die eerste en sê niks oor die tweede.

Die simptoom is gewoonlik ’n verifikasiefout op een gasheer, in een bewaarplek, terwyl alles anders normaal opdateer. Daardie vorm sê al klaar dat die netwerkpad werk en dat die verskil oor vertroue gaan.

Twee kontroles wat verskillende vrae beantwoord

Vervoersekuriteit beantwoord wie aan die ander kant van hierdie verbinding is en of iemand op die pad dit kan lees of verander. Pakketverifikasie beantwoord of hierdie artefak deur die outoriteit gepubliseer is wat jy opgestel het, en dit moet oorleef wanneer dit deur ’n spieël afgelaai word wat jy nie beheer nie.

Daardie vrae oorvleuel net aan die rande. ’n Korrekte sertifikaat op ’n spieël bewys die spieël is die spieël; dit bewys nie dat die spieël onveranderde uitgewerinhoud hou nie. ’n Ondertekende pakket bewys die uitgewer het dit onderteken; dit sê nie vir jou die netwerk het die nuutste weergawe afgelewer of dat die bewaarplek wat jy gemik het die een is wat jou organisasie goedgekeur het nie.

Die foutmodus wat mense skep deur kontroles af te skakel, is ’n permanente verlies van die tweede waarborg, in ruil vir een suksesvolle aflaai. Daardie ruil is onsigbaar tot die dag wanneer dit saak maak.

Wat apt werklik verifieer

APT se model is ’n geoutentiseerde argiefketting. Ondertekende vrystellingsmetadata lei per kontrolesom na die pakketindekse, en daardie indekse lei per kontrolesom na die individuele pakketlêers. Die verifikasie van die ketting is wat ’n spieël onvertroud maar bruikbaar maak: die spieël kan enigiets voorsien wat dit wil, en die metadata-handtekening besluit of APT dit aanvaar.

Dit is doelbewus nie dieselfde as om ’n instandhouer-handtekening op elke geïnstalleerde pakket na te gaan nie, en die onderskeid verduidelik waarom mense in foutverslae «die pakket is onderteken» en «die argief is geoutentiseer» as uitruilbaar gebruik wanneer hulle verskillende dinge bedoel.

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

Lees die opdateringsuitset eerder as net die uitgangskode. APT noem die bewaarplek wie se metadata misluk het, en daardie naam is die grens om te ondersoek. ’n Bewaarplek wat as vertroud gemerk is sonder handtekeningverifikasie, of ’n oorheersing vir onveilige bewaarplekke, is ’n konfigurasiebesluit wat iemand geneem het en moet kan verduidelik.

Varsheid is weer ’n aparte eienskap. ’n Geldig ondertekende metadataleêr kan ouer wees as die een wat jy verlede week gesien het, en daarom dra vrystellingsmetadata ’n vervaldatum en daarom kan ’n klokprobleem op die kliënt verifikasiefoute veroorsaak wat soos sleutelprobleme lyk.

Wat dnf5 afsonderlik nagaan

Die RPM-kant bied twee duidelike skakelaars, en om hulle te verwar lewer dieselfde soort fout in die ander rigting. Een beheer of pakketlêers ’n geldige handtekening moet dra; die ander beheer of bewaarplekmetadata onderteken moet wees. Hulle kan onafhanklik gestel word, en ’n stelsel kan streng oor een wees terwyl dit toegeeflik oor die ander is.

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

Die pakketnavraag wys hoe die geïnstalleerde kopie se handtekeningmetadata lyk, wat ’n nuttige werklikheidstoets is teen ’n konfigurasielêer wat strengheid beweer. Wat dit nie vir jou sê nie, is die verspreiding se ondersteunde beleid, en dit is wat jy moet volg eerder as ’n algemene «aktiveer GPG»-instruksie van ’n forum.

Waar die twee bestuurders verskil, is die verskil argitektonies eerder as ’n teken dat een swakker is. Albei verifieer uitgewerinhoud; hulle plaas die handtekening op verskillende punte in die ketting.

Wat die tonnel byvoeg en nie byvoeg nie

’n VPN kan ’n vereiste roete voorsien, opdateringsverkeer van ’n onbetroubare toegangsnetwerk af hou en verminder wat ’n plaaslike waarnemer sien. Dit is werklike operasionele voordele, en nie een daarvan is uitgewerverifikasie nie.

HTTPS voeg sy eie waarborg by, en dit is smaller as wat dit voel. Dit verifieer die TLS-eindpunt waaraan jy gekoppel het. As daardie eindpunt ’n spieël is, het jy die spieël geverifieer, nie die argiefinhoud wat dit voorsien nie. Dit is juis die geval waarvoor die ondertekende-metadataketting bestaan.

Nie een van die kontroles belowe beskikbaarheid nie. ’n Netwerk kan aflewering weier, en ’n geoutentiseerde objek is nie outomaties die nuutste een nie. Gebruik die pakketbestuurder se eie varsheidsbeleid eerder as om dit uit die teenwoordigheid van ’n slotikoon af te lei.

Diagnoseer die grens wat gefaal het

Noem die stadium voordat jy iets verander: DNS-resolusie, die instaanbediener of roete, die TLS-eindpuntidentiteit, argiefverifikasie, pakket-handtekeningkontroles, of installasie. Elkeen het ’n duidelike foutvorm en ’n duidelike eienaar.

Om ’n netwerkpad te herstel behoort nooit te behels dat jy ’n onbekende ondertekeningsleutel as vertroud verklaar, sertifikate ignoreer, of ’n bewaarplekkonfigurasie aanvaar wat jy nie gevra het nie. As ’n sleutel werklik geroteer het, publiseer die verspreiding of die bewaarplekeienaar die nuwe sleutel deur ’n kanaal wat jy kan verifieer, en dit is die regstelling om toe te pas.

Skryf neer watter grens gefaal het en wie dit besit. Die volgende opdateringsfout sal by ’n ander grens wees, en om die lys te hê maak dit ’n diagnose van vyf minute in plaas van nog ’n argument oor of die tonnel opdaterings veilig maak.