uthrasri/openssl_g2.5_cve-2014-3570_01Libreria crittografica generica e toolkit SSL/TLS che implementa cifrari, digest, algoritmi a chiave pubblica, certificati X.509 e uno strumento da riga di comando per crittografia, decrittografia e gestione dei certificati.
OpenSSL 1.0.1g 7 Apr 2014
Copyright (c) 1998-2011 The OpenSSL Project Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson Tutti i diritti riservati.
Il progetto OpenSSL è uno sforzo collaborativo per sviluppare un toolkit robusto, di livello commerciale, completo e open source che implementa i protocolli Secure Sockets Layer (SSL v2/v3) e Transport Layer Security (TLS v1), oltre a una libreria crittografica generica a piena potenza. Il progetto è gestito da una comunità mondiale di volontari che utilizzano Internet per comunicare, pianificare e sviluppare il toolkit OpenSSL e la relativa documentazione.
OpenSSL si basa sull'eccellente libreria SSLeay sviluppata da Eric A. Young e Tim J. Hudson. Il toolkit OpenSSL è concesso in licenza con una doppia licenza (la licenza OpenSSL più la licenza SSLeay), il che significa sostanzialmente che si è liberi di ottenerlo e utilizzarlo per scopi commerciali e non commerciali, purché si soddisfino le condizioni di entrambe le licenze.
Il toolkit OpenSSL include:
libssl.a: Implementazione di SSLv2, SSLv3, TLSv1 e del codice necessario per supportare SSLv2, SSLv3 e TLSv1 sia nel server che nel client.
libcrypto.a: Materiale generale di crittografia e X.509 v1/v3 necessario per SSL/TLS ma non logicamente parte di esso. Include routine per quanto segue:
Cifrari
libdes - il pacchetto di crittografia DES libdes di EAY, circolato
sulla rete per alcuni anni e poi da lui concesso nuovamente
in licenza come parte di SSLeay. Include 15 'modalità/variazioni'
di DES (versioni a 1, 2 e 3 chiavi di ecb, cbc, cfb e ofb;
pcbc e una forma più generale di cfb e ofb), incluso desx
in modalità cbc, una rapida crypt(3) e routine per leggere
le password dalla tastiera.
Crittografia RC4,
Crittografia RC2 - 4 modalità diverse: ecb, cbc, cfb e ofb.
Crittografia Blowfish - 4 modalità diverse: ecb, cbc, cfb e ofb.
Crittografia IDEA - 4 modalità diverse: ecb, cbc, cfb e ofb.
Digest
Algoritmi di message digest MD5 e MD2, implementazioni veloci,
algoritmi di message digest SHA (SHA-0) e SHA-1,
message digest MDC2. Un hash basato su DES popolare sulle smart card.
Chiave pubblica
Crittografia/decrittografia/generazione RSA.
Non esiste un limite al numero di bit.
Crittografia/decrittografia/generazione DSA.
Non esiste un limite al numero di bit.
Scambio di chiavi/generazione di chiavi Diffie-Hellman.
Non esiste un limite al numero di bit.
Certificati X.509v3
Codifica/decodifica X509 da/verso ASN1 binario e una codifica
ASCII-binaria basata su PEM che supporta la crittografia con una
chiave privata. Programma per generare richieste di certificato
RSA e DSA e per generare certificati RSA e DSA.
Sistemi
Le normali routine di busta digitale e codifica base64. Accesso
di livello superiore a cifrari e digest per nome. Nuovi cifrari possono
essere caricati a runtime. Il sistema di I/O BIO, una semplice
astrazione di I/O non bloccante. I metodi attualmente supportati sono
descrittori di file, socket, socket accept, socket connect, buffer di
memoria, buffering, client/server SSL, puntatore a file, crittografia,
digest, test non bloccanti e null.
Strutture dati
Un sistema di hashing a crescita dinamica
Una semplice pila (stack).
Un caricatore di configurazione che utilizza un formato simile ai file
MS .ini.
openssl: Uno strumento a riga di comando che può essere utilizzato per: Creazione di parametri per chiavi RSA, DH e DSA Creazione di certificati X.509, CSR e CRL Calcolo di message digest Crittografia e decrittografia con cifrari Test client e server SSL/TLS Gestione di posta S/MIME firmata o crittografata
Varie aziende detengono vari brevetti per vari algoritmi in varie località del mondo. Voi siete responsabili di garantire che l'uso di qualsiasi algoritmo sia legale verificando se esistono brevetti nel vostro paese. Il file contiene alcuni dei brevetti che conosciamo o che si sospetta esistano. Non è un elenco definitivo.
RSA Security detiene brevetti software sull'algoritmo RC5. Se si intende utilizzare questo cifrario, è necessario contattare RSA Security per le condizioni di licenza. La loro pagina web è http://www.rsasecurity.com/.
RC4 è un marchio di RSA Security, quindi l'uso di questa etichetta dovrebbe forse essere autorizzato da RSA Security.
L'algoritmo IDEA è brevettato da Ascom in Austria, Francia, Germania, Italia, Giappone, Paesi Bassi, Spagna, Svezia, Svizzera, Regno Unito e USA. Se tale algoritmo deve essere utilizzato, vanno contattati; la loro pagina web è http://www.ascom.ch/.
NTT e Mitsubishi hanno brevetti e brevetti in attesa di approvazione sull'algoritmo Camellia, ma ne consentono l'uso gratuitamente senza richiedere un accordo di licenza esplicito: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html
Per installare questo pacchetto su un derivato Unix, leggere il file INSTALL. Per una piattaforma Win32, leggere il file INSTALL.W32. Per i sistemi OpenVMS, leggere INSTALL.VMS.
Leggere la documentazione nella directory doc/. È piuttosto approssimativa, ma elenca le funzioni; probabilmente si dovrà guardare il codice per capire come usarle. Osservare i programmi di esempio.
Per alcune piattaforme esiste una serie di problemi noti che possono interessare l'utente o l'autore dell'applicazione. Cerchiamo di raccoglierli in doc/PROBLEMS, con le attuali riflessioni su come dovrebbero essere risolti in una versione futura di OpenSSL.
Consultare il sito web di OpenSSL www.openssl.org per i dettagli su come ottenere supporto tecnico commerciale.
Se si hanno problemi con OpenSSL, si prega di seguire prima i seguenti passaggi:
- Scaricare lo snapshot corrente da ftp://ftp.openssl.org/snapshot/
per vedere se il problema è già stato affrontato
- Rimuovere le versioni ASM delle librerie
- Rimuovere i flag di ottimizzazione del compilatore
Se si desidera segnalare un bug, si prega di includere le seguenti informazioni in qualsiasi segnalazione di bug:
- Su sistemi Unix:
Report di autotest generato da 'make report'
- Su altri sistemi:
Versione di OpenSSL: output di 'openssl version -a'
Nome del SO, versione, piattaforma hardware
Dettagli del compilatore (nome, versione)
- Dettagli dell'applicazione (nome, versione)
- Descrizione del problema (passaggi per riprodurre il problema, se noti)
- Stack Traceback (se l'applicazione genera un core dump)
Segnalare il bug al progetto OpenSSL tramite il Request Tracker (http://www.openssl.org/support/rt.html) via e-mail a:
Notare che il request tracker NON dovrebbe essere utilizzato per assistenza generale o richieste di supporto. Il fatto che qualcosa non funzioni come previsto non significa necessariamente che sia un bug di OpenSSL.
Notare che la posta a [email protected] viene registrata nel database pubblicamente leggibile del request tracker e viene inoltrata a una mailing list pubblica. La posta riservata può essere inviata a [email protected] (chiave PGP disponibile dai key server).
Lo sviluppo è coordinato sulla mailing list openssl-dev (vedere http://www.openssl.org per informazioni su come iscriversi). Se si desidera inviare una patch, inviarla a [email protected] con la stringa "[PATCH]" nell'oggetto. Assicurarsi di includere una spiegazione testuale di cosa fa la patch.
Se non si è certi che una funzionalità possa essere utile alla comunità generale di OpenSSL, discuterne prima sulla mailing list openssl-dev. Qualcuno potrebbe già star lavorando alla stessa cosa, oppure potrebbe esserci un valido motivo per cui quella funzionalità non è implementata.
Le patch dovrebbero essere il più aggiornate possibile, idealmente relative al Git corrente o all'ultimo snapshot. Dovrebbero seguire lo stile di codifica di OpenSSL e compilare senza warning. Alcuni target di sviluppo del team principale possono essere utilizzati a scopo di test (debug-steve64, debug-geoff, ecc.). OpenSSL compila su molte piattaforme diverse: cercare di utilizzare solo funzionalità portabili.
Nota: per motivi legali, i contributi dagli Stati Uniti possono essere accettati solo se una notifica TSU e una copia della patch vengono inviate a [email protected] (ex BXA) con copia all'ENC Encryption Request Coordinator; si prega di consultare http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html [sic] e http://w3.access.gpo.gov/bis/ear/pdf/740.pdf (sezione 740.13(e) dell'EAR) per i dettagli. Se "il proprio codice sorgente di crittografia è troppo grande per essere inviato come allegato e-mail", sono lieti di riceverlo via fax; si spera di avere un piano economico per le chiamate a lunga distanza.
Il formato preferito per le modifiche è l'output "diff -u". Si può generare in questo modo: