Many server administrators are now explicitly disabling SSL and TLS 1.0, requiring TLS 1.1 at a minimum, with a preference for TLS 1.2. If your software uses SocketTools to establish secure connections, this can potentially have an impact on your applications.
Another change that's not been as widely discussed is the process of deprecating certificates that are signed using SHA1. Microsoft stopped accepting certificates that use SHA1 in 2017, and before that all of the major browsers started returning warnings about the connection not being secure if the end-entity certificate (e.g.: the certificates you get from CAs like Thawte, VeriSign and Comodo) uses SHA1.
How This Impacts SocketTools
These changes can affect how your applications work, both when establishing secure connections and validating certificates. There's two general scenarios involved. One is where you are establishing a connection to an older server using the current version of SocketTools on a current version of Windows. The other is when you are connecting to a hardened server using an older version of SocketTools or running your application on an older version of Windows.
In the first case, if you are connecting with a server that still uses TLS 1.0, or it uses certificates signed using SHA1, you may not be able to establish a secure connection. The connection may be rejected outright, or the certificate may be considered untrusted. By default, SocketTools will always request the latest version of TLS, and use the strongest cipher suite that is available. Servers using older, deprecated security libraries may not know how to handle the request and abort the connection or otherwise fail unexpectedly. To try and connect to those servers, one thing that you can try is setting the application compatibility mode so that your software thinks that it’s running under Windows XP. If you do that, SocketTools will adjust to use earlier versions of the protocol and weaker cipher suites like RC4-SHA. For obvious reasons, this should only be done if absolutely necessary and it is strongly recommended that the server software be updated.
In the second case, where you are using an older version of SocketTools and/or are running on an older version of Windows, some servers may reject the connection attempt because you’re not using TLS 1.2 or only cryptographically weaker cipher suites are being offered to the server. The current version of SocketTools supports TLS 1.2 and strong encryption algorithms like AES-256, but only on Windows 7 or Windows Server 2008 R2 or later versions. If your software establishes secure connections, make sure you are using a current version of Windows and the latest version of SocketTools. Also make sure that you've installed all critical security updates provided by Microsoft.
Future Changes to SocketTools
SocketTools 10 continues to provide support for TLS 1.0 for backwards compatibility, but it is considered deprecated. To use TLS 1.0 in your applications, you will need to explicitly request it, because it will not be enabled by default. In addition, servers that return end-entity certificates signed using SHA1 will be flagged as untrusted. Although the connection itself will continue to be encrypted, if you use certificate status in your applications to verify the validity of the server certificate, you will need to decide whether or not to present your end-users with a warning. If you have any questions or concerns about how these security changes can impact your applications built using SocketTools, contact our technical support team.