SecureBlackbox 16: Why does my connection to the SSL/TLS (HTTPS, FTPS, SMTP/S, POP3/S) server close without any error indication right after connecting?
Note: This article applies only to SecureBlackbox Legacy. For future development please consider using the latest version.
Some servers close the connection immediately when they receive a data packet that they can't parse or a data packet that is otherwise unrecognized. This is usually either a flaw of a 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 a TLS 1.1 request.
If you come across such a 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 a special extension. This extension is enabled when you set the RenegotiationAttackPreventionMode property in SecureBlackbox components to rapmAuto or rapmStrict (the default value is rapmCompatible), enable TLS 1.x, and disable SSL 2 and 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 report an error before disconnecting. Such an error is dispatched to the client using the OnError (or OnSSLError) event of the SSL-enabled components. You can handle this event to get information about the error.
We appreciate your feedback. If you have any questions, comments, or suggestions about this article please contact our support team at email@example.com.