Varför finns det ingen https-transport för debian apt-verktyg?

Det finns. Du måste installera paketet apt-transport-https . Sedan kan du använda rader som

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

i din sources.list -fil. Men vanligtvis är det inte nödvändigt, eftersom hela innehållet är offentligt ändå och det lägger till kryptering över huvudet och latens. Eftersom du inte litar på en angripares offentliga nyckel är även http-trafik säker från MitM-attacker. apt varnar dig och misslyckas med att installera paketen när en angripare injicerar manipulerade paket.

EDIT: Som nämnts i kommentarerna är det verkligen säkrare att använda TLS -förvar. Forskning visar att användning av apt på okrypterade förråd verkligen kan utgöra en säkerhetsrisk eftersom HTTP-transporten är sårbar för återuppspelningsattacker.

Kommentarer

• Nej, de flesta speglar stöder inte https. Helt enkelt för att det ’ inte är mycket meningsfullt att kryptera denna typ av trafik. Paket verifieras ändå och informationen är offentlig.
• Jag kan tänka på några anledningar till att jag fortfarande föredrar att ladda ner över TLS: 1) Jag kanske bryr mig om min integritet när jag installerar paket och 2) där kan vara fel i paketets signaturkontrollkod, som en MITM kan utnyttja.
• @JackO ’ Connor, medan den första invändningen om sekretess är förståelig, den andra är som att säga att jag gillar webbplatser för att signera deras innehåll med PGP-nycklar eftersom det kan finnas fel i TLS-kod. Både PGP och TLS skapar förtroende; du behöver inte ’ båda för det.
• @Marco ditt svar är felaktigt; många forskningsdokument har visat att både APT- och YUM-förvar är sårbara för omspelningsattacker när förvaret nås via HTTP, även med GPG-signaturer. Förvar ska endast nås via TLS, 100% av tiden.
• Här är det papper som @Joe Damato hänvisar till – se även hans svara här

Din antagandet är fel: du kan använda HTTPS-nedladdningar. Du måste bara hitta en spegel som stöder den och placera dess URL i din källlista. Du måste installera paketet apt-transport-https .

Debian gör inte HTTPS nedladdningar enkelt eftersom det är mycket liten fördel. Debians paketdistribution innehåller redan en mekanism för att verifiera paket: alla paket är signerade med Gpg . Om en aktiv man-i-mitten omdirigerar din trafik till en server med skadade paket, kommer korruptionen att upptäckas eftersom GPG-signaturerna inte är giltiga. Att använda GPG snarare än HTTPS har fördelen att det skyddar mot fler hot: inte bara mot aktiv man-i-mitten på slutanvändaranslutningen utan också mot en skurk eller infekterad spegel eller andra problem var som helst i paketdistributionskedjan.

HTTPS ger en liten integritetsfördel genom att det döljer paketen som du laddar ner. En passiv observatör kan emellertid fortfarande upptäcka trafik mellan din dator och en paketserver så att de vet att du laddar ner Debian-paket. De kan också få en bra uppfattning om vilka paket du laddar ner från filstorlekarna.

Den enda platsen där HTTPS skulle hjälpa är att starta tillförlitlighet, för att få en känd giltig installationsbild. Debian gör inte ” verkar inte ge det: det finns kontrollsummar för installationsmedia , men bara via HTTP.

Kommentarer

• Det finns HTTPS-version av installationsmediet: cdimage.debian.org/debian -cd
• Mycket liten fördel? Vad sägs om justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke Ett specifikt fel som är lättare att utnyttja med HTTP än med HTTPS räknas en mycket liten fördel, ja. Det ’ är inte som om HTTP hade en större attackyta än HTTPS: i själva verket har HTTPS i sig en större attackyta eftersom den involverar mer kod. Så det är ’ inte ens en nettofördel alls: det ’ är en avvägning mellan två marginella risker.

