SHA1-Digest-Namen in OpenSSL: Was eine alte Liste bedeutet

Alte Digest-Listen lesen sich wie ein Transkript kryptografischer Entscheidungen, und das sind sie nicht. Namen wie SHA1, DSA-SHA1-old oder RSA-SHA1-2 stehen in alten OpenSSL-Builds nebeneinander, weil die Bibliothek mehrere Einstiegspunkte rund um verwandte Hash-Maschinerie registriert hat. Eine RSA- oder DSA-Bezeichnung in dieser Liste sagt nichts darüber aus, was OpenVPN mit einem Paket gemacht hat. Was Sie lesen, ist das Inventar der Bibliothek, nicht die Aufzeichnung einer Sitzung.

Drei Dinge müssen getrennt werden, bevor irgendeine Schlussfolgerung Sinn ergibt: der registrierte Name, die Digest-Berechnung darunter und die Operation, die ihn verbraucht.

Eine Registrierung ist eine Schnittstelle, keine Stärkebewertung

In OpenSSL 1.0.2 verbindet die Digest-Registrierungstabelle Namen, Aliase und Implementierungen in einer Datei. Der alte DSS1-Deskriptor ist der klarste Fall: Er meldet die Ausgabelänge von SHA-1 und ruft die Finalisierungsroutine von SHA-1 auf, während er einen Namen trägt, der einen ganz anderen Algorithmus nahelegt. Zusätzliche Buchstaben in einer Registrierung bedeuten daher keinen anderen Hash, keine längere Ausgabe und keine neue Sicherheitsstufe.

Dieselbe Quelle bewahrt Aliasbeziehungen für ältere Aufrufer, was erklärt, warum eine Liste überfüllt wirkt. Das ist Dokumentation der Kompatibilität, kein Versprechen, dass ein aktueller OpenSSL-Anbieter identische Namen bereitstellt.

Signaturnamen erzeugen keine Signaturen

Ein Signatur-Framework kann einen Digest an die Schnittstelle eines anderen Algorithmus binden, damit bestehende Aufrufer weiter kompilieren. Eine echte Public-Key-Signatur braucht sowohl einen Schlüssel als auch den Signaturschritt, der ihn nutzt, und beides liefert kein Name in einem Menü. Ein RSA-gefärbter Digest-Eintrag ist ein Name, den ein Aufrufer verwenden darf, kein Beleg dafür, dass jedes VPN-Paket eine RSA-Signatur trug.

An diesem Schritt rutschen ältere Texte in die Folklore. Wenn Sie wissen müssen, wie Pakete authentifiziert wurden, suchen Sie die Option, die den Mechanismus ausgewählt hat, und lesen Sie, was sie in der Version tut, die Sie tatsächlich ausführen. Die mit dieser Ausgabe gelieferte Handbuchseite ist die einzige Beschreibung, die zum Programm vor Ihnen passt. Archivierte Anleitungen beschreiben die Ausgabe, für die sie geschrieben wurden, und die kann mehrere Namenskonventionen zurückliegen.

Finden Sie die Option, die den Namen verbraucht hat

Im Fall der Paketauthentifizierung, den OpenVPN 2.6 dokumentiert, wählt auth einen Digest, den HMAC verwendet, eine schlüsselbasierte Nachrichtenauthentifizierung und keine Zertifikatssignatur. Der Signaturalgorithmus des TLS-Zertifikats ist eine separate Eigenschaft des Handshakes.

Bei einer AEAD-Datenchiffre gilt die separate Einstellung auth nicht mehr für den Datenkanal, während ihre Rolle für tls-auth eine eigene Frage bleibt. Eine Digest-Liste kann Ihnen daher nicht sagen, welcher Hash die aktuellen Pakete schützte, welche TLS-Suite ausgehandelt wurde oder wie das Peer-Zertifikat signiert wurde. Nur die wirksame Konfiguration plus die Version kann das beantworten, und nur für die Verbindung vor Ihnen.

Notieren Sie, was Sie tatsächlich haben

Notieren Sie die OpenVPN-Version, die verlinkte Kryptobibliothek, die genauen Optionen im Profil und das Ergebnis einer echten Verbindung. Dieser Satz beantwortet Fragen, die ein Screenshot eines Digest-Menüs nicht beantworten kann, und er überlebt das nächste Upgrade, weil er Versionen statt Eindrücke nennt.

Vor allem: Wählen Sie keinen alten Alias, weil sein Name stärker oder spezifischer klingt. Wählen Sie die unterstützte Richtlinie für die gesamte Verbindung, und behandeln Sie die alten Namen als Aufzeichnung dessen, wie sich eine Bibliothek früher präsentierte.