Miksi Debian apt -työkalulle ei ole https-kuljetusta?

On. Sinun on asennettava paketti apt-transport-https . Sitten voit käyttää rivejä, kuten

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

sources.list -tiedostossasi. Mutta yleensä se ei ole välttämätöntä, koska koko sisältö on joka tapauksessa julkista ja lisää salauksen yleiskustannuksia ja viivettä. Koska et luota hyökkääjien julkiseen avaimeen, jopa http-liikenne on suojattu MitM-hyökkäyksiltä. apt varoittaa sinua ja epäonnistuu asentamasta paketteja, kun hyökkääjä ruiskuttaa manipuloituja paketteja.

MUOKKAA: Kuten kommenteissa mainittiin, on todellakin turvallisempaa käyttää TLS -tietovarasto. Tutkimukset osoittavat , että apt: n käyttäminen salaamattomissa arkistoissa voi todellakin aiheuttaa turvallisuusriskin, koska HTTP-kuljetus on altis toistohyökkäyksille.

Kommentit

• Ei, useimmat peilit eivät tue https: ää. Yksinkertaisesti siksi, että ’ ei ole järkevää salata tällaista liikennettä. Paketteja tarkistetaan joka tapauksessa ja tiedot ovat julkisia.
• Voin ajatella muutamia syitä, jotka voisin silti haluta ladata TLS: n kautta: 1) Minusta saattaa välittää yksityisyyteni paketteja asennettaessa ja 2) siellä voivat olla virheitä paketin allekirjoituksen tarkistuskoodissa, jota MITM voisi hyödyntää.
• @JackO ’ Connor, kun taas ensimmäinen yksityisyyttä koskeva väite on ymmärrettävää, toinen on kuin sanoisin, että pidän verkkosivustoista allekirjoittamaan sisällönsä PGP-avaimilla, koska TLS-koodissa saattaa olla vikoja. Sekä PGP että TLS luovat luottamuksen; et tarvitse ’ sitä varten molempia.
• @Marco vastauksesi on väärä; Lukuisat tutkimusartikkelit ovat osoittaneet, että sekä APT- että YUM-arkistot ovat alttiita toistohyökkäyksille, kun arkistoon pääsee HTTP: n kautta, jopa GPG-allekirjoituksilla. Varastoihin tulisi päästä vain TLS: n kautta, 100% ajasta.
• Tässä on artikkeli, johon @Joe Damato viittaa – katso myös hänen vastaa tänne

oletus on väärä: voit käyttää HTTPS-latauksia. Sinun tarvitsee vain löytää peili, joka tukee sitä, ja laittaa sen URL-osoite lähdeluetteloon. Sinun on asennettava paketti apt-transport-https .

Debian ei tee HTTPS: ää lataaminen on helppoa, koska siitä on hyvin vähän hyötyä. Debianin pakettijakelu sisältää jo mekanismin pakettien tarkistamiseksi: kaikki paketit on allekirjoitettu Gpg -ominaisuudella. Jos aktiivinen välimies ohjaa liikenteen palvelimeen, jossa on vioittuneita paketteja, vioittuminen havaitaan, koska GPG-allekirjoitukset eivät ole kelvollisia. GPG: n käyttäminen HTTPS: n sijasta on etuna, että se suojaa uusilta uhilta: ei vain aktiivista välimies-käyttäjää vastaan loppukäyttäjäyhteydessä, vaan myös roistoja tai tartunnan saaneita peilejä tai muita ongelmia vastaan missä tahansa paketin jakeluketjussa.

HTTPS tarjoaa hieman yksityisyyden edun passiivinen tarkkailija voi silti havaita liikenteen tietokoneen ja pakettipalvelimen välillä, jotta he tietäisivät, että lataat Debian-paketteja. He voivat myös saada hyvän käsityksen siitä, mitä paketteja lataat tiedostokokoista.

Ainoa paikka, josta HTTPS auttaisi, on luottamuksen käynnistäminen uudelleen, jotta saat tunnetun kelvollisen asennuskuvan. Debian ei ” Näyttää siltä, että: -asennusvälineiden tarkistussummat ovat olemassa, mutta vain HTTP: n kautta.

kommentit

• Asennusvälineestä on olemassa HTTPS-versio: cdimage.debian.org/debian -cd
• Hyvin vähän hyötyä? Entä justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke Yksi tietty vika, joka on helpompi hyödyntää HTTP: llä kuin HTTPS: llä, on hyvin pieni hyöty, kyllä. Se ’ ei ole kuin HTTP: llä olisi suurempi hyökkäyspinta kuin HTTPS: Itse asiassa HTTPS: llä itsessään on suurempi hyökkäyspinta, koska siihen liittyy enemmän koodia. Joten se ei ole ’ edes nettoetu: se ’ on kompromissi kahden marginaaliriskin välillä.

