Hvorfor er det ingen https-transport for debian apt-verktøy?

Det er. Du må installere pakken apt-transport-https . Deretter kan du bruke linjer som

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

i sources.list -filen din. Men vanligvis er det ikke nødvendig, siden hele innholdet uansett er offentlig, og det legger til kryptering overhead og ventetid. Siden du ikke stoler på en angripers offentlige nøkkel, er til og med http-trafikk trygg fra MitM-angrep. apt vil advare deg og unnlate å installere pakkene når en angriper injiserer manipulerte pakker.

REDIGERING: Som nevnt i kommentarene er det faktisk sikrere å bruke TLS -register. Forskning viser at bruk av apt på ukrypterte arkiver faktisk kan utgjøre en sikkerhetsrisiko ettersom HTTP-transporten er sårbar for repriseangrep.

Kommentarer

• Nei, de fleste speil støtter ikke https. Bare fordi det ikke ‘ ikke gir mye mening å kryptere denne typen trafikk. Pakker blir verifisert uansett og informasjonen er offentlig.
• Jeg kan tenke på noen grunner til at jeg fremdeles foretrekker å laste ned over TLS: 1) Jeg bryr meg kanskje om personvernet mitt når jeg installerer pakker, og 2) der kan være feil i pakkesignaturkontrollkoden, som en MITM kan utnytte.
• @JackO ‘ Connor, mens den første innvendingen om personvern er forståelig, den andre er som å si at jeg liker nettsteder for å signere innholdet med PGP-nøkler fordi det kan være feil i TLS-kode. Både PGP og TLS skaper tillit; du trenger ikke ‘ begge deler for det.
• @Marco svaret ditt er feil; mange forskningsartikler har vist at både APT- og YUM-arkiver er sårbare for repriseangrep når depotet er tilgjengelig via HTTP, selv med GPG-signaturer. Repositories bør kun nås via TLS, 100% av tiden.
• Her er papiret @Joe Damato refererer til – se også hans svar her

Din antagelsen er feil: du kan bruke HTTPS-nedlastinger. Du må bare finne et speil som støtter det, og legge URL-en i kildelisten din. Du må installere apt-transport-https pakken.

Debian lager ikke HTTPS nedlastinger enkelt fordi det er veldig liten fordel. Distribusjon av Debian-pakker inkluderer allerede en mekanisme for å verifisere pakker: alle pakker er signert med Gpg . Hvis en aktiv mann-i-midten omdirigerer trafikken din til en server med ødelagte pakker, vil korrupsjonen bli oppdaget fordi GPG-signaturene ikke vil være gyldige. Å bruke GPG i stedet for HTTPS har fordelen at den beskytter mot flere trusler: ikke bare mot aktiv mann-i-midten på sluttbrukerforbindelsen, men også mot et useriøst eller infisert speil eller andre problemer hvor som helst i pakkedistribusjonskjeden.

HTTPS gir en liten fortrolighetsfordel ved at det tilslører pakkene du laster ned. En passiv observatør kan imidlertid fremdeles oppdage trafikk mellom datamaskinen din og en pakkeserver, slik at de vet at du laster ned Debian-pakker. De kan også få en god ide om hvilke pakker du laster ned fra filstørrelsene.

Det ene stedet hvor HTTPS vil hjelpe, er for bootstrapping-tillit, for å få et kjent gyldig installasjonsbilde. Debian gjør ikke » Det ser ut til å gi det: Det er kontrollsummer for installasjonsmedier , men bare via HTTP.

Kommentarer

• Det er HTTPS-versjon av installasjonsmediet: cdimage.debian.org/debian -cd
• Svært liten fordel? Hva med justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke En spesifikk feil som er lettere å utnytte med HTTP enn med HTTPS teller veldig liten fordel, ja. Det ‘ er ikke som om HTTP hadde en større angrepsflate enn HTTPS: faktisk har HTTPS i seg selv en større angrepsflate siden den innebærer mer kode. Så det er ikke ‘ ikke engang en nettofordel i det hele tatt: det ‘ er en avveining mellom to marginale risikoer.