Nyligen kom jag över frågan med mitt företags apt-arkiv. Problemet var att om vi använder standard http transport någon annan kan få paketet enkelt. Eftersom företaget förpackar sin egen programvara och inte vill dela den med alla blir http transport ett problem. Inte en tragedi utan ett problem. Det finns några sätt att begränsa tillgången till paketet – brandvägg, begränsar åtkomst på webbservernivå, använder ssh som transport. Ganska lätt att konsumera läsning om detta ämne kan hittas här: Begränsa åtkomsten till ditt privata Debian-arkiv / a>

I vårt fall bestämde vi oss för att använda https transport + klientcertifikatautentisering. Kortfattat är allt som krävs:

1. Förbered självsignerade certifikat, klient och server (med easy-rsa);

2. Konfigurera webserver som fronter förvaret så att det endast accepterar https; Vid 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. Sätt klientcertifikat, klientnyckel och ca-certifikat till / etc / apt / ssl och, i fall med Ubuntu, lägg till 00https-fil till /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"; };

Tänk på att om du använder självsignerat certifikat är det viktigt att stänga av värdverifiering: Verify-Host "false"; Om du inte gör det gör du ”Jag kommer att få ett fel: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

Och nu går det, det finns ingen mer obehörig åtkomst till förvaret. Så det här är ganska användbart och kraftfullt.

Kommentarer

• Tack för det fantastiska svaret. Men jag tror att huvudfrågan fortfarande finns kvar. HTTPS borde verkligen bli standardprotokollet för överföringar via webben och i synnerhet debianpaket. Argumentet borde inte vara varför HTTPS, det borde vara varför inte?
• @aalizadeh, jag håller med dig, det finns omkostnader när du använder https, men det finns ingen massiv kostnad. Jag tror att den främsta anledningen till att https inte är en standardtransport är att vissa organisationer uttryckligen förbjuder krypterad trafik (eftersom de vill kunna sticka näsan i vad de anställda gör via Internet), vilket innebär att förvar måste stödja både http- och https-transporter. Det kan finnas andra överväganden
• Använda » Verify-Host ” false ”; « är fel, även med självsignerade certifikat. Du måste göra dina klienter medvetna om (rätt) servercertifikat istället.
• Faktiskt, men här var mina klienter bara interna system. Så istället för att skapa all rätt pki-infrastruktur klipper jag hörnet. Och ja, senare avgjordes pki ordentligt och Verifier-värd falsk; avlägsnades. Och ja, poängen är giltig.
• med ubuntu xenial hämtas apt-paketen som obehöriga användare _apt, kan du uppdatera den här tråden med information om hur du hanterade eller löste problem med filtillstånd.

Observera att på grund av sårbarheter som

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

… vilket kringgår InRelease-signering, det är förmodligen en bra idé att konfigurera HTTPS ändå.

Och detta är inte ett enda exempel – många andra uppdateringssystem som är standard för HTTP har också haft en historia av signaturverifieringsfel.

Säkerhetskritiska uppdateringsmekanismer bör använda både HTTPS och signaturverifiering för att vara robust. Var och en mildrar varandras fel.

Kommentarer

• Och nu den här också: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. InRelease-signering räcker inte . ” Men att flytta alla speglar till HTTPS tar tid och samordning! ”. Ja. Börja nu. Detta kommer inte att vara det sista InRelease-misslyckandet.
• Här ’ är ett annat exempel från ett annat ekosystem – Alpine. Dess pakethanteringssystem ’ använder inte HTTPS som standard och förlitar sig enbart på signering för att verifiera paketets integritet …och den verifieringen hade ett fjärrutnyttjbart fel i september 2018: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine bör börja flyttar nu till att använda HTTPS som standard.
• (Fullständig information: min egen kärnan, men det ’ är den enda referensen jag känner till av), här är en lista över alla fel på verifieringsfel på klientsidan som jag ’ känner till. Listan är inte trivial i storlek och växer regelbundet. Lägger till välkommen. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004