Hvorfor er der ingen https-transport til debian apt-værktøj?

Der er. Du skal installere pakken apt-transport-https . Derefter kan du bruge linjer som

 deb https://some.server.com/debian stable main 

i din sources.list -fil. Men normalt er det ikke nødvendigt, da hele indholdet alligevel er offentligt, og det tilføjer kryptering overhead og latenstid. Da du ikke stoler på en angribers offentlige nøgle, er selv http-trafik sikker fra MitM-angreb. apt advarer dig og undlader at installere pakkerne, når en angriber injicerer manipulerede pakker.

EDIT: Som nævnt i kommentarerne er det faktisk mere sikkert at bruge TLS lager. Undersøgelser viser , at brug af apt på ukrypterede arkiver faktisk kan udgøre en sikkerhedsrisiko, da HTTP-transporten er sårbar over for gentagelsesangreb.

Kommentarer

• Nej, de fleste spejle understøtter ikke https. Simpelthen fordi det ikke ‘ ikke giver meget mening at kryptere denne form for trafik. Pakker verificeres alligevel, og oplysningerne er offentlige.
• Jeg kan tænke på et par grunde til, at jeg stadig foretrækker at downloade over TLS: 1) Jeg er måske interesseret i mit privatliv, når jeg installerer pakker, og 2) der kan være fejl i pakkeunderskriftskontrolkoden, som en MITM kunne udnytte.
• @JackO ‘ Connor, mens den første indvending om privatlivets fred er forståelig, den anden er som at sige, at jeg kan lide websteder til at underskrive deres indhold med PGP-nøgler, fordi der muligvis er fejl i TLS-kode. Både PGP og TLS skaber tillid; du behøver ikke ‘ begge dele til det.
• @Marco dit svar er forkert; adskillige forskningspapirer har vist, at både APT- og YUM-arkiver er sårbare over for gentagelsesangreb, når der er adgang til depotet via HTTP, selv med GPG-signaturer. Opbevaringssteder skal kun fås via TLS, 100% af tiden.
• Her er papiret, som @Joe Damato henviser til – se også hans svar her

Dit antagelsen er forkert: du kan bruge HTTPS-downloads. Du skal bare finde et spejl, der understøtter det, og placere dets URL på din kildeliste. Du skal installere pakken apt-transport-https .

Debian opretter ikke HTTPS download let, fordi der er meget lille fordel. Debians pakkedistribution inkluderer allerede en mekanisme til at verificere pakker: alle pakker er underskrevet med Gpg . Hvis en aktiv mand-i-midten omdirigerer din trafik til en server med beskadigede pakker, vil korruption blive opdaget, fordi GPG-signaturer ikke er gyldige. Brug af GPG snarere end HTTPS har den fordel, at det beskytter mod flere trusler: ikke kun mod aktiv mand-i-midten på slutbrugerforbindelsen, men også mod et skurk eller inficeret spejl eller andre problemer overalt i pakkedistributionskæden.

HTTPS giver en lille fortrolighedsfordel ved at det tilslører de pakker, du downloader. En passiv observatør kan dog stadig registrere trafik mellem din computer og en pakkeserver, så de ved, at du downloader Debian-pakker. De kunne også få en god idé om, hvilke pakker du downloader fra filstørrelserne.

Det eneste sted, hvor HTTPS vil hjælpe, er til bootstrapping-tillid for at få et kendt gyldigt installationsbillede. Debian gør ikke ” Det ser ud til at give det: der er kontrolsummer af installationsmedier , men kun via HTTP.

Kommentarer

• Der er HTTPS-version af installationsmediet: cdimage.debian.org/debian -cd
• Meget lille fordel? Hvad med justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke En specifik fejl, der er lettere at udnytte med HTTP end med HTTPS tæller en meget lille fordel, ja. Det ‘ er ikke som om HTTP havde en større angrebsflade end HTTPS: faktisk har HTTPS i sig selv en større angrebsflade, da den involverer mere kode. Så det er ‘ overhovedet ikke en nettofordel: det ‘ er en afvejning mellem to marginale risici.

For nylig kom jeg over problemet med min virksomheds apt-lager. Problemet var, at hvis vi bruger standard http transport alle andre kan nemt få pakken. Da virksomheden pakker sin egen proprietære software og ikke ønsker at dele den med alle, bliver http transport et problem. Ikke en tragedie, men et problem. Der er to måder at begrænse adgangen til pakken – firewalling, begrænsning af adgang på webserver-niveau ved hjælp af ssh som transport. Ret let at forbruge læsning om dette emne kan findes her: Begræns adgang til dit private Debian-lager

