17

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!

Improve this question

3 Answers 3

Reset to default
16

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...)

Improve this answer
2
  • 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, 2011 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, 2019 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.

Improve this answer
1
  • 4
    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, 2015 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.

Improve this answer
1
  • 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, 2018 at 15:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .