openssl: un binaire utilise-t-il bien les libs openssl ? Comment lui dire d'utiliser une autre version de ces libs ?

Le
Francois Lafont
Bonjour à tous,

Au départ, j'ai un problème SSL qui est expliqué en détail
ici https://github.com/flaf/miscellaneous/blob/master/shared/openssl-problem.md
mais je vous en fais un bref résumé ici.

D'un côté, j'ai un serveur RabbitMQ sous Ubuntu 14.04 qui utilise
des connexions SSL. Je pense (mais je n'en suis pas sûr à 100%,
cf mes questions plus bas) que ce serveur utilise les lib openssl
de la distribution, à savoir openssl version 1.0.1f, que je vais
appeler la "old" version de openssl.

De l'autre côté, j'ai un client en Ubuntu 14.04 également avec
lequel je cherche à contacter le serveur via une version de
openssl qui n'est pas celle de la distribution mais qui est
une version 1.0.2d, que je vais appeler la "new" version.

Or, ça plante. Si j'utilise la "old" version de openssl sur
le client, ça marche et j'arrive bien à faire un ssl handshake
mais avec la "new" version impossible.

J'en viens à mes questions. Je souhaiterais tester la chose
suivante : je voudrais faire tourner le serveur rabbitmq mais
en faisant en sorte qu'il utilise la "new" version de openssl.
En effet, sur le serveur, la "new" version de openssl est
également installée dans /opt et j'aimerais faire tourner
le serveur rabbitmq en lui disant d'utiliser cette "new"
version et pas celle du système (la "old" version).