Bare nylig kom jeg over problemet med firmaets apt repository. Problemet var at hvis vi bruker standard http transport noen andre kan enkelt få pakken. Siden selskapet pakker sin egen programvare og ikke ønsker å dele den med alle, blir http transport et problem. Ikke en tragedie, men et problem. Det er noen måter å begrense tilgangen til pakken – brannmur, begrenser tilgang på webservernivå, ved hjelp av ssh som transport. Ganske enkelt å konsumere lesing om dette emnet kan bli funnet her: Begrens tilgangen til ditt private Debian-depot

I vårt tilfelle bestemte vi oss for å bruke https transport + klientsertifikatgodkjenning. Kort fortalt er alt som trengs:

1. Forbered selvsignerte sertifikater, klient og server (bruker easy-rsa);

2. Konfigurer webserveren som fronter depotet slik at det bare godtar https; I tilfelle nginx kan det se ut 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. Sett klientsertifikat, klientnøkkel og ca-sertifikat til / etc / apt / ssl og, i tilfelle Ubuntu, legg til 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 bruker selvsignert sertifikat, er det viktig å slå av vertsbekreftelse: Verify-Host "false"; Hvis du ikke gjør dette, må du «Fanger en feil: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

Og her går vi, det er ikke mer uautorisert tilgang til depotet. Så dette er ganske nyttig og kraftig.

Kommentarer

• Takk for det gode svaret. Men jeg tror hovedsaken fortsatt er der. HTTPS bør virkelig bli standardprotokollen for overføringer over nettet og spesielt debianpakker. Argumentet burde ikke være hvorfor HTTPS, det burde være hvorfor ikke?
• @aalizadeh, jeg er enig med deg, det er overhead når du bruker https, men det er ingen massiv overhead. Jeg tror, hovedårsaken til at https ikke er en standardtransport, er at noen organisasjoner eksplisitt forbyder kryptert trafikk (ettersom de vil kunne stikke nesa i det de ansatte gjør over Internett), noe som betyr at repositorier må støtte både http- og https-transporter. Det kan være at det er andre hensyn
• Bruk av » Verify-Host » false «; « er feil, selv med selvsignerte sertifikater. Du må gjøre kundene dine oppmerksomme på (riktig) serversertifikat i stedet.
• Faktisk, men her var klientene mine bare interne systemer. Så i stedet for å lage all riktig PKI-infrastruktur, kuttet jeg hjørnet. Og ja, senere ble pki ordnet ordentlig og Verify-Host false; var fjerne. Og ja, poenget er gyldig.
• med ubuntu xenial hentes apt-pakkene som uprivilegerte brukere _apt, kan du oppdatere denne tråden med detaljer om hvordan du klarte eller løste problemene med filtillatelse.

Merk at på grunn av sårbarheter som

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

… som omgår InRelease-signering, det er sannsynligvis en god ide å konfigurere HTTPS uansett.

Og dette er ikke et enkelt eksempel – mange andre oppdateringssystemer som standard som HTTP har også hatt en historie med signaturverifiseringsfeil.

Sikkerhetskritiske oppdateringsmekanismer bør bruke både HTTPS og signaturverifisering for å være robust. Hver demper en svikt hos den andre.

Kommentarer

• Og nå også denne: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. InRelease-signering er ikke tilstrekkelig . » Men å flytte alle speil til HTTPS vil ta tid og koordinering! «. Ja. Start nå. Dette vil ikke være den siste InRelease-feilen.
• Her er ‘ et annet eksempel fra et annet økosystem – Alpine. Pakkehåndteringssystemet bruker ikke ‘ som standard HTTPS, og er avhengig utelukkende av signering for å bekrefte pakkeintegriteten …og at bekreftelsen hadde en ekstern utnyttbar feil i september 2018: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine skulle starte flytter nå til å bruke HTTPS som standard.
• (Full beskrivelse: min egen kjerne, men det ‘ er den eneste referansen jeg kjenner av), her er en liste over alle feil på bekreftelsesfeil på klientsiden som jeg ‘ er klar over. Listen er ikke triviell i størrelse, og vokser regelmessig. Legger velkommen. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004