Warum gibt es keinen https-Transport für das debian apt-Tool?

Bei aller Paranoia, die mit NSA-Enthüllungen und allem einhergeht, frage ich mich, warum der Installationsmechanismus von Debian-Paketen HTTPS für den Transport nicht unterstützt, geschweige denn standardmäßig verwendet.

Ich weiß, dass Debian-Pakete eine Art Signaturüberprüfung mit GPG haben, aber ich denke immer noch nicht, dass die Verwendung von HTTPS-Transport anstelle von HTTP zu schwierig wäre, wenn man bedenkt, wie wichtig dies in Bezug auf die Sicherheit ist.

Bearbeiten: Ich möchte mich hauptsächlich vor MitM-Angriffen schützen (einschließlich Traffic Sniffing), nicht vor Debian Mirror-Administratoren. HTTP-Repositorys stellen das gesamte System-Setup auf den Tisch, wenn jemand meinen Datenverkehr auf Debian-Mirrors überwacht.

Es gibt. Sie müssen das Paket installieren apt-transport-https. Dann können Sie Zeilen wie verwenden

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

in deiner sources.listAkte. In der Regel ist dies jedoch nicht erforderlich, da der gesamte Inhalt ohnehin öffentlich ist und der Aufwand für die Verschlüsselung und die Latenz erhöht wird. Da Sie einem öffentlichen Schlüssel eines Angreifers nicht vertrauen, ist auch der HTTP-Verkehr vor MitM-Angriffen sicher. aptwarnt Sie und kann die Pakete nicht installieren, wenn ein Angreifer manipulierte Pakete einschleust.

EDIT: Wie in den Kommentaren erwähnt, ist es in der Tat sicherer, das TLS- Repository zu verwenden. Untersuchungen haben ergeben, dass die Verwendung von apt für unverschlüsselte Repositorys tatsächlich ein Sicherheitsrisiko darstellen kann, da der HTTP-Transport für Wiederholungsangriffe anfällig ist.

Ihre Annahme ist falsch: Sie können HTTPS-Downloads verwenden. Sie müssen nur einen Spiegel finden, der dies unterstützt, und dessen URL in Ihre Liste der Quellen aufnehmen. Sie müssen das apt-transport-httpsPaket installieren .

Debian macht das Herunterladen von HTTPS nicht einfach, da es sehr wenig Vorteile bietet. Die Debian-Paketverteilung enthält bereits einen Mechanismus zur Überprüfung von Paketen: Alle Pakete sind mit Gpg signiert . Wenn eine aktive Person in der Mitte Ihren Datenverkehr auf einen Server mit beschädigten Paketen umleitet, wird die Beschädigung erkannt, da die GPG-Signaturen nicht gültig sind. Die Verwendung von GPG anstelle von HTTPS bietet den Vorteil, dass es vor mehr Bedrohungen schützt: nicht nur vor aktivem Man-in-the-Middle-Zugriff auf die Endbenutzerverbindung, sondern auch vor einem betrügerischen oder infizierten Spiegel oder anderen Problemen in der gesamten Paketverteilungskette .

HTTPS bietet einen leichten Datenschutzvorteil, da es die heruntergeladenen Pakete verdeckt. Ein passiver Beobachter kann jedoch weiterhin Datenverkehr zwischen Ihrem Computer und einem Paketserver erkennen, sodass er weiß, dass Sie Debian-Pakete herunterladen. Sie könnten auch anhand der Dateigrößen eine gute Vorstellung davon bekommen, welche Pakete Sie herunterladen.

Der einzige Ort, an dem HTTPS helfen würde, ist das Bootstrapping des Vertrauens, um ein bekanntermaßen gültiges Installationsimage zu erhalten. Debian scheint nicht zu bieten , dass: es gibt Prüfsummen der Installationsmedien , sondern nur über HTTP.

Erst kürzlich bin ich auf das Problem mit dem passenden Repository meines Unternehmens gestoßen. Das Problem war, dass, wenn wir Standard-HTTP-Transport verwenden, jeder andere das Paket leicht bekommen kann. Da das Unternehmen seine eigene proprietäre Software verpackt und diese nicht für alle freigeben möchte, wird der http-Transport zu einem Problem. Keine Tragödie, sondern ein Problem. Es gibt verschiedene Möglichkeiten, den Zugriff auf Pakete zu beschränken: Firewalling, Beschränkung des Zugriffs auf Webserverebene und Verwendung von ssh als Transport. Das Lesen zu diesem Thema ist hier ganz einfach zu konsumieren: Beschränken Sie den Zugriff auf Ihr privates Debian-Repository

In unserem Fall haben wir uns für die Verwendung der Zertifikatsauthentifizierung https transport + client entschieden. Kurz gesagt, alles was es braucht ist:

1. Bereiten Sie selbstsignierte Zertifikate, Client und Server vor (mit easy-rsa).

2. Konfigurieren Sie den Webserver, der das Front-Repository so konfiguriert, dass nur https akzeptiert wird. Im Falle von Nginx könnte es so aussehen:

   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. Legen Sie das Client-Zertifikat, den Client-Schlüssel und das CA-Zertifikat in / etc / apt / ssl ab und fügen Sie im Falle von Ubuntu die Datei 00https in /etc/apt/apt.conf.d ein:

   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"; };

Beachten Sie, dass es wichtig ist, die Host-Überprüfung zu deaktivieren, wenn Sie ein selbstsigniertes Zertifikat verwenden: Verify-Host "false";Wenn Sie dies nicht tun, wird ein Fehler angezeigt: SSL: certificate subject name (blah-blah-blah) does not match target host name 'example.com'

Und los geht's, es gibt keinen unbefugten Zugriff mehr auf das Repository. Das ist also eine nützliche und mächtige Sache.

Beachten Sie, dass wegen Schwachstellen wie

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

... die InRelease-Signierung umgeht, ist es wahrscheinlich eine gute Idee, HTTPS trotzdem zu konfigurieren.

Für den Anwendungsfall "Anonymität" gibt es auch einen apt-transport-tor, mit dem Sie URIs wie tor+http://in sources.list-Dateien einfügen können. Dies ist ein weitaus besserer Anonymitätsschutz als das einfache Verschlüsseln der Verbindung zu Ihrem Spiegel.

Ein lokaler Beobachter weiß beispielsweise immer noch, dass Sie Software auch mit HTTPS aktualisieren oder installieren, und kann wahrscheinlich ein paar Vermutungen anstellen, welche davon Sie ausführen (und möglicherweise sogar welche Pakete, basierend auf der Größe).

Debian stellt APT-Repositorys über "Onion-Dienste" von Tor zur Verfügung, so dass Sie eine End-to-End-Verschlüsselung (ähnlich wie TLS) erhalten können, ohne dem Domain-Name-System vertrauen zu müssen. Unter onion.debian.org finden Sie alle Debian-Dienste, die auf diese Weise verfügbar sind. Das Haupt-Debian-FTP-Repository befindet sich untervwakviie2ienjx6t.onion