I vores tilfælde besluttede vi at bruge https transport + klientcertifikatgodkendelse. Kort fortalt er alt, hvad der kræves:

1. Forbered selvsignerede certifikater, klient og server (ved hjælp af easy-rsa);

2. Konfigurer webserver, der fronter arkivet til kun at acceptere https; I tilfælde af nginx kan det se ud som:

   server { listen 443; root /path/to/public; server_name secure_repo; ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; ssl_session_timeout 5m; ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:; ssl_prefer_server_ciphers on; ssl_client_certificate /etc/nginx/ssl/ca.crt; ssl_verify_client on; location / { autoindex on; } } 

3. Sæt klientcertifikat, klientnøgle og ca-certifikat til / etc / apt / ssl og tilføj, i tilfælde af Ubuntu, 00https-fil til /etc/apt/apt.conf.d:

   Debug::Acquire::https "true"; Acquire::https::example.com { Verify-Peer "true"; Verify-Host "false"; CaInfo "/etc/apt/ssl/ca.crt"; SslCert "/etc/apt/ssl/client.crt"; SslKey "/etc/apt/ssl/client.key"; };

Husk, at hvis du bruger selvsigneret certifikat, er det vigtigt at slå værtsbekræftelse fra: Verify-Host "false"; Hvis du ikke gør dette, skal du “Ll fanger en fejl: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

Og nu er vi gået, der er ikke mere uautoriseret adgang til lageret. Så dette er ret nyttigt og kraftfuldt.

Kommentarer

• Tak for det gode svar. Men jeg tror, at hovedproblemet stadig er der. HTTPS burde virkelig blive standardprotokollen for overførsler via internettet og især debianpakker. Argumentet burde ikke være hvorfor HTTPS, det burde være hvorfor ikke?
• @aalizadeh, jeg er enig med dig, der er overhead, når du bruger https, men der er ingen massiv overhead. Jeg tror, hovedårsagen til, at https ikke er en standardtransport, er, at nogle organisationer eksplicit forbyder krypteret trafik (da de vil være i stand til at stikke deres næse i, hvad medarbejderne laver over internettet), hvilket betyder, at arkiver skal støtte både http- og https-transporter. Der kan være andre overvejelser
• Brug af » Verify-Host ” false “; « er forkert, selv med selvsignerede certifikater. Du skal i stedet gøre dine klienter opmærksomme på det (korrekte) servercertifikat.
• Faktisk, men her var mine klienter kun interne systemer. Så i stedet for at skabe al ordentlig pki-infrastruktur skar jeg hjørnet. Og ja, senere blev pki afgjort ordentligt og Verify-Host false; blev fjernet. Og ja, pointen er gyldig.
• med ubuntu xenial hentes apt-pakkerne som uprivilegerede brugere _apt, kan du opdatere denne tråd med detaljer om, hvordan du administrerede eller løste filtilladelsesproblemerne.

Bemærk, at på grund af sårbarheder som

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467

… som omgår InRelease-signering, det er sandsynligvis en god ide at konfigurere HTTPS alligevel.

Og dette er ikke et enkelt eksempel – mange andre opdateringssystemer, der som standard er HTTP, har også haft en historie med signaturbekræftelsesfejl.

Sikkerhedskritiske opdateringsmekanismer skal bruge både HTTPS og signaturbekræftelse for at være robust. Hver afbøder den anden svigt.

Kommentarer

• Og nu også denne: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. InRelease-underskrift er ikke tilstrækkelig . ” Men at flytte alle spejle til HTTPS vil tage tid og koordination! “. Ja. Start nu. Dette vil ikke være den sidste InRelease-fejl.
• Her er ‘ et andet eksempel fra et andet økosystem – Alpine. Dens pakkehåndteringssystem ‘ bruger ikke HTTPS som standard og er udelukkende afhængig af signering for at kontrollere pakkeintegritet …og denne verifikation havde en fjernudnyttelig fejl i september 2018: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine skulle starte flytter nu til at bruge HTTPS som standard.
• (Fuld offentliggørelse: min egen kerne, men det ‘ er den eneste reference, jeg kender af), her er en liste over alle fejl i bekræftelsesfejl på klientsiden, som jeg ‘ er opmærksom på. Listen er ikke triviel i størrelse og vokser regelmæssigt. Tilføjer velkommen. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004