Waarom is er geen https-transport voor het hulpprogramma Debian apt?

Er is. U moet het pakket apt-transport-https installeren. Dan kun je regels gebruiken als

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

in je sources.list bestand. Maar meestal is dat niet nodig, aangezien de volledige inhoud sowieso openbaar is en het zorgt voor extra overhead en latentie voor versleuteling. Aangezien je de openbare sleutel van een aanvaller niet vertrouwt, is zelfs http-verkeer veilig voor MitM-aanvallen. apt zal u waarschuwen en de pakketten niet installeren wanneer een aanvaller gemanipuleerde pakketten injecteert.

BEWERK: Zoals vermeld in de opmerkingen is het inderdaad veiliger om de TLS -opslagplaats. Onderzoek toont dat het gebruik van apt op niet-versleutelde opslagplaatsen inderdaad een beveiligingsrisico kan vormen aangezien het HTTP-transport kwetsbaar is voor replay-aanvallen.

Reacties

• Nee, de meeste mirrors ondersteunen geen https. Simpelweg omdat het ‘ niet veel zin heeft om dit soort verkeer te versleutelen. Pakketten worden hoe dan ook geverifieerd en de informatie is openbaar.
• Ik kan een paar redenen bedenken waarom ik misschien toch liever download via TLS: 1) Ik geef misschien om mijn privacy bij het installeren van pakketten, en 2) daar kunnen fouten zijn in de code voor het controleren van de handtekening van het pakket, waarvan een MITM misbruik zou kunnen maken.
• @JackO ‘ Connor, terwijl het eerste bezwaar over privacy begrijpelijk is, het tweede is hetzelfde als zeggen dat ik graag websites wil om hun inhoud te ondertekenen met PGP-sleutels, omdat er mogelijk bugs in TLS-code zitten. Zowel PGP als TLS zorgen voor vertrouwen; je hebt geen ‘ beide daarvoor nodig.
• @Marco je antwoord is onjuist; talrijke research papers hebben aangetoond dat zowel APT- als YUM-repositories kwetsbaar zijn voor replay-aanvallen wanneer de repository wordt benaderd via HTTP, zelfs met GPG-handtekeningen. Repositories mogen alleen worden benaderd via TLS, 100% van de tijd.
• Hier is het artikel waarnaar @Joe Damato verwijst – zie ook zijn antwoord hier

Uw aanname is onjuist: u kunt HTTPS-downloads gebruiken. U hoeft alleen maar een mirror te vinden die dit ondersteunt, en de URL ervan in uw lijst met bronnen te plaatsen. U “zult het pakket apt-transport-https moeten installeren.

Debian maakt geen HTTPS gemakkelijk te downloaden omdat er weinig voordeel is. De pakketdistributie van Debian bevat al een mechanisme om pakketten te verifiëren: alle pakketten zijn ondertekend met Gpg . Als een actieve man-in-the-middle uw verkeer omleidt naar een server met beschadigde pakketten, wordt de beschadiging gedetecteerd omdat de GPG-handtekeningen niet geldig zijn. Het gebruik van GPG in plaats van HTTPS heeft het voordeel dat het beschermt tegen meer bedreigingen: niet alleen tegen actieve man-in-the-middle op de eindgebruikerverbinding, maar ook tegen een malafide of geïnfecteerde mirror of andere problemen overal in de pakketdistributieketen.

HTTPS biedt een klein privacyvoordeel in die zin dat het de pakketten die u downloadt verdoezelt. Een passieve waarnemer kan echter nog steeds verkeer detecteren tussen uw computer en een pakketserver, zodat ze weten dat u Debian-pakketten aan het downloaden bent. Ze kunnen ook een goed idee krijgen van welke pakketten u downloadt uit de bestandsgroottes.

De enige plaats waar HTTPS zou helpen, is voor bootstrapping-vertrouwen, om een bekende geldige installatie-image te krijgen. Debian doet dat niet. Het lijkt erop te voorzien dat: er checksums zijn van installatiemedia , maar alleen via HTTP.

Opmerkingen

• Er is een HTTPS-versie van installatiemedia: cdimage.debian.org/debian -cd
• Zeer weinig voordeel? Hoe zit het met justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke Een specifieke bug is gemakkelijker te exploiteren met HTTP dan met HTTPS telt een klein voordeel, ja. Het ‘ is niet alsof HTTP een groter aanvalsoppervlak had dan HTTPS: in feite heeft HTTPS zelf een groter aanvalsoppervlak aangezien het meer code omvat. Het is dus niet ‘ zelfs helemaal geen netto voordeel: het ‘ is een afweging tussen twee marginale risicos.

Onlangs kwam ik het probleem tegen met de apt-opslagplaats van mijn bedrijf. Het probleem was dat als we standaard http transport door iemand anders kan gemakkelijk een pakket krijgen. Aangezien het bedrijf zijn eigen propriëtaire software verpakt en deze niet met iedereen wil delen, wordt http-transport een probleem. Geen tragedie maar een probleem. Er zijn een aantal manieren om de toegang tot het pakket te beperken – firewalling, toegang beperken op webserver-niveau, ssh gebruiken als transport. Vrij gemakkelijk leesbare informatie over dit onderwerp kan hier worden gevonden: Beperk de toegang tot uw privé-Debian-repository

