Mir ist aufgefallen, dass aptwir beim Installieren von Paketen von manchmal Folgendes tun:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
Wenn ich das richtig verstehe, holen wir uns hier einen öffentlichen GPG-Schlüssel von https://download.../gpgund geben ihn in ein /usr/share/keyrings/docker-archive-keyring.gpg. Dann sagen wir apt: „Wenn Sie Pakete von herunterladen, https://download.docker.com/...stellen Sie sicher, dass diese Pakete mit dem privaten Schlüssel signiert sind, der zu diesem öffentlichen Schlüssel gehört.“
Also, ich verstehe nicht ganz: Wenn wir darauf vertrauen, dass sich auf der anderen Seite Docker befindet https://download.docker.com/.. – und das tun wir, da wir dort den öffentlichen Schlüssel erhalten –, warum müssen wir dann Pakete, die von dort kommen, mit einem GPG-Schlüssel verifizieren?
Klingt für mich nach einem selbstsignierten Zertifikat.
Übersehe ich hier etwas?
Antwort1
Dafür gibt es mehrere Gründe, und sie alle drehen sich umMan-In-The-Middle-Angriffe(MITM) - insbesondere schützt es Sie vor zukünftigen Fällen, in denen Sie Opfer eines MITM-Angriffs oder einer anderen Art böswilliger Umleitung auf „falsche Downloadquellen“ werden.nachSie haben den guten Schlüssel bekommen.
Wenn Sie sich im schlimmsten Fall befinden - Ihr System ist bereits kompromittiert und auf eine schädliche Site für einen böswilligen Akteur (kurz „MA“) umgeleitet -, sind Sie aufgeschmissen, und dies schützt Sie nicht, weil Sie die Schlüssel von MA herunterladen. Das ist nicht der Sinn dieses Schutzes des PGP-Schlüssels und des Schlüsselbunds hier, sondern er soll Sie vorZukunftMITM-Angriffe.
In diesem Beispiel sind Sie bereits kompromittiert, und welcher Schlüssel verwendet wird, ist irrelevant, da MA zu diesem Zeitpunkt wahrscheinlich die Kontrolle über Ihren Computer, Ihr Netzwerk, Ihre Daten usw. hat. Das häufigste Schutzszenario ist jedoch, dass SieStartmit einer sauberen Umgebung/Anlage undDannInstallieren Sie Software aus einer legitimen Quelle. (siehe nächsten Abschnitt)
Allerdings ist der Start in einer kompromittierten Umgebung nicht das „übliche Szenario“, vor dem Schlüsselsignaturen schützen. Das häufigste Szenario ist: Sie befinden sich auf einem sauberen System mit sauberen Updates, Ihr System, die von Ihnen verwendeten DNS-Server, das Netzwerk, mit dem Sie verbunden sind, usw. sind nicht kompromittiert.
Sie installieren Docker und holen sich den Docker-Schlüssel von der echten Docker-Website. Anschließend installieren Sie Docker und der Schlüssel wird validiert.
Irgendwann in der Zukunft hat MA die Kontrolle über Ihren Datenverkehr im Internet übernommen und Sie auf eine „gefälschte“ Docker-Download-Site umgeleitet.
Sofern MA den PGP-Schlüssel nicht mit dem entsprechenden privaten Schlüssel von Docker gestohlen hat, aptzeigt Ihr System, dass die Signaturen aufdownload.docker.com nicht übereinstimmenund dass in Ihrer Umgebung etwas Seltsames vor sich geht und die Updates von der „fehlerhaften“ Repository-Weiterleitung von MA nicht angewendet werden.
Dasist, wovor die Schlüsselsignatur und die Schlüsselteile schützen: dass Sie imZukunft. Es schützt Sie nicht, wenn Sie bereits kompromittiert sind, nichts wird das tun. Es schützt Sie, wenn Sie sauber und kompromittiert beginnen und dannwerdenaus irgendeinem Grund kompromittiert.
Aus diesem Grund sollten Sie die Schlüsselfingerabdrücke auch mit bekannten guten Schlüsselfingerabdrücken vergleichen. Die meisten guten Anbieter von Repositorys haben ihre Fingerabdrücke zur manuellen Validierung verfügbar, sodass Sie sich nicht auf NUR Befehle verlassen müssen, um die Schlüssel abzurufen und ihnen zu vertrauen.