De ce nu există un transport https pentru instrumentul debian apt?

Există. Trebuie să instalați pachetul apt-transport-https . Apoi, puteți utiliza linii precum

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

în fișierul dvs. sources.list. Dar, de obicei, acest lucru nu este necesar, întrucât întregul conținut este public oricum și adaugă criptare generală și latență. Deoarece nu aveți încredere într-o cheie publică a atacatorilor, chiar și traficul http este sigur de atacurile MitM. apt vă va avertiza și nu va instala pachetele atunci când un atacator injectează pachete manipulate.

EDITARE: După cum sa menționat în comentarii, este într-adevăr mai sigur să utilizați depozit TLS . Cercetările arată că utilizarea apt pe depozite necriptate poate reprezenta într-adevăr un risc de securitate, deoarece transportul HTTP este vulnerabil la atacurile de reluare.

Comentarii

• Nu, majoritatea oglinzilor nu acceptă https. Pur și simplu pentru că nu are ‘ prea mult sens să criptezi acest tip de trafic. Pachetele sunt verificate oricum, iar informațiile sunt publice.
• Mă pot gândi la câteva motive pentru care aș putea prefera să descarc peste TLS: 1) S-ar putea să îmi pese de confidențialitatea mea la instalarea pachetelor și 2) acolo ar putea fi erori în codul de verificare a semnăturii pachetului, pe care un MITM l-ar putea exploata.
• @JackO ‘ Connor, în timp ce prima obiecție privind confidențialitatea este de înțeles, a doua este ca și cum ai spune că îmi place site-urile web să semneze conținutul lor cu chei PGP, deoarece ar putea exista erori în codul TLS. Atât PGP cât și TLS stabilesc încredere; ‘ nu aveți nevoie de ambele pentru asta.
• @Marco răspunsul dvs. este incorect; numeroase lucrări de cercetare au arătat că atât depozitele APT, cât și cele YUM sunt vulnerabile la reluarea atacurilor atunci când depozitul este accesat prin HTTP, chiar și cu semnături GPG. Repozitoarele ar trebui să fie accesate numai prin TLS, 100% din timp.
• Iată lucrarea la care face referire Joe Joe Damato – vezi și răspunde aici

presupunerea este greșită: puteți utiliza descărcări HTTPS. Trebuie doar să găsiți o oglindă care să o susțină și să puneți adresa URL în lista de surse. Va trebui să instalați pachetul apt-transport-https .

Debian nu face HTTPS se descarcă ușor, deoarece există foarte puține beneficii. Distribuirea pachetelor Debian include deja un mecanism de verificare a pachetelor: toate pachetele sunt semnate cu Gpg . Dacă un om activ în mijloc vă redirecționează traficul către un server cu pachete corupte, corupția va fi detectată deoarece semnăturile GPG nu vor fi valabile. Utilizarea GPG mai degrabă decât HTTPS are avantajul că protejează împotriva mai multor amenințări: nu doar împotriva omului activ în conexiunea utilizatorului final, ci și împotriva unei oglinzi necinstite sau infectate sau a altor probleme oriunde în lanțul de distribuție a pachetelor.

HTTPS oferă un ușor avantaj de confidențialitate prin faptul că ascunde pachetele pe care le descărcați. Cu toate acestea, un observator pasiv poate detecta totuși traficul între computerul dvs. și un server de pachete, așa că ar ști că descărcați pachetele Debian. De asemenea, ar putea avea o idee bună despre pachetele pe care le descărcați din dimensiunile fișierelor.

Singurul loc în care HTTPS ar ajuta este bootstrapping trust, pentru a obține o imagine de instalare validă. Debian nu ” Se pare că prevede că: există sume de verificare ale suport de instalare , dar numai prin HTTP.

Comentarii

• Există versiunea HTTPS a mediului de instalare: cdimage.debian.org/debian -cd
• Foarte puțin beneficiu? Ce zici de justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke O eroare specifică care este mai ușor de exploatat cu HTTP decât cu HTTPS are un avantaj foarte mic, da. ‘ nu este ca și cum HTTP ar avea o suprafață de atac mai mare decât HTTPS: de fapt, HTTPS în sine are o suprafață de atac mai mare, deoarece implică mai mult cod. Deci, nu este ‘ nici măcar un beneficiu net: este ‘ un compromis între două riscuri marginale.