In ons geval hebben we besloten om https transport + clientcertificaatverificatie te gebruiken. Kort gezegd, alles wat nodig is, is:

1. Bereid zelfondertekende certificaten, client en server (met easy-rsa);

2. Configureer de webserver welke fronts-repository alleen https accepteert; In het geval van nginx kan het er als volgt uitzien:

   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. Zet clientcertificaat, clientsleutel en ca-certificaat in / etc / apt / ssl en, in het geval van Ubuntu, voeg 00https-bestand toe aan /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"; };

Houd er rekening mee dat als u een zelfondertekend certificaat gebruikt, het belangrijk is om hostverificatie uit te schakelen: Verify-Host "false"; Als u dit niet doet, “Ik zal een fout opvangen: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

En hier gaan we, er is geen ongeautoriseerde toegang meer tot de repository. Dit is dus een heel nuttig en krachtig iets.

Reacties

• Bedankt voor het geweldige antwoord. Maar ik denk dat het belangrijkste probleem er nog steeds is. HTTPS zou echt het standaardprotocol moeten worden voor overdrachten via het web en in het bijzonder voor Debian-pakketten. Het argument zou niet moeten zijn waarom HTTPS, het zou moeten zijn waarom niet?
• @aalizadeh, ik ben het met je eens, er is overhead bij het gebruik van https, maar er is geen enorme overhead. Ik denk dat de belangrijkste reden waarom https geen standaardtransport is, is dat sommige organisaties expliciet gecodeerd verkeer verbieden (omdat ze hun neus willen kunnen steken in wat de werknemers via internet doen), wat betekent dat repositories moeten ondersteunen zowel http- als https-transporten. Mogelijk zijn er andere overwegingen
• Gebruik van » Verify-Host ” false “; « is fout, zelfs met zelfondertekende certificaten. Je moet je klanten in plaats daarvan bewust maken van het (juiste) servercertificaat.
• Inderdaad, maar hier waren mijn klanten alleen interne systemen. Dus in plaats van alle goede pki-infrastructuur te creëren, sneed ik de hoek om. En ja, later werd pki correct afgehandeld en Verify-Host false; was verwijderd. En ja, het punt is geldig.
• met ubuntu xenial worden de apt-pakketten opgehaald als onbevoegde gebruiker _apt, kun je deze thread bijwerken met details over hoe je de problemen met bestandstoestemmingen hebt beheerd of opgelost.

Merk op dat vanwege kwetsbaarheden zoals

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

… wat ondertekening van InRelease omzeilt, is het waarschijnlijk een goed idee om HTTPS toch te configureren.

En dit is geen enkel voorbeeld: veel andere updatesystemen die standaard op HTTP zijn ingesteld, hebben ook een geschiedenis van mislukte handtekeningverificatie gehad.

Beveiligingskritieke updatemechanismen moeten zowel HTTPS als handtekeningverificatie robuust zijn. Elk verzacht het falen van de ander.

Reacties

• En nu ook deze: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. InRelease-ondertekening is niet voldoende . ” Maar het verplaatsen van alle mirrors naar HTTPS kost tijd en coördinatie! “. Ja. Begin nu. Dit zal niet de laatste InRelease-fout zijn.
• Hier is ‘ een ander voorbeeld, uit een ander ecosysteem – Alpine. Het pakketbeheersysteem gebruikt standaard geen ‘ HTTPS en vertrouwt uitsluitend op ondertekening om de integriteit van het pakket te verifiëren …en die verificatie had een op afstand exploiteerbare bug in september 2018: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine zou moeten starten nu verplaatsen naar standaard HTTPS gebruiken.
• (Full disclosure: mijn eigen kern, maar het is ‘ de enige referentie die ik ken van), hier is een lijst van alle fouten van client-side ondertekeningsverificatie fouten waarvan ik ‘ op de hoogte ben. De lijst is niet triviaal van formaat en groeit regelmatig. Voegt welkom toe. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004

Voor de” anonimiteit “use-case is er ook apt-transport-tor waarmee je URIs zoals tor+http:// in sources.list bestanden. Dit is een veel betere anonimiteitsbescherming dan simpelweg de verbinding met je mirror te versleutelen.

Een lokale waarnemer weet bijvoorbeeld nog steeds dat je software bijwerkt of installeert, zelfs met HTTPS, en kan waarschijnlijk behoorlijk gissen aan welke van die u “doet (en mogelijk zelfs welke pakketten, op basis van grootte).

Debian biedt APT-repositories aan via Tor” Onion-services “zodat u end-to-end-codering kunt krijgen (vergelijkbaar naar TLS) zonder het domeinnaamsysteem te hoeven vertrouwen. Zie ui.debian.org voor alle Debian-services die op deze manier beschikbaar zijn. De belangrijkste FTP-opslagplaats van Debian bevindt zich op vwakviie2ienjx6t.onion