{"id":101224,"date":"2021-09-08T16:23:07","date_gmt":"2021-09-08T14:23:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-kriptograficheskoj-biblioteki-openssl-3-0-0"},"modified":"2021-09-08T16:23:07","modified_gmt":"2021-09-08T14:23:07","slug":"vypusk-kriptograficheskoj-biblioteki-openssl-3-0-0","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/vypusk-kriptograficheskoj-biblioteki-openssl-3-0-0","title":{"rendered":"Ver\u00f6ffentlichung der Kryptobibliothek OpenSSL 3.0.0","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach drei Jahren Entwicklung und 19 Testver\u00f6ffentlichungen fand die Ver\u00f6ffentlichung der Bibliothek OpenSSL 3.0.0 statt, die die Protokolle SSL\/TLS und verschiedene Verschl\u00fcsselungsalgorithmen implementiert. Der neue Branch umfasst \u00c4nderungen, die die R\u00fcckw\u00e4rtskompatibilit\u00e4t auf API- und ABI-Ebene verletzen, aber die \u00c4nderungen werden die Funktionsweise der meisten Anwendungen nicht beeintr\u00e4chtigen, f\u00fcr deren Migration von OpenSSL 1.1.1 eine Neubau gen\u00fcgen wird. Die Unterst\u00fctzung des alten Branches OpenSSL 1.1.1 wird bis September 2023 fortgesetzt. <\/p>\n
Eine signifikante \u00c4nderung der Versionsnummer steht im Zusammenhang mit der Einf\u00fchrung der traditionellen Nummerierung \u201eMajor.Minor.Patch\u201c. Die erste Ziffer (Major) wird k\u00fcnftig nur bei API\/ABI-Inkompatibilit\u00e4ten ge\u00e4ndert, w\u00e4hrend die zweite Ziffer (Minor) bei der Funktionsausweitung ohne \u00c4nderung des API\/ABI ge\u00e4ndert wird. Korrekturupdates werden mit einer \u00c4nderung der dritten Ziffer (Patch) bereitgestellt. Die Nummer 3.0.0 wurde unmittelbar nach 1.1.1 gew\u00e4hlt, um \u00dcberschneidungen mit dem in Entwicklung befindlichen FIPS-Modul f\u00fcr OpenSSL, das die Nummerierung 2.x verwendete, zu vermeiden. <\/p>\n
Eine weitere wichtige \u00c4nderung f\u00fcr das Projekt war der \u00dcbergang von der doppelten Lizenz (OpenSSL und SSLeay) zur Apache 2.0 Lizenz. Die zuvor verwendete eigene OpenSSL-Lizenz basierte auf dem Text der veralteten Apache 1.0 Lizenz und verlangte eine ausdr\u00fcckliche Nennung von OpenSSL in Werbematerialien bei Verwendung der OpenSSL-Bibliotheken sowie die Hinzuf\u00fcgung eines speziellen Hinweises im Falle der Lieferung von OpenSSL als Teil eines Produkts. Solche Anforderungen machten die alte Lizenz mit der GPL inkompatibel, was bei der Verwendung von OpenSSL in GPL-lizenzierten Projekten Schwierigkeiten verursachte. Um diese Inkompatibilit\u00e4t zu umgehen, sahen sich GPL-Projekte gezwungen, spezifische Lizenzvereinbarungen zu verwenden, in denen der Haupttext der GPL um einen Absatz erg\u00e4nzt wurde, der ausdr\u00fccklich die Bindung der Anwendung an die OpenSSL-Bibliothek erlaubte und erw\u00e4hnte, dass die Anforderungen der GPL nicht auf die Bindung an OpenSSL angewendet werden. <\/p>\n
Im Vergleich zum Branch OpenSSL 1.1.1 wurden in OpenSSL 3.0.0 \u00fcber 7500 \u00c4nderungen von 350 Entwicklern vorgenommen. Zu den wichtigsten Neuerungen in OpenSSL 3.0.0 geh\u00f6ren: <\/p>\n
\n
Ein neues FIPS-Modul wurde vorgeschlagen, das die Implementierung kryptografischer Algorithmen beinhaltet, die dem Sicherheitsstandard FIPS 140-2 entsprechen (im Laufe dieses Monats wird der Zertifizierungsprozess f\u00fcr das Modul gestartet, und die FIPS 140-2-Zertifizierung wird im n\u00e4chsten Jahr erwartet). Das neue Modul ist deutlich benutzerfreundlicher und die Integration in viele Anwendungen erfordert nicht mehr als eine \u00c4nderung der Konfigurationsdatei. Standardm\u00e4\u00dfig ist das FIPS-Modul deaktiviert und erfordert die Angabe der Option enable-fips zur Aktivierung.\n
In libcrypto wurde das Konzept der Plug-in-Anbieter umgesetzt, das das veraltete Konzept der Engines (ENGINE API) ersetzt hat. Mit Hilfe von Anbietern k\u00f6nnen eigene Implementierungen von Algorithmen f\u00fcr Operationen wie Verschl\u00fcsselung, Entschl\u00fcsselung, Schl\u00fcsselerzeugung, MAC-Berechnung sowie f\u00fcr die Erstellung und \u00dcberpr\u00fcfung digitaler Signaturen hinzugef\u00fcgt werden. Sowohl neue Anbieter als auch alternative Implementierungen bereits unterst\u00fctzter Algorithmen k\u00f6nnen erstellt werden (standardm\u00e4\u00dfig wird f\u00fcr jeden Algorithmus jetzt der in OpenSSL integrierte Anbieter verwendet).\n