Recent am aflat problema cu depozitul apt al companiei mele. Problema a fost că, dacă folosim http standard transport oricine altcineva poate obține pachetul cu ușurință. Deoarece Compania își împachetează propriul software proprietar și nu dorește să îl împărtășească cu toată lumea, transportul http devine o problemă. Nu o tragedie, ci o problemă. Există câteva modalități de a limita accesul la pachet – firewalling, restricționarea accesului la nivel de server web, folosind ssh ca mijloc de transport. Destul de ușor de citit pe acest subiect poate fi găsit aici: Restricționarea accesului la depozitul dvs. privat Debian

În cazul nostru, am decis să folosim autentificarea https transport + certificat client. Pe scurt, nu trebuie decât:

1. Pregătiți certificate autosemnate, client și server (folosind easy-rsa);

2. Configurați serverul web care depozitează fronturi pentru a accepta numai https; În cazul nginx ar putea arăta ca:

   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. Puneți certificatul clientului, cheia clientului și certificatul ca la / etc / apt / ssl și, în cazul Ubuntu, adăugați fișierul 00https la /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"; };

Rețineți că, dacă utilizați un certificat auto-semnat, este important să dezactivați verificarea gazdei: Verify-Host "false"; Dacă nu faceți acest lucru, „Voi vedea o eroare: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

Și iată-ne, nu mai există acces neautorizat la depozit. Deci, acest lucru este destul de util și puternic.

Comentarii

• Vă mulțumim pentru răspunsul excelent. Dar cred că problema principală este încă acolo. HTTPS ar trebui să devină cu adevărat protocolul implicit pentru transferuri pe web și în special pachetele debian. Argumentul nu ar trebui să fie de ce HTTPS, ar trebui să fie de ce nu?
• @aalizadeh, sunt de acord cu dvs., există cheltuieli generale atunci când utilizați https, dar nu există cheltuieli generale masive. Cred că principalul motiv pentru care https nu este un transport implicit este acela că unele organizații interzic în mod explicit orice trafic criptat (deoarece doresc să poată să-și lipească nasul în ceea ce fac angajații prin Internet), ceea ce înseamnă că depozitele trebuie să sprijine atât transporturile http, cât și https. Poate exista și alte considerații
• Utilizarea » Verify-Host ” false „; « este greșit, chiar și cu certificate auto-semnate. În schimb, trebuie să vă informați clienții despre certificatul de server (corect).
• Într-adevăr, dar aici clienții mei erau doar sisteme interne. Deci, în loc să creez toată infrastructura pki adecvată, am tăiat colțul. Și da, mai târziu pki a fost stabilit corect și Verify-Host este fals; a fost eliminat. Și da, punctul este valid.
• cu ubuntu xenial pachetele apt sunt preluate ca _apt de utilizator neprivilegiat, puteți actualiza acest fir cu detalii despre cum ați gestionat sau ați rezolvat problemele de permisiune a fișierului.

Rețineți că din cauza vulnerabilităților precum

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

… care ocolește semnarea InRelease, probabil că este o idee bună să configurați HTTPS oricum.

Și acesta nu este un singur exemplu – multe alte sisteme de actualizare care implicit la HTTP au avut, de asemenea, un istoric al eșecurilor verificării semnăturii.

Mecanismele de actualizare critice pentru securitate ar trebui să utilizeze atât HTTPS cât și verificarea semnăturii pentru a fi robustă. Fiecare atenuează un eșec al celuilalt.

Comentarii

• Și acum și acesta: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. Semnarea InRelease nu este suficientă . ” Dar mutarea tuturor oglinzilor în HTTPS va necesita timp și coordonare! „. Da. Începe acum. Acesta nu va fi ultimul eșec InRelease.
• Iată ‘ un alt exemplu, dintr-un ecosistem diferit – Alpine. Sistemul său de gestionare a pachetelor nu ‘ nu utilizează HTTPS în mod implicit și se bazează exclusiv pe semnare pentru a verifica integritatea pachetului …și verificarea respectivă a avut un bug exploatabil de la distanță în septembrie 2018: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine ar trebui să înceapă trecând acum la utilizarea HTTPS în mod prestabilit.
• (Dezvăluire completă: esența mea, dar ‘ este singura referință pe care o cunosc of), iată o listă a tuturor eșecurilor erorilor de verificare a semnării de către client de care ‘ știu. Lista nu are importanță banală și crește în mod regulat. Adaugă bun venit. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004