trinadh465/openssl-1_0_1g_cve-2015-3195OpenSSL 1.0.1g Quellcode-Schnappschuss für die Schwachstellenanalyse von CVE-2015-3195. Enthält SSL/TLS-Protokollimplementierung, kryptografische Allzweckbibliothek (Chiffren, Digests, öffentlicher Schlüssel) und Kommandozeilenwerkzeuge für die Schlüssel-/Zertifikatsverwaltung.
OpenSSL 1.0.1g 7 Apr 2014
Copyright (c) 1998-2011 Das OpenSSL-Projekt Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson Alle Rechte vorbehalten.
Das OpenSSL-Projekt ist eine gemeinschaftliche Initiative zur Entwicklung einer robusten, kommerziell nutzbaren, voll funktionsfähigen und quelloffenen Toolkit-Bibliothek, die die Protokolle Secure Sockets Layer (SSL v2/v3) und Transport Layer Security (TLS v1) sowie eine leistungsstarke, allgemeine Kryptographie-Bibliothek implementiert. Das Projekt wird von einer weltweiten Gemeinschaft freiwilliger Helfer verwaltet, die das Internet nutzen, um zu kommunizieren, zu planen und das OpenSSL-Toolkit sowie die dazugehörige Dokumentation zu entwickeln.
OpenSSL basiert auf der hervorragenden SSLeay-Bibliothek, die von Eric A. Young und Tim J. Hudson entwickelt wurde. Das OpenSSL-Toolkit ist unter einer dualen Lizenz (der OpenSSL-Lizenz und der SSLeay-Lizenz) lizenziert, was im Wesentlichen bedeutet, dass Sie es für kommerzielle und nicht- kommerzielle Zwecke frei verwenden und nutzen dürfen, sofern Sie die Bedingungen beider Lizenzen erfüllen.
Das OpenSSL-Toolkit umfasst:
libssl.a: Implementierung von SSLv2, SSLv3, TLSv1 und dem erforderlichen Code zur Unterstützung sowohl von SSLv2, SSLv3 als auch TLSv1 in einem Server und Client.
libcrypto.a: Allgemeine Verschlüsselungs- und X.509 v1/v3-Komponenten, die von SSL/TLS benötigt werden, aber eigentlich nicht logisch dazugehören. Es enthält Routinen für Folgendes:
Chiffren
libdes - EAYs libdes DES-Verschlüsselungspaket, das einige Jahre im Netz kursierte
und dann von ihm als Teil von SSLeay neu lizenziert wurde. Es enthält 15
'Modi/Varianten' von DES (1, 2 und 3 Schlüsselversionen von ecb, cbc, cfb und
ofb; pcbc und eine allgemeinere Form von cfb und ofb), einschließlich desx
im cbc-Modus, ein schnelles crypt(3) sowie Routinen zum Einlesen von
Passwörtern von der Tastatur.
RC4-Verschlüsselung,
RC2-Verschlüsselung - 4 verschiedene Modi: ecb, cbc, cfb und ofb.
Blowfish-Verschlüsselung - 4 verschiedene Modi: ecb, cbc, cfb und ofb.
IDEA-Verschlüsselung - 4 verschiedene Modi: ecb, cbc, cfb und ofb.
Digests
MD5- und MD2-Message-Digest-Algorithmen, schnelle Implementierungen,
SHA (SHA-0)- und SHA-1-Message-Digest-Algorithmen,
MDC2-Message-Digest. Ein auf DES basierender Hash, der auf Smartcards beliebt ist.
Öffentliche Schlüssel
RSA-Verschlüsselung/Entschlüsselung/Generierung.
Es gibt keine Begrenzung der Bitanzahl.
DSA-Verschlüsselung/Entschlüsselung/Generierung.
Es gibt keine Begrenzung der Bitanzahl.
Diffie-Hellman-Schlüsselaustausch/Schlüsselgenerierung.
Es gibt keine Begrenzung der Bitanzahl.
X.509v3-Zertifikate
X509-Kodierung/Dekodierung in/aus binärem ASN1 und einer auf PEM
basierenden ASCII-Binärkodierung, die Verschlüsselung mit einem privaten
Schlüssel unterstützt. Programm zur Erstellung von RSA- und DSA-
Zertifikatsanfragen und zur Erstellung von RSA- und DSA-Zertifikaten.
Systeme
Die normalen Digital-Envelope-Routinen und Base64-Kodierung. Höherstufiger
Zugriff auf Chiffren und Digests nach Namen. Neue Chiffren können zur Laufzeit
geladen werden. Das BIO-IO-System, eine einfache nicht-blockierende IO-Abstraktion.
Derzeit unterstützte Methoden sind Dateideskriptoren, Sockets, Socket-Accept,
Socket-Connect, Speicherpuffer, Pufferung, SSL-Client/Server, Dateizeiger,
Verschlüsselung, Digest, nicht-blockierender Test und Null.
Datenstrukturen
Ein dynamisch wachsendes Hashing-System
Ein einfacher Stack.
Ein Konfigurationslader, der ein Format ähnlich wie MS .ini-Dateien verwendet.
openssl: Ein Kommandozeilenwerkzeug, das verwendet werden kann für: Erstellung von RSA-, DH- und DSA-Schlüsselparametern Erstellung von X.509-Zertifikaten, CSRs und CRLs Berechnung von Message Digests Verschlüsselung und Entschlüsselung mit Chiffren SSL/TLS-Client- und Server-Tests Verarbeitung von S/MIME-signierten oder -verschlüsselten E-Mails
Verschiedene Unternehmen besitzen verschiedene Patente für verschiedene Algorithmen an verschiedenen Orten weltweit. SIE sind dafür verantwortlich, sicherzustellen, dass Ihre Nutzung jeglicher Algorithmen legal ist, indem Sie prüfen, ob in Ihrem Land Patente bestehen. Die Datei enthält einige der Patente, von denen wir wissen oder von denen gemunkelt wird, dass sie existieren. Dies ist keine abschließende Liste.
RSA Security besitzt Softwarepatente auf den RC5-Algorithmus. Wenn Sie diese Chiffre verwenden möchten, müssen Sie sich bezüglich der Lizenzbedingungen an RSA Security wenden. Deren Webseite ist http://www.rsasecurity.com/.
RC4 ist eine Marke von RSA Security, daher sollte dieses Label möglicherweise nur mit Genehmigung von RSA Security verwendet werden.
Der IDEA-Algorithmus ist von Ascom in Österreich, Frankreich, Deutschland, Italien, Japan, den Niederlanden, Spanien, Schweden, der Schweiz, Großbritannien und den USA patentiert. Sie sollten kontaktiert werden, wenn dieser Algorithmus verwendet werden soll; deren Webseite ist http://www.ascom.ch/.
NTT und Mitsubishi besitzen Patente und anhängige Patente auf den Camellia-Algorithmus, erlauben aber die kostenlose Nutzung ohne ausdrückliche Lizenzvereinbarung: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html
Um dieses Paket unter einem Unix-Derivat zu installieren, lesen Sie die INSTALL-Datei. Für eine Win32-Plattform lesen Sie die INSTALL.W32-Datei. Für OpenVMS-Systeme lesen Sie INSTALL.VMS.
Lesen Sie die Dokumentation im doc/-Verzeichnis. Sie ist recht grob, listet aber die Funktionen auf; Sie werden wahrscheinlich den Code ansehen müssen, um herauszufinden, wie sie verwendet werden. Sehen Sie sich die Beispielprogramme an.
Für einige Plattformen gibt es bekannte Probleme, die den Benutzer oder Anwendungsautor betreffen können. Wir versuchen, diese in doc/PROBLEMS zu sammeln, zusammen mit aktuellen Gedanken, wie sie in einer zukünftigen Version von OpenSSL gelöst werden sollten.
Informationen zur kommerziellen technischen Unterstützung finden Sie auf der OpenSSL-Website www.openssl.org.
Wenn Sie Probleme mit OpenSSL haben, führen Sie bitte zunächst die folgenden Schritte durch:
- Laden Sie den aktuellen Snapshot von ftp://ftp.openssl.org/snapshot/ herunter,
um zu sehen, ob das Problem bereits behoben wurde.
- Entfernen Sie ASM-Versionen der Bibliotheken.
- Entfernen Sie Compiler-Optimierungsflags.
Wenn Sie einen Fehler melden möchten, geben Sie bitte die folgenden Informationen in den Fehlerbericht ein:
- Auf Unix-Systemen:
Selbsttestbericht, erzeugt mit 'make report'
- Auf anderen Systemen:
OpenSSL-Version: Ausgabe von 'openssl version -a'
Betriebssystemname, -version, Hardware-Plattform
Compiler-Details (Name, Version)
- Anwendungsdetails (Name, Version)
- Problembeschreibung (Schritte, die das Problem reproduzieren, falls bekannt)
- Stack-Traceback (falls die Anwendung einen Core-Dump erzeugt)
Melden Sie den Fehler dem OpenSSL-Projekt über den Request Tracker (http://www.openssl.org/support/rt.html) per E-Mail an:
Beachten Sie, dass der Request Tracker NICHT für allgemeine Unterstützungs- oder Hilfeanfragen verwendet werden sollte. Nur weil etwas nicht so funktioniert, wie Sie es erwarten, bedeutet das nicht unbedingt, dass es sich um einen Fehler in OpenSSL handelt.
Beachten Sie, dass E-Mails an [email protected] in der öffentlich einsehbaren Request-Tracker-Datenbank aufgezeichnet und an eine öffentliche Mailingliste weitergeleitet werden. Vertrauliche E-Mails können an [email protected] gesendet werden (PGP-Schlüssel über die Schlüsselserver verfügbar).
Die Entwicklung wird auf der Mailingliste openssl-dev koordiniert (siehe http://www.openssl.org für Informationen zum Abonnement). Wenn Sie einen Patch einreichen möchten, senden Sie ihn an [email protected] mit dem Betreff "[PATCH]". Bitte fügen Sie eine textuelle Erklärung bei, was Ihr Patch bewirkt.
Wenn Sie sich nicht sicher sind, ob eine Funktion für die allgemeine OpenSSL-Community nützlich sein wird, besprechen Sie sie bitte zuerst auf der Mailingliste openssl-dev. Möglicherweise arbeitet bereits jemand an derselben Sache, oder es gibt einen guten Grund, warum diese Funktion nicht implementiert ist.
Patches sollten so aktuell wie möglich sein, vorzugsweise relativ zum aktuellen Git oder zum letzten Snapshot. Sie sollten dem Codierungsstil von OpenSSL folgen und ohne Warnungen kompilieren. Einige der Kernentwickler-Ziele können zu Testzwecken verwendet werden (debug-steve64, debug-geoff etc.). OpenSSL kompiliert auf vielen unterschiedlichen Plattformen: Versuchen Sie, nur portable Features zu verwenden.
Hinweis: Aus rechtlichen Gründen können Beiträge aus den USA nur angenommen werden, wenn eine TSU-Meldung und eine Kopie des Patches an [email protected] (früher BXA) mit einer Kopie an den ENC Encryption Request Coordinator gesendet werden; bitte nehmen Sie sich etwas Zeit, um http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html [sic] und http://w3.access.gpo.gov/bis/ear/pdf/740.pdf (EAR Section 740.13(e)) für die Details zu lesen. Wenn "Ihr Verschlüsselungsquellcode zu groß ist, um als E-Mail-Anhang zu dienen", nehmen sie ihn gerne auch per Fax entgegen; hoffen Sie, dass Sie einen günstigen Ferntarif haben.
Unser bevorzugtes Format für Änderungen ist die Ausgabe von "diff -u". Sie können es wie folgt erzeugen: