openssl: un binaire utilise-t-il bien les libs openssl ? Comment lui dire d'utiliser une autre version de ces libs ?
10 réponses
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.
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 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)
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)
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
Lucas Levrel , dans le message , a écrit :
b) mv /usr/lib/libopenssl* /tmp ?
Bonne idée pour casser le système.
Lucas Levrel , dans le message
<alpine.LNX.2.11.1509200943280.1901@localhost>, a écrit :
Francois Lafont , dans le message <55fd94e2$0$4570$, a écrit :
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.
Francois Lafont , dans le message
<55fd94e2$0$4570$426a34cc@news.free.fr>, a écrit :
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 ?
Francois Lafont , dans le message <55fd94e2$0$4570$, a écrit :
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 20 septembre 2015, Nicolas George a écrit :
Lucas Levrel , dans le message , a écrit :
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)
Le 20 septembre 2015, Nicolas George a écrit :
Lucas Levrel , dans le message
<alpine.LNX.2.11.1509200943280.1901@localhost>, a écrit :
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)
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
Bonjour,
Le 21/09/2015 à 07:46, Dominique MICOLLET a écrit dans le message <55ff997a$0$3306$ :
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
Bonjour,
Le 21/09/2015 à 07:46, Dominique MICOLLET a écrit dans le message
<55ff997a$0$3306$426a74cc@news.free.fr> :
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).
Le 21/09/2015 à 07:46, Dominique MICOLLET a écrit dans le message <55ff997a$0$3306$ :
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
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
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).
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
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
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.
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.
