Short answer

First of all, newer versions of servers expect the client to have enabled either new (TLS 1.1, TLS 1.2) or old (SSL 3) versions of the protocol, but not both.

Browsers don't magically connect with the full set of protocols enabled. Most browsers have SSL 3, TLS 1.0 and TLS 1.1 enabled by default, but you can change this in the options. Next, the browsers try to connect with certain settings and if this fails, they try to reconnect with "older" set of settings, i.e. reduced number of cipher suites enabled and without support for TLS 1.1 and 1.2 (or even without TLS 1.0 support).

Another reason for the problem is that the long list of enabled cipher suites confuses some servers. Depending on what versions of the protocol (new or old) you enable, you need to disable either old (MD5-based, for example) cipher suites or new cipher suites (EC*-, Camellia-, AES-GCM- etc).

Long answer

If you were about to ask one of the questions from the list below, this topic is for you:

• My SSL/TLS components used to work fine but suddenly stopped working for no apparent reason.
• I was able to connect to the TLS (FTPS, SMTPS, POP3S) server with SBB 11/10/9/… just fine, but I can't connect after upgrading to SBB12 any more.
• My server provider has upgraded their TLS endpoint (or updated their certificate) and I can't connect any more.
• I'm just unable to connect to a TLS server I need to connect to.

Being fairly general terms, 'can't connect' and 'stopped working' can be represented by a variety of symptoms, from socket errors (100XX, e.g. 10060) and SecureBlackbox SSL errors (75xxx, e.g. 75782) to 'control channel transfer error'-like exceptions.

After a major shake-up in the global SSL/TLS ecosystem that followed a row of vulnerabilities discovered in different versions of the protocol during a period of 2012-2015, the compatibility balance that was being built up between the implementations for years, was challenged. To counteract the attacks, TLS users and administrators were advised to implement a variety of measures in their environments, including as ground breaking as complete cease of support for particular protocol versions - SSL 2.0 and SSL 3.0, to be specific. While most of those measures are fairly friendly compatibility-wise, the others are not and may need specific tune-up to overcome connectivity problems, which sometimes may involve in a certain level of a trade-off. This particularly concerns the protocol versions issue - on one hand, an SSL3-capable client just won't connect to a TLS 1.x-only server, while a TLS 1.x-only client won't connect to an older server that only supports SSL 3.0. Therefore, you need to choose whether you want your SSL/TLS client to be compatible to a newer or an older server - because you can't be compatible to both at the same time.

So, let's go down to the problem. Your SecureBlackbox-powered application just won't connect to an SSL/TLS-capable server (you can add a variety of endings here - 'that it was able to connect before', 'that it was able to connect to with earlier version of SecureBlackbox', or 'whereas IE, Mozilla, Google Chrome, FileZilla or OpenSSL connect just fine' - or just can leave it as it is). If you are reading this in 2015, 95 out of 100, the issue is caused by a compatibility problem that can be resolved by tuning the client component up. The underlying reason is either (1) the server having employed the new TLS guidelines recently (by e.g. ceasing SSL 3.0 support) and not being able to accept connections from your 'less secure' (sic) client any more, or (2) the client having employed the same guidelines and failing to connect to an older and 'less secure' server.

It should be noted that during the life time of SecureBlackbox 12, the default configurations of the SSL/TLS components (primarily client-side) were progressively tuned-up to cater for new 'best practices' suggested by TLS experts and the actual course of events in the ecosystem. We did our best to keep the components as compatible as possible at the same time, yet in certain cases (like versions example above) 100% compatibility just couldn't be achieved. Therefore different builds of version 12 may expose different behaviors even when connecting to the same server - this is normal and is not an indicator of any problem or bug. This is due to a different default setup of the components in different version 12 builds which makes them behave differently out of the box. Yet, each newer product build is expected to be more compatible than the preceding ones, so it makes sense to upgrade to the freshest available version first when coming across an issue and checking if the updated component addresses the issue out of the box.

You are expected to follow the steps described below in the same order, trying to re-establish the connection after each step and checking if it helps. Each step aims to increase the compatibility level of the client component bit by bit by switching off the parameters that might affect connections to certain exotic servers (but not trading off too much of security). Each following step assumes that you preserve the changes you've made on a previous step, unless explicitly instructed otherwise. If you followed all the steps and still can't connect, you are welcome to create a dedicated forum or help desk topic for your problem where our engineers will try to have a deeper look into it and come up with some bespoke solution.

Before you go with the steps:

Pre-Step 1. Check that you are using the latest version 12 build (check here).

