Openssl errno 104 signifie que SSLv2 est désactivé?

13

Je veux vérifier si SSLv2 est désactivé sur mon serveur. Je fais cela en essayant de me connecter à distance avec openssl avec la commande shell suivante.

openssl s_client -connect HOSTNAME:443 -ssl2

La plupart des publications que j'ai pu trouver sur Internet indiquent que si je vois quelque chose de similaire à l'erreur suivante, SSLv2 est correctement désactivé.

29638:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

J'obtiens l'erreur ci-dessus lors de la connexion à mon serveur Ubuntu avec SSLv2 désactivé dans Apache Apache, mais lorsque je me connecte à mon serveur Windows Server 2008 R2 avec SSLv2 désactivé dans le registre, j'obtiens la sortie et l'erreur suivantes.

CONNECTED(00000003)
write:errno=104

Je ne trouve aucune documentation expliquant cette sortie et cette erreur. Si quelqu'un pouvait m'expliquer si et pourquoi cette sortie et cette erreur signifient que SSLv2 est correctement désactivé, je l'apprécierais.

Merci!

David
la source

Réponses:

14

Au moins sous Linux, 104 est ECONNRESETpour "Réinitialisation de la connexion par un pair" - en d'autres termes, la connexion a été fermée de force avec un paquet TCP RST, envoyé par le serveur ou usurpé par un intermédiaire.

J'essaierais Wireshark / tshark sur le serveur Ubuntu pour voir ce qui est réellement envoyé. Si le RST est réel, il se peut que le processus httpd soit mort - vérifiez les fichiers journaux et dmesgjuste au cas où.


Le site Web Qualys SSL Server Test peut afficher toutes les versions SSL / TLS prises en charge par votre serveur Web. (Malheureusement, cela ne dérange même pas avec TLS SNI ...)

user1686
la source
Je me demande donc si le paquet TCP RST est envoyé à partir de Windows Server 2008 R2 lorsqu'un client essaie de se connecter avec SSLv2 lorsque SSLv2 est désactivé sur le serveur
David
Votre pare-feu est généralement le seul intermédiaire qui envoie le paquet RST. Mais si ce n'est pas le problème, forcer parfois SSL3 avec l' -ssl3option ou utiliser l' -servernameoption peut passer outre .
Amit Naidu
-3

Il existe probablement un décalage entre les chiffres pris en charge par votre serveur et ceux pris en charge par le serveur du destinataire.

À M
la source
3
Comment confirme-t-on cela? Comment quelqu'un peut-il le résoudre une fois qu'il l'a confirmé? Je connais personnellement les réponses à ces questions, mais d'autres ne le savent peut-être pas, d'où la raison pour laquelle cette question existe.
Ramhound
-3

J'ai eu la même erreur et elle était liée à l'interface MTU. La définition de l'interface client MTU sur 1492 (c'était 1500) a résolu cette erreur pour moi.

Daniel Roque
la source
2
Cela a peut-être résolu votre problème, mais votre problème n'a rien à voir avec la compatibilité et / ou la configuration du chiffrement SSL. Bien que cette réponse ait pu résoudre votre problème, elle ne s'applique pas au problème de l'auteur, car elle n'est pas liée à cette question.
Ramhound