Überprüfung der Apache HTTP Server Releases

Überprüfung der Apache HTTP Server Releases

Alle offiziellen Releases des vom Apache HTTP Server Project vertriebenen Codes werden vom Release Manager der jeweiligen Version signiert. PGP-Signaturen und SHA-Hashes sind zusammen mit der Distribution verfügbar.

Sie sollten die PGP-Signaturen und SHA-Hashes direkt von der Apache Software Foundation und nicht von unseren Mirrors herunterladen. Dies dient dazu, die Integrität der Signaturdateien zu gewährleisten. Wir empfehlen Ihnen jedoch, die Veröffentlichungen von unseren Spiegelservern herunterzuladen. (Unsere Download-Seite verweist Sie auf die Mirrors für die Version und die offizielle Seite für die Signaturen, so dass dies automatisch für Sie geschieht).

Prüfung

Das folgende Beispiel zeigt, wie die Signaturinteraktion funktioniert. In diesem Beispiel wird davon ausgegangen, dass Sie httpd-2.4.18.tar.gz(die Version) und httpd-2.4.18.tar.gz.asc (die abgetrennte Signatur) bereits heruntergeladen haben.

Dieses Beispiel verwendet den GNU Privacy Guard. JedesOpenPGP-konforme Programm sollte erfolgreich funktionieren.

Als erstes werden wir die abgetrennte Signatur ( httpd-2.4.18.tar.gz.asc ) mit unserer Version ( httpd-2.4.18.tar.gz ) vergleichen.

% gpg --verify httpd-2.4.18.tar.gz.asc httpd-2.4.18.tar.gz gpg: Signatur erstellt Tue Dec 8 21:32:07 2015 CET mit RSA-Schlüssel-ID 791485A8 gpg: Kann Signatur nicht prüfen: öffentlicher Schlüssel nicht gefunden

Wir haben den öffentlichen Schlüssel des Release Managers ( 791485A8 ) nicht in unserem lokalen System. Sie müssen nun den öffentlichen Schlüssel von einem Schlüsselserver abrufen. Ein beliebter Server ist pgpkeys.mit.edu (mit einem Webinterface ). Die öffentlichen Schlüsselserver sind miteinander verknüpft, so dass Sie sich mit jedem Schlüsselserver verbinden können sollten. Sie können die Schlüssel der httpd-Release-Manager auch unterhttps://downloads.apache.org/httpd/KEYS erhalten.

% gpg --keyserver pgpkeys.mit.edu --recv-key 791485A8 gpg: Abfrage des Schlüssels 791485A8 vom HKP-Schlüsselserver pgpkeys.mit.edu gpg: trustdb erstellt gpg: Schlüssel 791485A8: öffentlicher Schlüssel "Jim Jagielski <jim@apache.org>" importiert gpg: Schlüssel 791485A8: öffentlicher Schlüssel "Jim Jagielski <jim@apache.org>" importiert gpg: Gesamtanzahl verarbeitet: 2 gpg: importiert: 2 (RSA: 2)

In diesem Beispiel haben Sie nun zwei öffentliche Schlüssel für Entitäten mit dem Namen "Jim Jagielski<jim@apache.org>" erhalten. Sie haben jedoch keine Möglichkeit zu überprüfen, ob diese Schlüssel von der Person mit dem Namen Jim Jagielski erstellt wurden, deren E-Mail-Adresse angegeben ist. Tatsächlich ist einer von ihnen ein Betrüger. Das bedeutet nicht, dass PGP kaputt ist, sondern nur, dass man sich den vollständigen 40-stelligen Fingerabdruck des Schlüssels ansehen muss und nicht nur die anfällige 8-stellige ID.

Wie auch immer, lassen Sie uns noch einmal versuchen, die Freigabesignatur zu überprüfen:

% gpg --verify httpd-2.4.18.tar.gz.asc httpd-2.4.18.tar.gz gpg: Signatur erstellt Tue Dec 8 21:32:07 2015 CET unter Verwendung der RSA-Schlüssel-ID 791485A8 gpg: Gute Signatur von "Jim Jagielski <jim@apache.org>" gpg: auch bekannt als "Jim Jagielski <jim@jimjag.com>" gpg: auch bekannt als "Jim Jagielski <jim@jaguNET.com>" gpg: auch bekannt als "Jim Jagielski <jimjag@gmail.com>" gpg: Überprüfung der Trustdb gpg: keine letztlich vertrauenswürdigen Schlüssel gefunden gpg: WARNUNG: Dieser Schlüssel ist nicht mit einer vertrauenswürdigen Signatur zertifiziert!
gpg: Es gibt keinen Hinweis darauf, dass die Signatur dem Besitzer gehört. Fingerabdruck: A93D 62EC C3C8 EA12 DB22 0EC9 34EA 76E6 7914 85A8

