Why can connection to the SSL/TLS (HTTPS, FTPS, SMTP/S, POP3/S) server be closed without any error indication right after connecting?

Some servers close the connection immediately when they receive client's data packet which they can't parse or don't understand. This is usually either a flaw of the server not capable of handling unknown parameters properly or misconfiguration of the server. For example, most versions of OpenSSL (before 1.0) failed when getting TLS 1.1 request.

If you come across such server, the first thing to do is disable TLS 1.1 and TLS 1.2 (disabling SSL 2 is also a good idea).

Next, some servers, including the stock installation of IIS 7, require Renegotiation Attack Prevention to be enabled. This requires the use of TLS 1.0+ and special extension. This extension is enabled when you set RenegotiationAttackPreventionMode property in SecureBlackbox components to rapmAuto or rapmStrict (default value is rapmCompatible) AND enable TLS 1.x and disable SSL 2 and SSL 3.

Finally, some servers handle certain cipher suites incorrectly. Unfortunately, the only remedy for this situation is to disable all cipher suites using the CipherSuites property and then enable them one by one and try to connect.

Some servers are generous enough to report an error before disconnecting. Such error is dispatched to the client using OnError (or OnSSLError) event of the SSL-enabled components. You can handle this event to get information about the error.

Ready to get started?

Learn more about SecureBlackbox or download a free trial.

Download Now