11

I want to check if my server has SSLv2 disabled. I am doing this by attempting to connect remotely with openssl with the following shell command.

openssl s_client -connect HOSTNAME:443 -ssl2

Most literature I could find on the Internet says if I see something similar to the following error then SSLv2 is properly disabled.

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

I do get the above error when connecting to my Ubuntu server with SSLv2 disabled in Apache Apache but when I connect to my Windows Server 2008 R2 server with SSLv2 disabled in the registry I get the following output and error.

CONNECTED(00000003)
write:errno=104

I can't find any literature explaining this output and error. If anybody could explain to me if and why this output and error means that SSLv2 is properly disabled, I would appreciate it.

Thanks!

13

At least on Linux, 104 is ECONNRESET for "Connection reset by peer" – in other words, the connection was forcibly closed with a TCP RST packet, either sent out by the server or spoofed by an intermediary.

I would try Wireshark/tshark on the Ubuntu server to see what actually gets sent. If the RST is real, it could be that the httpd process died – check the log files and dmesg just in case.


The Qualys SSL Server Test website can show all SSL/TLS versions supported by your web server. (Unfortunately, it doesn't even bother with TLS SNI...)

  • So I'm wondering if the TCP RST packet is sent from Windows Server 2008 R2 when a client tries to connect with SSLv2 when the server has SSLv2 disabled – David Jun 17 '11 at 7:32
  • Your firewall is usually the one intermediary who sends the RST packet. But if that is not the problem, sometimes forcing SSL3 with the -ssl3 option or using the -servername option can get past this. – Amit Naidu Jun 20 at 22:35
-3

There is likely a mismatch between the ciphers that are supported by your server, and those supported by the recipient's server.

  • 3
    How does one confirm this? How does somebody resolve it once they have confirmed it? I know the answers to these questions personally, but others might not know, hence the reason they reason this question exists. – Ramhound Oct 14 '15 at 15:09
-3

I had the same error and it was related to interface MTU. Setting the client interface MTU to 1492 (it was 1500), solved this error for me.

  • 2
    This might have solved your problem, but your issue had nothing to do with SSL cipher compatibility and/or configuration. While this answer might have solved your problem, it is not applicable to the author's problem, since it is unrelated to this question. – Ramhound Apr 25 '18 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.