Zu diesem Zeitpunkt ist die Signatur gut, aber wir trauen diesem Schlüssel nicht. Eine gute Signatur bedeutet, dass die Datei nicht verfälscht wurde. Aufgrund der Natur der Public-Key-Kryptografie müssen Sie jedoch zusätzlich überprüfen, ob der Schlüssel A93D62ECC3C8EA12DB220EC934EA76E6791485A8 vom echtenJim Jagielski erstellt wurde.

Jeder Angreifer kann einen öffentlichen Schlüssel erstellen und ihn auf die Server für öffentliche Schlüssel hochladen. Wenn Sie dann versuchen, die Signatur dieser gefälschten Version zu überprüfen, wird dies nicht gelingen, da der Schlüssel nicht der "echte" Schlüssel ist. Daher müssen Sie die Authentizität dieses Schlüssels überprüfen.

Validierung der Authentizität

Der entscheidende Schritt zur Validierung ist die Bestätigung des Fingerabdrucks des öffentlichen Schlüssels. Wir haben den Fingerabdruck gesehen, als wir den Download überprüft haben: Er lautet A93D 62EC C3C8 EA12 DB22 0EC9 34EA 76E6 7914 85A8

Es gibt zwei Möglichkeiten, Jims Fingerabdruck zu validieren. Der wirklich sichere Weg (der weiter unten beschrieben wird) ist die Verwendung des PGP "Web of Trust", das Ihnen eine kryptographisch starke Vertrauenskette zu Jims Schlüssel bietet. Wenn Sie jedoch neu in PGP sind, erfordert dies einige Zeit und Mühe. Eine Abkürzung zu einem vernünftigen Maß an Sicherheit ist es, Jims Fingerabdruck (immer mit https, nicht http) mit der von der Apache-Stiftung unterhaltenen Datenbank der Fingerabdrücke der Apache-Entwickler unter https://downloads.apache.org/httpd/KEYS abzugleichen . Beachten Sie, dass diese Abkürzung katastrophal scheitert, wenn die Apache-Website jemals kompromittiert wird oder wenn ein Betrüger die HTTPS-Sicherheit bricht, indem er sich ein gefälschtes Zertifikat beschafft und sich als die Website ausgibt. Behalten Sie die Fachpresse im Auge, wenn Sie von einem solchen Vorfall erfahren!

Ein guter Anfang für die Validierung eines Schlüssels ist die Kommunikation von Angesicht zu Angesicht mit mehreren Bestätigungen von amtlichen Lichtbildausweisen. Es steht jedoch jeder Person frei, ihre eigenen Maßstäbe für die Feststellung der Echtheit eines Schlüssels zu haben. Manchen genügt es, die Signatur des Schlüssels am Telefon abzulesen (Sprachverifizierung). Für weitere Informationen darüber, welcher Grad an Vertrauen für Sie am besten geeignet ist, lesen Sie bitte den Abschnitt im GNU Privacy Handbook über die Validierung anderer Schlüssel in Ihrem öffentlichen Schlüsselbund.

Die meisten Entwickler des Apache-HTTP-Servers haben versucht, die Schlüssel der anderen zu signieren (in der Regel mit einer persönlichen Validierung). Um in das Netz des Vertrauens einzutreten, sollten Sie daher nur eine Person in unserem Netz des Vertrauens validieren müssen. (Hinweis: Die Schlüssel aller unserer Entwickler befinden sich in der Datei KEYS).

Zum Beispiel haben die folgenden Personen den öffentlichen Schlüssel von Jim Jagielski signiert. Wenn Sie einen Schlüssel aus dieser Liste verifizieren, haben Sie einen Vertrauenspfad zum Schlüssel 791485A8. Wenn Sie einen Schlüssel verifizieren, der einen der Unterzeichner für 791485A8 verifiziert, dann haben Sie einen Vertrauenspfad. (Und so weiter, und so weiter.)

