SecureBlackbox 16: Why doesn't the SSL/TLS (HTTPS, FTPS, etc.) client connect to the server with the default settings?

Short answer

First of all, newer versions of many 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 do not connect with the full set of protocols enabled. Most browsers have SSL 3, TLS 1.0, and TLS 1.1 enabled by default, and you can change this in the browser options. Next, browsers try to connect with certain settings, and if this fails they try to reconnect with an "older" set of settings, i.e., a 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

This topic provides information on troubleshooting the following scenarios:

• 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 anymore.
• My server provider has upgraded their TLS endpoint (or updated their certificate) and I can't connect any more.
• I'm unable to connect to a TLS server I need to connect to, but I can connect in IE/Mozilla/Google Chrome/FileZilla/OpenSSL.

In fairly general terms, when you can't connect or when the components suddenly stop working, the problem can be represented with a variety of symptoms, from 100XX socket errors (e.g., 10060) and 75xxx SecureBlackbox SSL errors (e.g., 75782) to exceptions like "control channel transfer error".

95 times out of 100, the issue is caused by a compatibility problem that can be resolved by reconfiguring the component. The underlying cause is usually one of the following:

• The server has employed the new TLS guidelines recently (by, e.g., ceasing SSL 3.0 support) and cannot accept connections from your "less secure" client anymore.
• The client has employed the same guidelines and fails to connect to an older and "less secure" server.

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 had been building 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 measures as groundbreaking as the complete cease of support for particular protocol versions -- SSL 2.0 and SSL 3.0, to be specific.

Some of those measures are not as friendly as others, compatibility-wise, and may require specific tune-ups to overcome connectivity problems, which sometimes involve trade-offs. This particularly concerns the protocol version issue -- on one hand, an SSL3-capable client will not connect to a TLS 1.x-only server, while a TLS 1.x-only client will not 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 with newer or older servers -- and you cannot be compatible with both at the same time.

The positive side of these perturbations is that we could probably expect the TLS world to implement support for the newest arrangements in TLS 1.x in the short term to be able to resist the discovered attacks and be compatible with the others in the boat. However, a small share of implementations that cannot be upgraded (e.g., implementations based on hardware or exotic embedded solutions) is likely to remain alive for quite some time and will need special handling from parties that need to communicate to them.

Prerequisites

Before troubleshooting compatibility problems, follow the steps below:

1. Check that you are using the latest version 12 build.

   During the life time of SecureBlackbox 12, the default configurations of the SSL/TLS components (primarily client-side) were progressively tuned up to implement the best practices suggested by TLS experts and to reflect the actual course of events in the ecosystem. However, in certain cases (like the versioning example above), 100% compatibility could not be achieved. Therefore, different builds of version 12 may exhibit 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.

2. Disable certification validation by simply returning Valid=true from the OnCertificateValidate event handler.

   Warning: Restore this back later.

Troubleshooting

After performing each of the steps below, in order, try to re-establish the connection -- each step aims to incrementally increase the compatibility level of the client component by disabling the parameters that might affect connections to certain exotic servers (at the same time avoiding security trade-offs). Additionally, on each following step, preserve the changes you have made on a previous step, unless you are explicitly instructed otherwise.

If you still cannot connect, you may require a bespoke solution: please create a dedicated forum or help desk topic for your problem.

Step 1

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

Step 2

Disable all cipher suites 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 following 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

Test TLS protocol extensions. This should be done before opening the connection with a TLS client component.

1. Disable the Signature Algorithms extension and try to connect without it being sent:

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

2. If that does not fix the issue, enable the StatelessTLS property and reconnect.

3. If that does not fix the issue, disable all extensions except ServerName. This can be done by walking down the objects exposed by the ClientComponent.Extensions property and setting their Enabled properties to false.

Check the connection again. Move to the following step if the component still cannot connect.

Step 5

If using a 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 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 disabled first.

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

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

Creating SSL Profiles

It is generally recommended to start supporting SSL setting profiles in your SBB-driven software and allowing 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 more slowly than HTTPS, it is a good idea to provide a profile that is compatible with them specifically.

1. Default:

   Versions

   All of these enabled by default.

   Cipher suites

   TLS 1.0, TLS 1.1, TLS 1.2



2. HTTPS compatibility

   Versions

   TLS 1.0, TLS 1.1, TLS 1.2

   Cipher suites

   All those from the list here.



3. FTPS, SMTPS, POP3S compatibility:

   Versions

   SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2

   Cipher suites

   All those from the Tuning SSL article.



4. Compatibility with older software (use with care):

   Versions

   SSL 3.0, TLS 1.0

   Cipher suites

   All those from the Tunning SSL article.



5. Prehistoric software compatibility (use with care):

   Versions

   SSL 3.0, TLS 1.0

   cipher suites

   only those from the list from Step 3 above.