Warum gibt es keinen https-Transport für das Debian Apt Tool?

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

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

in Ihrer sources.list -Datei verwenden. In der Regel ist dies jedoch nicht erforderlich, da der gesamte Inhalt ohnehin öffentlich ist und der Verschlüsselungsaufwand und die Latenz erhöht werden. Da Sie dem öffentlichen Schlüssel eines Angreifers nicht vertrauen, ist selbst der http-Verkehr vor MitM-Angriffen sicher. apt warnt Sie und kann die Pakete nicht installieren, wenn ein Angreifer manipulierte Pakete injiziert.

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

Kommentare

• Nein, die meisten Spiegel unterstützen kein https. Nur weil es ‚ nicht sinnvoll ist, diese Art von Verkehr zu verschlüsseln. Pakete werden ohnehin überprüft und die Informationen sind öffentlich.
• Ich kann mir einige Gründe vorstellen, die ich möglicherweise immer noch lieber über TLS herunterladen möchte: 1) Ich kümmere mich möglicherweise um meine Privatsphäre bei der Installation von Paketen und 2) dort Möglicherweise handelt es sich um Fehler im Code zur Überprüfung der Paketsignatur, die ein MITM ausnutzen könnte.
• @JackO ‚ Connor, während der erste Einwand zum Datenschutz verständlich ist, der zweite Ich möchte, dass Websites ihren Inhalt mit PGP-Schlüsseln signieren, da der TLS-Code möglicherweise Fehler enthält. Sowohl PGP als auch TLS schaffen Vertrauen. Sie brauchen nicht ‚ beides.
• @Marco Ihre Antwort ist falsch; Zahlreiche Forschungsarbeiten haben gezeigt, dass sowohl APT- als auch YUM-Repositorys anfällig für Wiederholungsangriffe sind, wenn auf das Repository über HTTP zugegriffen wird, selbst mit GPG-Signaturen. Auf Repositorys sollte in 100% der Fälle nur über TLS zugegriffen werden.
• Hier ist das Papier, auf das sich @Joe Damato bezieht – siehe auch sein Antwort hier

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

Debian erstellt kein HTTPS Downloads einfach, weil es sehr wenig Nutzen gibt. Die Debian-Paketverteilung enthält bereits einen Mechanismus zum Überprüfen von Paketen: Alle Pakete sind mit Gpg signiert. Wenn ein aktiver Mann 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 hat den Vorteil, dass sie vor weiteren Bedrohungen schützt: Nicht nur gegen einen aktiven Mann in der Mitte der Endbenutzerverbindung, sondern auch gegen einen betrügerischen oder infizierten Spiegel oder andere Probleme in der gesamten Paketverteilungskette.

HTTPS bietet einen leichten Datenschutzvorteil Dies verdeckt die Pakete, die Sie herunterladen. 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 eine gute Vorstellung davon bekommen, welche Pakete Sie „aus den Dateigrößen herunterladen.

Der einzige Ort, an dem HTTPS helfen würde, ist das Bootstrapping von Vertrauen, um ein bekanntermaßen gültiges Installationsimage zu erhalten. Debian nicht.“ Dies scheint nicht zu gewährleisten: Es gibt Prüfsummen für Installationsmedien , jedoch nur über HTTP.

Kommentare

• Es gibt eine HTTPS-Version des Installationsmediums: cdimage.debian.org/debian -cd
• Sehr wenig Nutzen? Was ist mit justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke Ein spezifischer Fehler, der ist Einfacher mit HTTP als mit HTTPS auszunutzen, zählt einen sehr kleinen Vorteil, ja. ‚ ist nicht so, als ob HTTP eine größere Angriffsfläche als HTTPS hätte: Tatsächlich hat HTTPS selbst eine größere Angriffsfläche, da es mehr Code enthält. ‚ ist also überhaupt kein Nettovorteil: ‚ ist ein Kompromiss zwischen zwei Grenzrisiken.

Erst kürzlich bin ich auf das Problem mit dem passenden Repository meines Unternehmens gestoßen. Das Problem war, dass wir Standard-http verwenden Jeder andere kann das Paket problemlos erhalten. Da das Unternehmen seine eigene proprietäre Software verpackt und diese nicht mit allen teilen möchte, wird der http-Transport zum Problem. Keine Tragödie, sondern ein Problem. Es gibt verschiedene Möglichkeiten, den Zugriff auf das Paket einzuschränken – Firewalling, Einschränkung des Zugriffs auf Webserverebene, Verwendung von ssh als Transportmittel. Das Lesen zu diesem Thema ist hier recht einfach zu lesen: Beschränken Sie den Zugriff auf Ihr privates Debian-Repository

