Secure Connections Using SSL 3.0

You may have heard about the POODLE attack that can exploit a vulnerability which forces a fallback to SSL 3.0 and can be used to compromise a secure connection. Because SSL 3.0 has been shown to be vulnerable (and SSL 2.0 has been considered deprecated for years now), many server administrators are now explicitly disabling SSL and requiring TLS 1.0 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 how your applications work.

There is also another change underway that’s not been as widely discussed which is the process of deprecating certificates that are signed using SHA1. Microsoft has previously announced that Windows will stop accepting SHA1 certificates by 2017, and before that all of the major browsers will start 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, where you are connecting with a server that still uses SSL 3.0 or uses certificates signed using SHA1, you may not be able to establish a secure connection or the connection may be considered untrusted. By default, SocketTools will always request the latest version of TLS and 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 your systems have the current service pack installed and all critical security updates provided by Microsoft.

Future Changes to SocketTools

SocketTools 8.0 continues to provide support for SSL 3.0 for backwards compatibility, but in future versions it will be considered deprecated. To use SSL 3.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. Let us know if you have any questions or concerns about how these security changes can impact your applications built using SocketTools.

Share This
Facebooktwittergoogle_plus