OpenSSL: unknown protocol / wrong version number

En faisant ma mise à jour vers Devuan ascii, un de mes tunnels SSL (avec stunnel4) est tombé.

Comme j'ai demandé à mon moteur de recherche préféré si quelqu'un avait rencontré ses erreurs et que personne n'a partagé de réponse, je me suis dit que j'allai laisser ça là.

Première erreur, le passage de stunnel 5.30 à 5.39 a visiblement fait sauter l'option NO_SSLv2. Le man me dit que non, mais le message d'erreur est très explicite :

"options = NO_SSLv2": Illegal TLS option

Une fois ceci réglé, je tombe sur une seconde erreur :

stunnel: LOG3[84]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol

Ça aurait dû me mettre la puce à l'oreille, mais le SSL23 m'a induit en erreur. Pensant avoir un protocol missmatch avec mon client qui parlait en SSLv2 pendant que le serveur n'acceptait que du TLS à cause de la disparition de l'option.

J'ai donc tenté de forcer des versions de TLS de chaque côté avec :

sslVersion = TLSv1.2
ciphers = ECDHE-RSA-AES256-GCM-SHA384

Et j'ai obtenu ma troisième erreur :

stunnel: LOG3[113]: SSL_accept: 1408F10B: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

Ici aussi, les moteurs de recherche n'aident pas.

Je tente depuis le client de me connecter au serveur :

user@client# openssl s_client -connect $server:$port
[...]
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
[...]

Bon, à priori, pas de problème sur le serveur (ça tombe bien, il n'avait pas encore été mis à jour).

Sur le serveur, je coupe stunnel4 et le remplace par OpenSSL en mode serveur puis je laisse mon client faire passer ses requêtes normalement (sans les forger) une première fois avant d'en forger une seconde de test avec wget (que je fais requêter le port d'écoute du client stunnel4) :

root@server$ openssl s_server -accept $port -www -cert cert.pem -key key.pem
140501131413136:error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request:s23_srvr.c:397:
ACCEPT

Hum... Toujours la même erreur.

Donc, le problème vient bien du client. Mais pas de stunnel4 ? Je vérifie donc avec un outil beaucoup plus simple :

root@server$ nc -l -p $port

Et là : Eureka. Je vois le traffic de mon client passer en clair.

Tout va bien, pas de soucis avec stunnel4 : c'est le logiciel qui empruntait le tunnel qui s'est mis à renvoyer les données directement au serveur au lieu de passer par le tunnel.

Aucune idée de comment la mise à jour a pu faire ça, mais maintenant, c'est réglé. Ouf !