% gpg --list-sigs pub 4096R/791485A8 2010-11-04 uid Jim Jagielski (Release Signing Key) <jim@apache.org> sig 88C3A5A5 2010-11-07 Philippe M. Chiasson (Home) <gozer@ectoplasm.org> sig 4E24517C 2011-11-10 Hyrum K. Wright (Personal) <hyrum@hyrumwright.org> sig C4FC9A65 2011-11-10 Bernd Bohmann <bommel@apache.org> sig 1F27E622 2015-04-16 Konstantin I Boudnik (Cos) <cos@boudnik.org> sig 08C975E5 2010-11-04 Jim Jagielski <jim@apache.org> sig 2 F2EFD0F0 2011-11-14 Christopher David Schultz (Christopher David Schultz) <chris@christopherschultz.net> sig 3 311A3DE5 2010-11-10 Ruediger Pluem <rpluem@apache.org> sig 64A6A0BA 2013-02-27 Steven J. Hathaway (Apache PGP) <shathaway@apache.org> sig 00A1234F 2015-04-15 Andre Arcilla <arcilla@apache.org> sig 9A59B973 2015-04-21 Stefan Sperling <stsp@stsp.name> sig F51BB88A 2010-11-04 Sander Temme <sander@temme.net> ...weitere Signaturen geschwärzt...

Da die Entwickler in der Regel sehr beschäftigt sind, finden Sie möglicherweise nicht sofort jemanden, der bereit ist, sich persönlich mit Ihnen zu treffen (sie antworten vielleicht nicht einmal auf Ihre E-Mails, weil sie so beschäftigt sind! Wenn Sie keinen Entwickler in der Nähe haben oder Schwierigkeiten haben, eine geeignete Person ausfindig zu machen, senden Sie bitte eine E-Mail an die Adresse des Schlüssels, den Sie zu überprüfen versuchen. Möglicherweise kann man dort jemanden finden, der bereit ist, den Schlüssel zu validieren, oder alternative Mechanismen für die Validierung arrangieren.

Sobald Sie das Netz des Vertrauens betreten haben, sollten Sie bei der Überprüfung der Unterschrift einer Freigabe Folgendes sehen.

% gpg --verify httpd-2.4.18.tar.gz.asc httpd-2.4.18.tar.gz gpg: Signature made Tue Dec 8 21:32:07 2015 CET using RSA key ID 791485A8 gpg: Good signature from "Jim Jagielski (Release Signing Key) <jim@apache.org>" gpg: aka "Jim Jagielski <jim@jimjag.com>" gpg: aka "Jim Jagielski <jim@jaguNET.com>" gpg: aka "Jim Jagielski <jimjag@gmail.com>"

Um die Integrität der heruntergeladenen Datei zu überprüfen, müssen Sie den Quellcode und den zugehörigen SHA256-Hash herunterladen. Wenn Sie zum Beispiel tar.bz bevorzugen, sollten Sie zur Überprüfung der Version 2.4.34 zwei Dateien auf der Festplatte haben:

• httpd-2.4.34.tar.bz2 (Quelle)
• httpd-2.4.34.tar.bz2.sha256 (SHA256-Hash)

Auf den meisten Unix-Systemen ist es dann nur noch eine Frage der Ausführung:

% shasum -a 256 -c httpd-2.4.34.tar.bz2.sha256 httpd-2.4.34.tar.bz2: OK

Hinter den Kulissen überprüft der Befehl, ob der in httpd-2.4.34.tar.bz2.sha256 enthaltene SHA-Hash mit dem für die Datei httpd-2.4.34.tar.bz2 berechneten übereinstimmt. Als korrektes Ergebnis sollte ein "OK" angezeigt werden.

Eine andere Möglichkeit, den SHA256-Wert für eine Datei zu berechnen, ist die Verwendung von openssl:

% openssl sha256 -r httpd-2.4.34.tar.bz2 fa53c95631febb08a9de41fd2864cfff815cf62d9306723ab0d4b8d7aa1638f0 *httpd-2.4.34.tar.bz2

Überprüfen Sie dann, ob der Inhalt von httpd-2.4.34.tar.bz2.sha256 mit dem obigen Ergebnis übereinstimmt.