1) Déjà je voudrais bien m'assurer que je ne suis pas dans
une mauvaise direction et donc je voudrais être sûr que le
serveur rabbitmq utilise bien les libs openssl de la
distribution. Or déjà, sur ce point, j'ai des doutes. En
effet, si je vois les dépendances (de manière récursive) du
paquet rabbitmq-server, je peux voir une dépendance du paquet
libssl1.0.0 et donc une dépendance à openssl. Mais en revanche
si je tente de lancer le serveur rabbitmq en foreground (avec
la simple commande rabbitmq-server) et que je strace le
processus et ses enfants, à aucun moment je ne vois une
ouverture par exemple de la lib
/lib/x86_64-linux-gnu/libssl.so.1.0.0. Je vois des ouvertures
de fichiers du genre /usr/lib/erlang/lib/ssl-5.3.2/ebin/*.beam
mais c'est tout. Donc, comment être sûr que le binaire
rabbitmq-server utilise bien les libs openssl du système ?

2) En admettant que rabbitmq-server utilise bien les libs
openssl de la distribution, comment faire proprement pour
que le binaire utilise les libs de la "new" version qui
se trouvent donc dans des chemins différents (dans /opt).
Est-ce que cela passe nécessairement pas une compilation
des sources du paquet rabbitmq-server ? Peut-on faire cela
en évitant la compilation et en passant par une installation
de la "new" version de openssl dans /usr/local/ ? Ou alors
un truc à faire avec des variables d'environnement LD_MACHIN
pour ajouter un chemin ?

J'avoue que je n'y connais pas grand chose dans ces histoires
de « liaisons dynamiques de bibliothèques partagées » (je crois
que c'est comme ça qu'on dit ;)) et même s'il s'avère que je
suis dans une mauvaise direction car rabbitqm-server n'utilise
pas les libs openssl, ça m'intéresserait en soi d'en savoir un
peu plus sur ces mécanismes sous Linux.

Merci d'avance pour votre aide.

--
François Lafont
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
yamo'
Le #26368079
Salut,

Francois Lafont a écrit le 19/09/2015 19:01 :
ici https://github.com/flaf/miscellaneous/blob/master/shared/openssl-problem.md




Je suis peut-être à côté de la plaque mais la principale différence est
que sur la 'new' tu as :
Secure Renegotiation IS NOT supported



Soit, il faut éviter soit l'activer sur la new mais je ne crois pas que
ce soit une bonne idée ...

Sinon pour voir ce qui utilise quoi, tu as lsof.

Par exemple lsof +D /opt



HTH!

--
Stéphane
Lucas Levrel
Le #26368136
Le 19 septembre 2015, Francois Lafont a écrit :

comment être sûr que le binaire rabbitmq-server utilise bien les libs
openssl du système ?



a) « ld » doit pouvoir te dire ça avec les options kivonbien, mais je n'en
sais pas plus.

b) mv /usr/lib/libopenssl* /tmp ?

2) En admettant que rabbitmq-server utilise bien les libs
openssl de la distribution, comment faire proprement pour
que le binaire utilise les libs de la "new" version qui
se trouvent donc dans des chemins différents (dans /opt).
Est-ce que cela passe nécessairement pas une compilation
des sources du paquet rabbitmq-server ?



Il me semble que l'usage veut qu'il y ait compatibilité ascendante
quand c'est seulement le troisième nombre qui change (donc 1.0.2 serait
compatible avec 1.0.1), mais cela semble infirmé par ce que cite yamo.

Ou alors un truc à faire avec des variables d'environnement LD_MACHIN
pour ajouter un chemin ?



Il y a LIBRARY_PATH et LD_LIBRARY_PATH ; ou l'option -L de ld. Ça doit
être expliqué dans le man ld, je pense.

--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Nicolas George
Le #26368160
Lucas Levrel , dans le message
b) mv /usr/lib/libopenssl* /tmp ?



Bonne idée pour casser le système.
Nicolas George
Le #26368162
Francois Lafont , dans le message
1) Déjà je voudrais bien m'assurer que je ne suis pas dans
une mauvaise direction et donc je voudrais être sûr que le
serveur rabbitmq utilise bien les libs openssl de la
distribution. Or déjà, sur ce point, j'ai des doutes. En
effet, si je vois les dépendances (de manière récursive) du
paquet rabbitmq-server, je peux voir une dépendance du paquet
libssl1.0.0 et donc une dépendance à openssl. Mais en revanche
si je tente de lancer le serveur rabbitmq en foreground (avec
la simple commande rabbitmq-server) et que je strace le
processus et ses enfants, à aucun moment je ne vois une
ouverture par exemple de la lib
/lib/x86_64-linux-gnu/libssl.so.1.0.0. Je vois des ouvertures
de fichiers du genre /usr/lib/erlang/lib/ssl-5.3.2/ebin/*.beam
mais c'est tout. Donc, comment être sûr que le binaire
rabbitmq-server utilise bien les libs openssl du système ?



La solution ultime, c'est d'aller voir dans /proc/$PID/maps.

Peut-on faire cela
en évitant la compilation et en passant par une installation
de la "new" version de openssl dans /usr/local/ ?



Comment veux-tu installer quelque chose dans /usr/local sans le compiler.

Ou alors
un truc à faire avec des variables d'environnement LD_MACHIN
pour ajouter un chemin ?



C'est la bonne solution : LD_LIBRARY_PATH.
Lucas Levrel
Le #26368224
Le 20 septembre 2015, Nicolas George a écrit :

Lucas Levrel , dans le message
b) mv /usr/lib/libopenssl* /tmp ?



Bonne idée pour casser le système.



Oui, j'ai oublié de préciser que pour que la commande soit efficace,
il faut un /tmp en tmpfs, et redémarrer.

P.-S. : Je n'aime pas les smileys.

--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Lucas Levrel
Le #26368223
Le 20 septembre 2015, Nicolas George a écrit :

Francois Lafont , dans le message
Peut-on faire cela
en évitant la compilation et en passant par une installation
de la "new" version de openssl dans /usr/local/ ?



Comment veux-tu installer quelque chose dans /usr/local sans le compiler.



Il parlait de ne pas recompiler rabbitmq, je pense.

--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Dominique MICOLLET
Le #26368249
Bonjour,

Lucas Levrel wrote:
Le 19 septembre 2015, Francois Lafont a écrit :
comment être sûr que le binaire rabbitmq-server utilise bien les libs
openssl du système ?


a) « ld » doit pouvoir te dire ça avec les options kivonbien, mais je n'en
sais pas plus.



$ ldd nom_complet_du_binaire

donne la liste précise des librairies dynamiques employées par l'éxecutable
(sauf si elles sont chargées à la main par le programme).

Cordialement

Dominique
Benoit Izac
Le #26368318
Bonjour,

Le 21/09/2015 à 07:46, Dominique MICOLLET a écrit dans le message

comment être sûr que le binaire rabbitmq-server utilise bien les libs
openssl du système ?


a) « ld » doit pouvoir te dire ça avec les options kivonbien, mais je n'en
sais pas plus.



$ ldd nom_complet_du_binaire

donne la liste précise des librairies dynamiques employées par
l'éxecutable (sauf si elles sont chargées à la main par le programme).



Ajoutons qu'il ne faut pas lancer cette commande sur un binaire dont on
n'est pas sûr de la provenance car il y a une chance que le binaire soit
exécuté (voir ldd(1) pour explication et parade).

--
Benoit Izac
Dominique MICOLLET
Le #26368745
Bonjour,

Francois Lafont wrote:

Si vous
avez une idée de comment je pourrais trouver la lib coupable, je serais
assez curieux de savoir.


J'insiste : ldd (+ diff)
ldd donne exactement - i.e. avec les numéros de versions - quelles
librairies sont utilisées : en l'employant dans le cas "qui marche" et celui
"qui se vautre", vous devriez pouvoir comparer (avec diff ou diffuse).

Cordialement

Dominique
Francois Lafont
Le #26369105
On 25/09/2015 07:26, Dominique MICOLLET wrote:

Si vous
avez une idée de comment je pourrais trouver la lib coupable, je serais
assez curieux de savoir.


J'insiste : ldd (+ diff)
ldd donne exactement - i.e. avec les numéros de versions - quelles
librairies sont utilisées : en l'employant dans le cas "qui marche" et celui
"qui se vautre", vous devriez pouvoir comparer (avec diff ou diffuse).



Ok, je tenterais ça dès que j'en aurais le temps, promis. Actuellement je
n'ai pas pu me replonger sur ce problème mais, sur ce coup là aussi, j'aimerais
vraiment comprendre qui est le coupable. Je tenterai ta technique dès que
possible. Merci à toi.

--
François Lafont
Publicité
Poster une réponse
Anonyme