HTTPS dhe një VPN nuk e vërtetojnë paketën që instaloni

Një përditësim dështon, dhe sugjerimi në fill ndjek një linjë të njohur: trafiku kalon përmes një VPN, prandaj shkarkimi duhet të jetë i besueshëm, dhe verifikimi i nënshkrimit lehtësohet për të kaluar gabimin. Dy ide të ndara janë shkrirë në një fjali të vetme. Kriptimi mbron një rrugë midis dy skajeve; vërtetimi vendos nëse bajtët erdhën nga botuesi që kishit parasysh. Tuneli jep të parën dhe nuk thotë asgjë për të dytën.

Simptomi zakonisht është një gabim verifikimi në një host, në një depo, ndërsa gjithçka tjetër përditësohet normalisht. Ai formë tashmë thotë se rruga e rrjetit funksionon dhe se mospajtimi ka të bëjë me besimin.

Dy kontrolle që u përgjigjen pyetjeve të ndryshme

Siguria e transportit përgjigjet se kush është në skajin tjetër të kësaj lidhjeje dhe nëse dikush në rrugë mund ta lexojë ose ndryshojë atë. Vërtetimi i paketës përgjigjet nëse ky artefakt u publikua nga autoriteti që konfiguruat, dhe duhet t’i mbijetojë një shkarkimi përmes një pasqyre që nuk e kontrolloni.

Këto pyetje mbivendosen vetëm në skaje. Një certifikatë e saktë në një pasqyrë provon se pasqyra është pasqyra; nuk provon se pasqyra mban përmbajtje botuesi të pandryshuar. Një paketë e nënshkruar provon se botuesi e nënshkroi atë; nuk ju thotë se rrjeti dorëzoi versionin më të ri ose se depoja që treguat është ajo që miratoi organizata juaj.

Mënyra e dështimit që njerëzit krijojnë duke çaktivizuar kontrollet është një humbje e përhershme e garancisë së dytë, në këmbim të një shkarkimi të suksesshëm. Ky shkëmbim është i padukshëm deri në ditën kur ka rëndësi.

Çfarë vërteton në të vërtetë apt

Modeli i APT është një zinxhir arkivi i vërtetuar. Metadatat e publikimit të nënshkruara çojnë përmes shumës kontrolluese te indekset e paketave, dhe ato indekse çojnë përmes shumës kontrolluese te skedarët individualë të paketave. Është verifikimi i zinxhirit ai që e bën një pasqyrë jo të besueshme por të përdorshme: pasqyra mund të shërbejë çfarë të dojë, dhe nënshkrimi i metadatave vendos nëse APT e pranon.

Kjo me qëllim nuk është e njëjtë me kontrollimin e nënshkrimit të një mirëmbajtësi në çdo paketë të instaluar, dhe ky dallim shpjegon pse «paketa është e nënshkruar» dhe «arkivi është i vërtetuar» përdoren në mënyrë të këmbyeshme në raportet e gabimeve kur nënkuptojnë gjëra të ndryshme.

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

Lexoni daljen e përditësimit, jo vetëm kodin e daljes. APT emërton depon, metadatat e së cilës dështuan, dhe ai emër është kufiri për t’u hetuar. Një depo e shënuar si e besueshme pa verifikim nënshkrimi, ose një anulim për një depo të pasigurt, është një vendim konfigurimi që dikush e ka marrë dhe duhet të jetë në gjendje ta shpjegojë.

Freskia është përsëri një veti e veçantë. Një skedar metadatash i nënshkruar në mënyrë të vlefshme mund të jetë më i vjetër se ai që patë javën e kaluar, prandaj metadatat e publikimit mbajnë një datë skadimi dhe prandaj një problem ore në klient mund të prodhojë gabime verifikimi që duken si probleme çelësi.

Çfarë kontrollon veçmas dnf5

Ana e RPM ekspozon dy ndërprerës të veçantë, dhe ngatërrimi i tyre prodhon të njëjtën klasë gabimi në drejtimin tjetër. Njëri kontrollon nëse skedarët e paketave duhet të mbajnë një nënshkrim të vlefshëm; tjetri nëse metadatat e depos duhet të jenë të nënshkruara. Ato mund të vendosen në mënyrë të pavarur, dhe një sistem mund të jetë i rreptë në njërin dhe i lehtë në tjetrin.

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

Pyetja e paketës tregon se si duken metadatat e nënshkrimit të kopjes së instaluar, që është një kontroll realiteti i dobishëm kundrejt një skedari konfigurimi që pretendon rreptësi. Ajo që nuk ju thotë është politika e mbështetur e distribucionit, dhe është ajo që duhet të ndiqni në vend të një udhëzimi të përgjithshëm «aktivizoni GPG» nga një forum.

Aty ku dy menaxherët ndryshojnë, dallimi është arkitekturor dhe jo shenjë se njëri është më i dobët. Të dy vërtetojnë përmbajtjen e botuesit; ata e vendosin nënshkrimin në pika të ndryshme të zinxhirit.

Çfarë shton tuneli dhe çfarë jo

Një VPN mund të sigurojë një rrugë të nevojshme, ta mbajë trafikun e përditësimeve jashtë një rrjeti aksesi të pabesueshëm dhe të zvogëlojë atë që sheh një vëzhgues lokal. Këto janë përfitime reale operacionale, dhe asnjëra prej tyre nuk është vërtetim i botuesit.

HTTPS shton garancinë e vet, dhe ajo është më e ngushtë sesa duket. Ai vërteton skajin TLS me të cilin u lidhët. Nëse ai skaj është pasqyrë, ju keni vërtetuar pasqyrën, jo përmbajtjen e arkivit që ajo shërben. Ky është pikërisht rasti për të cilin ekziston zinxhiri i metadatave të nënshkruara.

Asnjë nga kontrollet nuk premton disponueshmëri. Një rrjet mund të refuzojë dorëzimin, dhe një objekt i vërtetuar nuk është automatikisht më i riu. Përdorni politikën e freskisë të vetë menaxherit të paketave në vend që ta nxirrni nga prania e një ikone dryni.

Diagnostikoni kufirin që dështoi

Emërtoni fazën para se të ndryshoni ndonjë gjë: zgjidhja DNS, proxy ose rruga, identiteti i skajit TLS, vërtetimi i arkivit, kontrollet e nënshkrimit të paketës ose instalimi. Secili ka një formë gabimi dhe një pronar të veçantë.

Riparimi i një rruge rrjeti nuk duhet të përfshijë kurrë shpalljen e një çelësi nënshkrimi të panjohur si të besueshëm, injorimin e certifikatave ose pranimin e një konfigurimi depoje që nuk e kërkuat. Nëse një çelës ka ndryshuar vërtet, distribucioni ose pronari i depos publikon çelësin e ri përmes një kanali që mund ta verifikoni, dhe ky është korrigjimi që duhet aplikuar.

Shkruani cili kufi dështoi dhe kush e zotëron atë. Dështimi i ardhshëm i përditësimit do të jetë në një kufi tjetër, dhe të kesh listën e bën atë një diagnozë pesë minutash në vend të një debati tjetër se a i bën tuneli përditësimet të sigurta.