Juuri äskettäin tulin kysymykseen yritykseni apt-arkistosta. Ongelmana oli, että jos käytämme tavallista http kuljetus kuka tahansa muu saa paketin helposti. Koska yritys pakkaa omia ohjelmistojaan eikä halua jakaa niitä kaikkien kanssa, http-liikenteestä tulee ongelma. Ei tragedia vaan ongelma. On olemassa pari tapaa rajoittaa paketin käyttöä – palomuuri, pääsyn rajoittaminen verkkopalvelintasolla, ssh: n käyttäminen kuljetuksena. Aiheeseen liittyvä käsittely on melko helppoa: Rajoita pääsy yksityiseen Debian-tietovarastoon

Meidän tapauksessamme päätimme käyttää https transport + client -sertifikaatin todennusta. Lyhyesti sanottuna, kaikki mitä tarvitaan:

1. Valmista itse allekirjoitetut varmenteet, asiakas ja palvelin (käyttäen easy-rsa: ta);

2. Määritä verkkopalvelin, jonka rintaman arkisto hyväksyy vain https: n; Nginxin tapauksessa se voi näyttää tältä:

   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. Laita asiakassertifikaatti, asiakasavain ja ca-varmenne tiedostoon / etc / apt / ssl ja lisää Ubuntun tapauksessa 00https-tiedosto tiedostoon /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"; };

Muista, että jos käytät itse allekirjoittamaa sertifikaattia, on tärkeää poistaa isäntäkohtainen vahvistus käytöstä: Verify-Host "false"; Jos et tee tätä, sinun on ”Löydän virheen: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

Ja tässä ei ole enää luvatonta pääsyä arkistoon. Joten tämä on varsin hyödyllinen ja tehokas asia.

Kommentit

• Kiitos upeasta vastauksesta. Mutta mielestäni pääkysymys on edelleen olemassa. HTTPS: stä tulisi todella tulla oletusprotokolla erityisesti web- ja debian-pakettien välityksellä. Väitteen ei pitäisi olla miksi HTTPS, sen pitäisi olla miksi ei?
• @aalizadeh, olen kanssasi samaa mieltä, https: ää käytettäessä on yleiskustannuksia, mutta massiivisia yleiskustannuksia ei ole. Mielestäni tärkein syy siihen, miksi https ei ole oletuskuljetus, on se, että jotkut organisaatiot nimenomaisesti kieltävät kaiken salatun liikenteen (koska he haluavat pystyä työntämään nenänsä siihen, mitä työntekijät tekevät Internetin kautta), mikä tarkoittaa, että arkistojen on tuettava sekä http- että https-siirrot. Saattaa olla muitakin näkökohtia
• » Verify-Host -palvelimen käyttäminen ” false ”; « on väärä, jopa itse allekirjoitettujen varmenteiden kanssa. Sinun on sen sijaan ilmoitettava asiakkaillesi (oikea) palvelinsertifikaatti.
• Todellakin, mutta tässä asiakkaani olivat vain sisäisiä järjestelmiä. Joten kaiken oikean pki-infrastruktuurin luomisen sijasta leikkaan kulman. Ja kyllä, myöhemmin pki selvitettiin oikein ja Verify-Host väärä; oli poistettu. Ja kyllä, kohta on kelvollinen.
• ubuntu xenialilla apt-paketit haetaan etuoikeutetuiksi käyttäjiksi _apt, voitko päivittää tämän ketjun yksityiskohdilla siitä, miten hallitsit tai ratkaisit tiedoston käyttöoikeusongelmat.

Huomaa, että haavoittuvuuksien takia, kuten

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

… joka kiertää InRelease-allekirjoituksen, on todennäköisesti hyvä määrittää HTTPS joka tapauksessa.

Ja tämä ei ole ainoa esimerkki – monilla muilla HTTP-oletusarvoisilla päivitysjärjestelmillä on myös ollut allekirjoituksen vahvistusvirheitä.

Suojauskriittisten päivitysmekanismien tulisi käyttää sekä HTTPS: ää että allekirjoituksen vahvistus on vankka. Kukin lievittää toisten epäonnistumista.

Kommentit

• Ja nyt myös tämä: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. InRelease-allekirjoitus ei riitä . ” Mutta kaikkien peilien siirtäminen HTTPS: ään vie aikaa ja koordinointia! ”. Joo. Aloita nyt. Tämä ei ole viimeinen InRelease-epäonnistuminen.
• Tässä ’ on toinen esimerkki toisesta ekosysteemistä – Alpine. Sen paketinhallintajärjestelmä ei käytä ’ oletusarvoisesti HTTPS: ää ja luottaa vain allekirjoittamiseen paketin eheyden tarkistamiseksi …ja kyseisessä vahvistuksessa oli etänä hyödynnettävä vika syyskuussa 2018: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine pitäisi alkaa siirretään nyt oletusarvoisesti käyttämään HTTPS: ää.
• (Täysi paljastus: oma pääsisältöni, mutta se ’ on ainoa tiedettävä viite /), tässä on luettelo kaikista asiakaspuolen allekirjoittamisen vahvistuksen epäonnistumisista, joista ’ tiedän. Luettelo ei ole triviaalikokoinen ja kasvaa säännöllisesti. Lisää tervetuloa. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004