Pre-Step 2. Switch off certification validation by simply returning Valid = true from the OnCertificateValidate event handler (REMEMBER TO RESTORE IT BACK LATER).

So, off we go:

Step 1. Enable the following set of versions only: [TLS 1.0, TLS 1.1, TLS 1.2].

Step 2. Switch all cipher suites off except the ones given in the table in the article.

Step 2a. (version 11 users only). Additionally, switch off all AEAD (GCM) cipher suites from the list (SB_SUITE_RSA_AES128_GCM_SHA256, SB_SUITE_RSA_AES256_GCM_SHA384, SB_SUITE_DHE_RSA_AES128_GCM_SHA256, SB_SUITE_DHE_RSA_AES256_GCM_SHA384, SB_SUITE_DHE_DSS_AES128_GCM_SHA256, SB_SUITE_DHE_DSS_AES256_GCM_SHA384, SB_SUITE_ECDHE_ECDSA_AES128_GCM_SHA256, SB_SUITE_ECDHE_ECDSA_AES256_GCM_SHA384, SB_SUITE_ECDH_ECDSA_AES128_GCM_SHA256, SB_SUITE_ECDH_ECDSA_AES256_GCM_SHA384, SB_SUITE_ECDHE_RSA_AES128_GCM_SHA256, SB_SUITE_ECDHE_RSA_AES256_GCM_SHA384, SB_SUITE_ECDH_RSA_AES128_GCM_SHA256, SB_SUITE_ECDH_RSA_AES256_GCM_SHA384).

Step 3. Leave only the following cipher suites enabled: SB_SUITE_RSA_AES128_SHA, SB_SUITE_DHE_RSA_AES128_SHA, SB_SUITE_RSA_AES256_SHA, SB_SUITE_ECDHE_ECDSA_AES128_SHA, SB_SUITE_RSA_AES128_SHA256, SB_SUITE_RSA_3DES_SHA.

Step 4. Try to play with TLS protocol extensions. This should be done before opening connection with a TLS client component. Start with disabling the Signature Algorithms extension and trying to connection without it being sent:

ClientComponent.Extensions.SignatureAlgorithms.Enabled = false;
ClientComponent.Options = ClientComponent.Options &~ ssloDisableSignatureAlgorithmsExtension;
// or 'ClientComponent.Options and not ssloDisableSignatureAlgorithmsExtension' in Delphi

If it doesn't help, please enable the StatelessTLS extension (it is a Boolean property, so just set it to true) and try again.

If it doesn't help either, please disable all extensions except ServerName. This can be done by walking down the objects exposed by ClientComponent.Extensions property and setting their Enabled property to false. Check the connection again. Move to the following step if the component still can't connect.

Step 5. If using higher-level SSL component, such as TElSimpleSSLClient or TElHTTPSClient, remove the ssloAutoAddServerNameExtension flag from the Options flag set.

Step 6. Enable the following set of versions only: [SSL 3.0, TLS 1.0]. If you manage to connect fine after this adjustment, please note that this mode is insecure and should not be used as a default mode for your software. The server you are connecting to is old, insecure and is likely to be upgraded soon. Please use this mode as an exception and always try to connect to other servers with SSL 3.0 switched off first.

If after this step you still can't connect, please create a separate topic in the forum or help desk.

Remember to restore your certificate validation handler after finding the working configuration!

Generally, it might make good sense to start supporting SSL setting profiles in your SBB-driven software and allow your users to choose a profile from the list in case of a problem. This will help you reach the highest levels of compatibility and provide your customers with a high quality, adjustable and stable solution.

As of March 2015 we would recommend the following set of profiles for HTTPS connections. As FTPS, SMTPS and POP3S servers worldwide are upgraded slower than HTTPS, it is a good idea to provide a specific compatible profile for them:

1. Default. Versions: TLS 1.0, TLS 1.1, TLS 1.2; cipher suites: all those enabled by default.


2. Compatible (HTTPS). Versions: TLS 1.0, TLS 1.1, TLS 1.2; cipher suites: all those from the list here.


3. Compatible (FTPS, SMTPS, POP3S). Versions: SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2; cipher suites: all those from the list here.


4. Older software compatible (use with care). Versions: SSL 3.0, TLS 1.0; cipher suites: all those from the list here.


5. Prehistoric software compatible (use with care). Versions: SSL 3.0, TLS 1.0; cipher suites: only those from the list from Step 3 above.

The above set of preset profiles only reflects our view of the situation in SSL/TLS ecosystem as of March 2015. As the environments are changing extremely quick, the list might need some updating in future. We will try to do our best to maintain it in the up-to-date state, so it is a good idea to check this page for updates from time to time and adjust your code as suggested.