Les changements notables depuis la dernière version majeure sont :
- implémentation du protocole DTLS permettant la sécurisation des échanges par datagrammes (UDP)
- implémentation d’algorithmes de cryptographie par courbe elliptique (ECDH et ECDSA)
- amélioration du traitement des grands nombres
- ajout d'un mini compilateur ASN.1 en ligne de commande
- SHA-1 devient l’algorithme de hachage par défaut à la place de MD5
- support des adresses IPv6 dans les certificats
- support d’architectures 64 bits
- amélioration des performances
Pour ceux qui ne connaissent pas, OpenSSL est un composant de sécurité Open Source intégré dans beaucoup d’applications. Par exemple, Apache l’utilise pour les connexions sécurisées du type https ; on peut encore citer OpenSSH, OpenPGP, OpenCA, Samba, Bind, Sendmail, Postfix, QMail... OpenSSL est un ensemble de bibliothèques et d’outils comprenant tout ce qui est nécessaire à l’utilisation de la cryptographie forte et des protocoles SSL, TLS et DTLS.
Il se découpe donc en trois parties :
- la bibliothèque cryptographique
- la bibliothèque implémentant SSL/TLS et DTLS
- le programme en ligne de commande permettant, entre autres, de manipuler les certificats et de mettre en place un serveur d’authentification ou une autorité de certification
SSL (Secure Socket Layer) est un protocole de sécurisation des communications TCP, développé à l'origine par Netscape (SSL v2 et v3). Il a été renommé en TLS (Transport Layer Security) lors de sa standardisation par l'IETF (TLS v1). Il y a très peu de différence entre SSL v3 et TLS v1.
Désormais, les communications par datagrammes (UDP) peuvent, elles aussi, être sécurisées grâce à DTLS. C’est un protocole basé sur TLS et standardisé par l’IETF. Il semble qu’à l’heure actuelle, OpenSSL soit le seul projet implémentant ce protocole. Ceci a été possible grâce à Nagendra Modadugu (un des auteurs du standard) et Ben Laurie (un des leaders du projet). DTLS risque de devenir une solution de choix pour sécuriser les applications pour lesquelles le délai de transmission est important (vidéoconférence, téléphonie et jeux), pour les tunnels et pour les applications gourmandes en sockets.
Les algorithmes cryptographiques implémentés dans OpenSSL sont nombreux :
- symétriques (Blowfish, CAST, DES, 3DES, IDEA, RC2, RC4, RC5, AES)
- asymétriques (DSA, Diffie-Hellman, RSA)
- hachage (HMAC, MD2, MD4, MD5, MDC2, RIPEMD, SHA-1)
Aujourd’hui, les brevets Diffie-Hellman et RSA ont expiré (respectivement en 1997 et 2000). Cependant, IDEA est toujours protégé, et n'est pas utilisable sans restriction.
OpenSSL est basé sur la bibliothèque SSLeay développée par Eric A. Young (ses initiales donnant le nom du projet) et Tim J. Hudson. Aujourd’hui, ils ont rejoint la société RSA en Australie pour développer le produit BSAFE SSL-C qui est le successeur commercial de SSLeay.
La licence du projet OpenSSL est du type Apache. C’est-à-dire que l’on est libre de l’utiliser pour des applications gratuites ou commerciales.
Une alternative GPL peut être trouvé dans le couple Libgcrypt/GnuTLS.
OpenSSL est codé en C mais il est possible de l’utiliser par l’intermédiaire d’autres langages tels que Java, Python, Ruby ou encore Haskell.
Malheureusement, la documentation n’est pas encore complète et il est parfois utile de se référer à celle de SSLeay.
Aller plus loin
- site (33 clics)
- annonce (7 clics)
- documentation SSLeay (15 clics)
- publication sur DTLS (6 clics)
# ...
Posté par M . Évalué à 1.
Sauf que d'apres certains (debian entre autre) elle serait incompatible avec la GPL, d'ou des ports vers la Gnutls si possible ou le retrait du ssl ou du paquet quand c'est pas possible...
[^] # Re: ...
Posté par symoon . Évalué à 6.
http://www.gnome.org/~markmc/openssl-and-the-gpl.html(...)
citant la licence de openssl :
http://www.openssl.org/source/license.html(...)
En gros, tu es *obligé* d'inclure ce texte dans tout programme utilisant ssl :
"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)(...)"
[^] # Re: licences
Posté par Thomas Monjalon . Évalué à 6.
Mais ce qui est beau avec l'Open Source, c'est qu'il y a souvent des alternatives :
Mozilla NSS (http://www.mozilla.org/projects/security/pki/nss)(...)
GnuTLS (http://www.gnu.org/software/gnutls)(...)
Libgcrypt (http://directory.fsf.org/security/libgcrypt.html)(...)
Mhash (http://mhash.sourceforge.net)(...)
MCrypt (http://mcrypt.sourceforge.net)(...)
[^] # Re: licences
Posté par M . Évalué à 0.
[^] # Re: ...
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Haypo
[^] # Re: ...
Posté par brunus (site web personnel) . Évalué à 2.
Parceque si tout le monde se met à faire ça on s'en sort plus...enfin on peut mais pour chaque lib utilisée il serat indispensable de vérifier qu'il n'y a pas des contraintes particulières...alors qu'avec une license GPL...on peut y aller les yeux fermer on sait ce qu'elle implique comme contrainte et libertés.
[^] # Re: ...
Posté par CrEv (site web personnel) . Évalué à 7.
C'est avant tout une reconnaissance et ça me semble normal.
Alors oui c'est pas forcément libre parce que ça contraint mais bon...
Et puis si quelqu'un fait un soft qui utilise des libs, la moindre des choses est quand même de vérifier les licences et d'intervenir en conséquence, rajouter une malheureuse petite ligne ne fait pas de mal et est à mon avis mieux que : "c'est GPL, je me fous totalement de qui l'a fait je le prend et l'intègre dans mon soft sans même dire sur quoi il est basé"
Enfin, c'est mon avis perso ;-)
[^] # Re: ...
Posté par Arachne . Évalué à 1.
Bref, utilisez GNU TLS ou bien pensez dés le départ à ajouter cette clause dans les README et COPYRIGHT de votre projet.
[^] # Re: ...
Posté par CrEv (site web personnel) . Évalué à 3.
Je croyais que dans le libre un peu plus qu'ailleurs on faisait un peu attention aux licences et ce qui en découle...
C'est aussi grave que de prendre un soft gpl et de le licencier sous une autre forme je trouve, c'est ne pas respecter la licence et encore plus les personnes qui sont à l'origine du logiciel...
Pourquoi utiliser tls ? Simplement parce que les développeurs oublient de respecter la licence de ce qu'ils utilisent ?
[^] # Re: ...
Posté par mdlh . Évalué à -1.
tout commen on fait attention de bien lire le post auquel on repond pour etre sur de ne pas repondre a cote...
[^] # Re: ...
Posté par CrEv (site web personnel) . Évalué à 2.
d'où mon :
Je croyais que dans le libre un peu plus qu'ailleurs on faisait un peu attention aux licences et ce qui en découle...
[^] # Re: ...
Posté par Gniarf . Évalué à 2.
Sauf que d'apres certains (debian entre autre) elle serait incompatible avec la GPL
non, c'est le contraire, c'est la GPL qui est incompatible avec elle.
# MD5 vs SHA-1
Posté par Sylvestre Ledru (site web personnel) . Évalué à -2.
Pourquoi SHA-1 ?
Je sais que MD5 a été cassé mais c'est aussi le cas de SHA-1, non ?
[^] # Re: MD5 vs SHA-1
Posté par densmore . Évalué à 1.
Je crois qu'il aurait été cependant plus judicieux de passer directement à SHA-256, par conversatisme.
[^] # Re: MD5 vs SHA-1
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
[^] # Re: MD5 vs SHA-1
Posté par ouah (site web personnel) . Évalué à 0.
Le papier est sorti il y a déjà une ou deux semaines (chercher "Finding Collisions in the Full SHA-1").
> Je crois qu'il aurait été cependant plus judicieux de passer directement à SHA-256, par conversatisme.
Il faut aussi ajouter par rapport à la news qu'avec cette version 0.9.8 il y a enfin une implémentation (c'est pas trop tôt)
des versions de SHA-256, 384 et 512. (Cela faisait cependant des mois et des mois qu'elles étaient sur le CVS).
A ce propos (pub), si vous voulez une implémentation rapide de SHA-224, SHA-256, SHA-384 et SHA-512:
http://www.ouah.org/~ogay/sha2/(...)
[^] # Re: MD5 vs SHA-1
Posté par fredoh . Évalué à 1.
comme il est dit ici http://fr.wikipedia.org/wiki/MD5#Attaques(...) , des chercheurs ont trouvés des collisions pour MD5.
juste une question de vocabulaire, dire qu'un algo de hash est cassé signifie t il que pour un hash donné il peut y avoir plusieurs chaînes au départ (=collision).
Dans ce cas le terme "cassé" ne fait pas la différence avec le fait de trouver une méthode permettant de reconstituer la chaîne de départ à partir du hash.
[^] # Re: MD5 vs SHA-1
Posté par M . Évalué à 1.
[^] # Re: MD5 vs SHA-1
Posté par ouah (site web personnel) . Évalué à 0.
Ce n'est pas exact. Si un algo de hash possède effectivement toujours des collisions ce n'est par contre pas normal de pouvoir en exhiber une. Pour les algorithmes de hachage cryptographiques, exhiber une collision ou connaître un algorithme qui permet d'en exhiber une en moins de 2^(t/2) opérations (où t est la longueur du haché), merci au birthday paradox, revient à casser l'algorithme.
Enfin pour la seconde partie de ta phrase, la propriété que tu mentionnes est la résistance à la préimage et elle est nécessaire mais pas suffisante pour qu'un algorithme de hachage soit considéré comme sûr.
[^] # Re: MD5 vs SHA-1
Posté par tgl . Évalué à 1.
> pour qu'un algorithme de hachage soit considéré comme sûr.
Ouais, m'enfin "sûr" dans l'absolu ça veut pas dire grand chose, faut dire "sûr pour telle application", ou "tel protocole". La résistance à la préimage est par exemple nécessaire ET suffisante pour qu'un algo de hash soit sûr pour la vérification d'intégrité d'un fichier. Et de manière général, elle est suffisante dans une large part des protocoles crypto.
[^] # Re: MD5 vs SHA-1
Posté par Beretta_Vexee . Évalué à 3.
En gros l'attaque donnée permet de générer les fichier A et B qui ont la même signature MD5, mais absolument pas de générer un fichier C qui aurait une signature définie. L'attaque consiste a trouver des collision pas a en générer sur signature ( enfin il explique quelque arnaque a monter a partit de collision mais cela ne vas pas loin ).
Même chose pour SHA1, de plus l'implémentation de cette attaque est très loin d'étre simple ( http://smertrios.atr.free.fr/crypto/(...) )
# crypto
Posté par patrick_g (site web personnel) . Évalué à 5.
Ensuite est-ce que quelqu'un à une idée du pourquoi de l'inclusion d'algos aussi vieux et peu efficaces que DES ou RC2 alors qu'à part AES on ne retrouve aucun des très bons algos de ces dernières années (Twofish; MARS; Serpent; Camellia) ?
[^] # Re: crypto
Posté par M . Évalué à 2.
RC2 : ca sert dans les normes SSL2/SSL3
Donc c'est plus des algos historique qu'il faut encore supporter par compatibilite.
Pour tes nouveaux algos, t'as des papier d'analyse qui evalue leur efficacite ?
[^] # Re: crypto
Posté par patrick_g (site web personnel) . Évalué à 7.
Ils ont été longuement testés par tous les cryptographes du monde et leur sécurité a été jugée au moins aussi bonne qu'AES (qui a gagné car il est plus rapide sur les CPU de petite puissance comme les cartes à puces).
Mars (concu par IBM) : http://www.research.ibm.com/security/mars.html(...)
Twofish (concu par Bruce Schneier l'auteur de Blowfish) : http://www.schneier.com/twofish.html(...)
Serpent : http://www.cs.technion.ac.il/~biham/Reports/Serpent/(...) et aussi http://www.cl.cam.ac.uk/~rja14/serpent.html(...)
A noter la répartition des votes lors du choix d'AES :
The winner, Rijndael, got 86 votes at the last AES conference while Serpent got 59 votes, Twofish 31 votes, RC6 23 votes and MARS 13 votes.
Pour faire face a ce choix d'algos par un organisme américain l'Europe a aussi lancé un concours ouvert à tous : C'est le projet NESSIE.
Le gagnant des algos symétriques est Camellia (un algo japonais) : http://info.isl.ntt.co.jp/crypt/eng/camellia/index.html(...)
A noter plusieurs nouvelles importantes et récentes concernant Camellia :
1) Camellia is adopted for the first time as the ISO/IEC international standard cipher (ISO/IEC18033-3).
2) Camellia was certified as the IETF standard cipher (Proposed Standard) of S/MIME (RFC3657).
3) Camellia was certified as the IETF standard cipher (Proposed Standard) for XML security URIs (RFC4051).
4) IETF began the final process for publishing the Proposed Standard RFC for adding Camellia to IPsec.
Il semble donc que Camellia soit sur la voie de devenir au moins aussi important qu'AES puisqu'il sera dans IPSec et qu'il est le premier algo de cryptographie à être adopté comme standard international par L'ISO.
[^] # Re: crypto
Posté par Anonyme . Évalué à 1.
patrick_g, tu serais quel est le gagnant des algos asymétriques ?
[^] # Re: crypto
Posté par Olivier Samyn (site web personnel) . Évalué à 2.
http://info.isl.ntt.co.jp/crypt/eng/camellia/technology.html(...)
tu peux trouver:
http://info.isl.ntt.co.jp/crypt/eng/camellia/dl/camellia.c(...)
ça doit être utilisable :)
[^] # Re: crypto
Posté par M . Évalué à 1.
Sinon j'ai pas reussit a deternimer si certains truc etait brevete (logiquement si c'est reconnu par l'ietf y a pas de brevet contrairement a l'iso) ni si y a deja des implem libre...
[^] # Re: crypto
Posté par Arachne . Évalué à 2.
typedef unsigned char Byte;
typedef unsigned long Word;
sans compter :
Camellia Block Encryption Algorithm in ANSI-C Language : Camellia.c
[^] # Re: crypto
Posté par Anonyme . Évalué à 0.
[^] # Re: crypto
Posté par patrick_g (site web personnel) . Évalué à 3.
la page wikipedia en français :
http://fr.wikipedia.org/wiki/Projet_NESSIE(...)
Le site du projet NESSIE :
http://www.cosic.esat.kuleuven.ac.be/nessie/(...)
Une page que j'aime bien avec pas mal de renseignements :
http://paginas.terra.com.br/informatica/paulobarreto/(...)
[^] # Re: crypto
Posté par proutaize . Évalué à 2.
Ensuite est-ce que quelqu'un à une idée du pourquoi de l'inclusion d'algos aussi vieux et peu efficaces que DES ou RC2 alors qu'à part AES on ne retrouve aucun des très bons algos de ces dernières années (Twofish; MARS; Serpent; Camellia)
Ce qui compte ce n'est pas que l'efficacité théorique, en crypto. Il faut mettre ça en rapport avec la pratique. DES est *rapide*, vraiment rapide. Alors pour protéger des pages qui n'ont pas forcément intérêt stratégique hyper important, c'est amplement suffisant (qui irait utiliser son cluster de proc vectoriels qui coûte 500k¤ pour intercepter ton mot de passe gmail ?).
De plus, la vieillesse en cryptographie est justement signe de bonne santé. Ça veut dire que ton algo a été testé, éprouvé, par la communauté pendant de longues années.
GL
[^] # Re: crypto
Posté par patrick_g (site web personnel) . Évalué à 1.
Je pense que c'est plus solide que le simple passage des années.
En plus je ne m'interroge que sur l'absence de ces algos...ça coutait pas grand chose de les rajouter dans OpenSSL non ?
[^] # Re: crypto
Posté par proutaize . Évalué à 1.
Twofish date de 1998, ce qui est, il est vrai, un peu mieux, Serpent aussi.
La dernière version date elle de 2000.
Même si ce sont de bons algos, ils n'ont pas du tout subi les mêmes traitements que Rinjdael, le vainqueur. Et le fait que des cryptologues se soient penchés sur le problème essentiellement le temps d'une compet est rien, comparé à l'épreuve des années (hey oui, pendant ces années aussi les gens de la communautés s'attaquent à DES/AES/<mettre ici un algo utilisé>, et ils s'y attèlent d'autant plus qu'ils sont censés devenir des standards).
GL
PS : la médiatisation n'est pas nécessairement un gage de qualité.
[^] # Re: crypto
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
[^] # Re: crypto
Posté par Anonyme . Évalué à 2.
Meme si AES est censé être plus rapide en software, il lui faut un minimum de mémoire, la ou 3DES est beaucoup moins gourmand
[^] # Re: crypto
Posté par Nicolas Bernard (site web personnel) . Évalué à 3.
[^] # Re: crypto
Posté par Anonyme . Évalué à 1.
Je montrai juste que ca coute rien de le garder sous le coude, d'autant plus qu'il a été largement qu'éprouvé ^^
[^] # Re: crypto
Posté par Anonyme . Évalué à 1.
# Erreur de compilation
Posté par Gazel . Évalué à 1.
J'arrive a compiler OpenSSL mais des que je m'attaque a OpenSSH et Apache ca marche pas....
OpenSSH:
gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/apps/build/openssl/lib -L/apps/build/zlib/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
/apps/build/openssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x35): In function `dlfcn_load':
dso_dlfcn.c: undefined reference to `dlopen'
/apps/build/openssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x95):dso_dlfcn.c: undefined reference to `dlclose'
/apps/build/openssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0xbc):dso_dlfcn.c: undefined reference to `dlerror'
/apps/build/openssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x147): In function `dlfcn_bind_var':
dso_dlfcn.c: undefined reference to `dlsym'
/apps/build/openssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x172):dso_dlfcn.c: undefined reference to `dlerror'
/apps/build/openssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x237): In function `dlfcn_bind_func':
dso_dlfcn.c: undefined reference to `dlsym'
/apps/build/openssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x262):dso_dlfcn.c: undefined reference to `dlerror'
/apps/build/openssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x446): In function `dlfcn_unload':
dso_dlfcn.c: undefined reference to `dlclose'
collect2: ld returned 1 exit status
Apache:
/apps/src/httpd-2.0.54/srclib/apr/libtool --silent --mode=compile gcc -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DAP_HAVE_DESIGNATED_INITIALIZER -I/apps/src/httpd-2.0.54/srclib/apr/include -I/apps/src/httpd-2.0.54/srclib/apr-util/include -I. -I/apps/src/httpd-2.0.54/os/unix -I/apps/src/httpd-2.0.54/server/mpm/prefork -I/apps/src/httpd-2.0.54/modules/http -I/apps/src/httpd-2.0.54/modules/filters -I/apps/src/httpd-2.0.54/modules/proxy -I/apps/src/httpd-2.0.54/include -I/apps/src/httpd-2.0.54/modules/generators -I/apps/build/openssl/include/openssl -I/apps/build/openssl/include -I/apps/src/httpd-2.0.54/modules/dav/main -prefer-non-pic -static -c ssl_engine_pphrase.c && touch ssl_engine_pphrase.lo
ssl_engine_pphrase.c: In function `ssl_pphrase_Handle_CB':
ssl_engine_pphrase.c:684: `PEM_F_DEF_CALLBACK' undeclared (first use in this function)
ssl_engine_pphrase.c:684: (Each undeclared identifier is reported only once
ssl_engine_pphrase.c:684: for each function it appears in.)
make[3]: *** [ssl_engine_pphrase.lo] Error 1
make[3]: Leaving directory `/apps/src/httpd-2.0.54/modules/ssl'
[^] # Re: Erreur de compilation
Posté par M . Évalué à 3.
[^] # Re: Erreur de compilation
Posté par allfull . Évalué à 1.
Il faut modifier le fichier suivant
/httpd-2.0.54/modules/ssl/ssl_toolkit_compat.h
Avant le dernier #endif de la page tu rajoutes ce bout de code :
#ifndef PEM_F_DEF_CALLBACK
#ifdef PEM_F_PEM_DEF_CALLBACK
/* In OpenSSL 0.9.8 PEM_F_DEF_CALLBACK was renamed */
#define PEM_F_DEF_CALLBACK PEM_F_PEM_DEF_CALLBACK
#endif
#endif
Tu recompiles et ca tourne normalement.
AF
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.