In unserem Fall haben wir uns für die Authentifizierung mit https-Transport + Client-Zertifikat entschieden. Kurz gesagt, alles, was Sie benötigen, ist:

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

2. Konfigurieren Sie den Webserver, der das Repository so bearbeitet, dass nur https akzeptiert werden. Im Fall 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 / ab. ssl und fügen Sie im Fall von Ubuntu die Datei 00https zu /etc/apt/apt.conf.d hinzu:

   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, tun Sie dies „Ich werde einen Fehler abfangen: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

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

Kommentare

• Vielen Dank für die großartige Antwort. Aber ich denke, das Hauptproblem ist immer noch da. HTTPS sollte wirklich das Standardprotokoll für Übertragungen über das Web und insbesondere über Debian-Pakete werden. Das Argument sollte nicht sein, warum HTTPS, es sollte sein, warum nicht?
• @aalizadeh, ich stimme Ihnen zu, es gibt Overhead bei der Verwendung von https, aber es gibt keinen massiven Overhead. Ich denke, der Hauptgrund, warum https kein Standardtransport ist, ist, dass einige Organisationen jeglichen verschlüsselten Datenverkehr ausdrücklich verbieten (da sie in der Lage sein möchten, ihre Nasen in das zu stecken, was die Mitarbeiter über das Internet tun), was bedeutet, dass Repositorys Unterstützung benötigen sowohl http- als auch https-Transporte. Möglicherweise gibt es andere Überlegungen.
• Verwenden von » Verify-Host “ false „; « ist selbst bei selbstsignierten Zertifikaten falsch. Sie müssen Ihre Clients stattdessen auf das (richtige) Serverzertifikat aufmerksam machen.
• In der Tat, aber hier waren meine Clients nur interne Systeme. Anstatt die richtige pki-Infrastruktur zu schaffen, habe ich die Ecke gekürzt. Und ja, später wurde pki richtig erledigt und Verify-Host falsch; wurde entfernt. Und ja, der Punkt ist gültig.
• Mit Ubuntu Xenial werden die apt-Pakete als nicht privilegierter Benutzer _apt abgerufen. Können Sie diesen Thread mit Details darüber aktualisieren, wie Sie die Dateiberechtigungsprobleme verwaltet oder behoben haben.

Beachten Sie, dass aufgrund von Sicherheitslücken wie

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

… was die InRelease-Signatur umgeht, ist wahrscheinlich eine gute Idee, HTTPS trotzdem zu konfigurieren.

Und dies ist kein einziges Beispiel – viele andere Update-Systeme, die standardmäßig HTTP verwenden, haben in der Vergangenheit ebenfalls Fehler bei der Signaturüberprüfung festgestellt.

Sicherheitskritische Update-Mechanismen sollten sowohl HTTPS als auch Signaturüberprüfung als robust. Jeder mildert einen Fehler des anderen.

Kommentare

• Und jetzt auch dieser: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. InRelease-Signierung ist nicht ausreichend . “ Das Verschieben aller Spiegel auf HTTPS erfordert jedoch Zeit und Koordination! „. Ja. Jetzt anfangen. Dies ist nicht der letzte InRelease-Fehler.
• Hier ist ‚ ein weiteres Beispiel aus einem anderen Ökosystem – Alpine. Das Paketverwaltungssystem ‚ verwendet standardmäßig kein HTTPS und verlässt sich ausschließlich auf die Signatur, um die Paketintegrität zu überprüfen …und diese Überprüfung hatte im September 2018 einen remote ausnutzbaren Fehler: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine sollte starten jetzt standardmäßig auf HTTPS umstellen.
• (Vollständige Offenlegung: mein eigener Kern, aber ‚ ist die einzige mir bekannte Referenz of), hier ist eine Liste aller Fehler bei der Überprüfung der clientseitigen Signaturüberprüfung, die mir ‚ bekannt sind. Die Liste ist nicht trivial und wächst regelmäßig. Fügt willkommen hinzu. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004