OpenSSL 0.9.8 est sorti

Posté par . Modéré par Amaury.
Tags : aucun
0
6
juil.
2005
Sécurité
La précédente version majeure (0.9.7) datait de fin 2002. Depuis, les sorties de versions mineures concernaient principalement des corrections de bugs et de sécurité. Après que l’évolution des fonctionnalités ait été bloquée et qu’une première version Bêta soit publiée au mois de mai, voici enfin une nouvelle version majeure.

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

  • # ...

    Posté par . Évalué à 1.

    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.

    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 . Évalué à 6.

      Une explication intéressante d'un développeur gnome :
      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 . Évalué à 6.

        Effectivement, OpenSSL impose une contrainte.

        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 . Évalué à 0.

          oui, mais ces alternatives ne sont pas toute assi completes que OpenSSL, parfois les auteurs n'y ont pas reflechi et ont utilisé openSSL et le portage n'est pas forcement evidant.
      • [^] # Re: ...

        Posté par (page perso) . Évalué à 7.

        Je trouve pas très contraignant d'avoir à ajouter une phrase dans un programme. Payer 10$ par licence ou ne pas avoir accès au code source est autrement plus contraignant.

        Haypo
        • [^] # Re: ...

          Posté par (page perso) . Évalué à 2.

          Si c'est chiant...

          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 (page perso) . Évalué à 7.

            chiant, chiant, faut pas exagérer non plus...

            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 . Évalué à 1.

          Le problème c'est que de nombreux projets, comme lftp ou msmtp, démarrent sans cette clause, parceque l'auteur l'a oubliée ou parceque le projet n'utilise pas OpenSSL. Lorsque l'on s'en rend compte, ou bien lorsque le support SSL est ajouté, de nombreuses contributions ont déjà été intégrées. A ce moment-là il devient très difficile de modifier la licence, vu qu'on doit obtenir l'accord de tous les contributeurs.

          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 (page perso) . Évalué à 3.

            comment les personnes font pour ne pas faire attention aux mentions des copyrights ?
            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 . Évalué à -1.

              Je croyais que dans le libre un peu plus qu'ailleurs on faisait un peu attention aux licences et ce qui en découle...
              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 (page perso) . Évalué à 2.

                Le problème c'est que de nombreux projets [...] démarrent sans cette clause, parceque l'auteur l'a oubliée


                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 . Évalué à 2.

      > 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.

      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 (page perso) . Évalué à -2.

    SHA-1 devient l’algorithme de hachage par défaut à la place de MD5
    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 . Évalué à 1.

      Le papier sur l'attaque de SHA-1 n'est pas encore sorti, la complexité de l'attaque sur SHA-1 est aussi plus grande ce qui laisse de la marge. Et ces attaques ne sont de toute façon pas vraiment applicables dans le cadre du SSH car ce sont des recherches de collisions et pas des attaques sur les préimages.

      Je crois qu'il aurait été cependant plus judicieux de passer directement à SHA-256, par conversatisme.
      • [^] # Re: MD5 vs SHA-1

        Posté par (page perso) . Évalué à 2.

        Le problème c'est que SHA-256 n'est pas spécifié par les normes SSL.
      • [^] # Re: MD5 vs SHA-1

        Posté par (page perso) . Évalué à 0.

        > Le papier sur l'attaque de SHA-1 n'est pas encore sorti.

        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 . Évalué à 1.

      Je sais que MD5 a été cassé mais c'est aussi le cas de SHA-1, non ?

      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 . Évalué à 1.

        un algo de hash a toujours des collisions (normal tu transforme n bits en m bits avec n >> m) , c'est juste qu'on ne doit pas pouvoir generer un fichier qui a un hash connu a l'avance qui est important...
        • [^] # Re: MD5 vs SHA-1

          Posté par (page perso) . Évalué à 0.

          > un algo de hash a toujours des collisions (normal tu transforme n bits en m bits avec n >> m) , c'est juste qu'on ne doit pas pouvoir generer un fichier qui a un hash connu a l'avance qui est important...

          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 . Évalué à 1.

            > la résistance à la préimage [...] est nécessaire mais pas suffisante
            > 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 . Évalué à 3.

          Ce que tu décris c'est la génération d'une pré-image. C'est a dire créer une fichier qui a un hash donné, et cela on ne sait toujours pas le faire . Si tu lis le papier tu verra que l'attaque consiste a générer deux fichiers ou bloc ( en général de 512Ko pour MD5 ) qui produise une collision, mais ces bloc sont générés aux hasard ou presque.

          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 (page perso) . Évalué à 5.

    En premier lieu merci pour cette news : claire; complète; précise et bien rédigée...le sans faute !
    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 . Évalué à 2.

      Ben DES bien que plus trop efficace est encore utilise dans certains domaines (SSl2 par exemple).

      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 (page perso) . Évalué à 7.

        Pour Mars, Serpent et Twofish : ces algos symétriques étaient les concurrents d'AES (Rijndael) lors du concours ouvert par le NIST américain.
        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 . É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 (page perso) . Évalué à 1.

        Certes mais les algos symétriques que je cite ont eux aussi quelques années au compteur et ont participé à une compétition mondiale très médiatisé ou la crème des cryptographes du monde entier a esayé de se faire une réputation en les cassant.
        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 . Évalué à 1.

          Camellia ne date que de 2000, ce qui est faible, tout de même.
          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 (page perso) . Évalué à 2.

        DES est rapide en hardware. En software il est affreusement lent, car il fait plein d'opération sur les bits. Il s'en tire un peu mieux que les algos modernes, mais avec un niveau de protection bien plus bas. Si on utilise du Triple-DES, les perfs en software sont affreuses et le niveau de protection (en supposant que le brute-force soit la meilleure attaque) toujours inférieure, même si cela n'a plus grande importance...
        • [^] # Re: crypto

          Posté par . Évalué à 2.

          j'avais compilé les codes de reference de 3DES et AES pour ma TI-89, et testé avec les vecteurs de tests officiels, et bien 3DES c'est fait en qques secondes, AES j'ai arrété d'attendre au bout d'une heure ^_^
          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 (page perso) . Évalué à 3.

            C'est un cas particulier malheureux alors. Essaye sur un PC, avec la lib de ton choix, que ce soit OpenSSL, libtomcrypt, crypto++, libgcrypt ou ce qu'il y a dans le noyau de l'OS (cryptoapi pour linux ou l'implémentation qui sert pour IPsec dans les BSD), AES est TOUJOURS nettement plus rapide que 3DES, en gros avec un facteur de 3 ou 4 (je parle d'implémentations comparables, dans le même langage).
            • [^] # Re: crypto

              Posté par . Évalué à 1.

              je sais bien que c'est un cas très particulier, je l'ai precisé, c'est quand on est très restreint en mémoire (ce qui peu arriver sur des circuits elecs maison budget etudiant pauvre ^^)
              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 . Évalué à 1.

                (car oui une calculatrice, c'est TRES TRES restreint en mémoire ^^)
  • # Erreur de compilation

    Posté par . Évalué à 1.

    Quelqu'un a reussi a compiler OpenSSH 4.1p et Apache 2.0.54 avec OpenSSL 0.9.8?

    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 . Évalué à 3.

      pour le premier il te manque un -ldl.
    • [^] # Re: Erreur de compilation

      Posté par . Évalué à 1.

      Salut, j'ai rencontré le meme problème que toi lors de la compilation d'Apache avec le mod-ssl. Après quelques recherches, il s'avère qu'il y a un petit problème de compatibilité entre Apache 2 et la dernière version Openssl. En fait, il faut modifier un fichier avant de compiler :
      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.