Industry standards now require increased security in encryption protocols to keep data safe. We are legally-obligated to comply with these increased security requirements, and doing so requires changes to our hosting infrastructure.
We applied security updates for most of our hosted websites on Monday, 16 July 2018.
UPDATE: We will be enforcing security updates for secure.softwarekey.com on Monday, 26 November 2018 that have the potential to be impactful to your company and how your customers connect to our licensing servers.
How does this affect my customers?
The fact is, operating system vendors have chosen to stop enhancing older operating systems. Very old operating systems that only support very old internet browsers and security standards are no longer secure as a result. Any customers attempting to use these non-secure systems will not be able to establish secure connections to our licensing servers.
Testing Environment Available Now
We have no reason to believe that any widespread disruption in service will occur for licensed applications using a recent release of our licensing toolkit, when the most common implementation scenarios are used.
You should check with your software development team to see if they customized the implementation to force secure connections in the license activation and license validation requests to our servers, as these implementations WILL be impacted.
Effective immediately, any customers using SOLO Server Shared / Custom URL can temporarily change their code to use solotest.softwarekey.com as the server name for internal testing purposes. This server URL will only respond to TLS 1.1 or TLS 1.2 for secure connections just like our production servers will be doing on the enforcement date.
What Operating Systems are Affected?
Effective Monday, 16 July 2018, any attempt to securely access SoftwareKey's web sites and services (which includes SOLO Server Automation, our www.softwarekey.com web site, and our support.softwarekey.com support portal) will only be able to do so where TLS 1.1 or TLS 1.2 is supported.
Here is a summary of the new operating system requirements:
- Microsoft Windows operating systems
- Windows 7 / Windows Server 2008 R2 or newer with Internet Explorer 11 or newer is required.
- It is possible to use Windows Vista / Windows Server 2008 with Internet Explorer 10, but users will be required to adjust settings on each computer to enable support.
- Windows XP / Windows Server 2003 R2 or earlier, or Internet Explorer 9 or earlier do not support the newer, required standards.
- macOS / OS X operating systems:
- macOS / OS X versions 10.9 or newer is required.
- OS X 10.8 and earlier do not support the newer, required standards.
- iOS 5 or newer is required.
- Earlier versions of iOS (4 and older) do not support the newer, required standards.
- Android 5.0 (Lollipop) and newer is required.
- Earlier versions (4.4.4 and prior) do not support the newer, required standards.
- Linux and other operating systems
- Linux distributions using OpenSSL 1.0.1 and newer is required.
- Any operating system using earlier versions of OpenSSL (such as 1.0.0 and older) do not support the newer, required standards.
The list above reflects the new requirements for securely accessing all of SoftwareKey web sites and services both through web browsers and through licensed software/applications.
How does this affect my applications?
As a software developer, it's important to understand how this impacts your software that might integrate with SoftwareKey's services such as SOLO Server Automation. This can include custom integrations that call SOLO Server's web services, as well as licensed applications. The additional requirements noted here are in addition to the operating system requirements noted above.
To minimize potential for impact, the various Protection PLUS licensing toolkits support falling back to using plain HTTP by default. This allows your licensed applications to communicate with SOLO Server when communications cannot be secured via SSL/TLS. Many of these transmissions (such as activation, license refresh, and deactivation attempts) use their own, separate layer of encryption for security.
If you configured your licensing business logic to require SSL/TLS when communicating with SOLO Server with an application licensed with Protection PLUS 5 SDK, then the operating system requirements above always apply, as the plain HTTP fallback is explicitly forbidden in your source code in this case.
Applications using .NET Framework and/or Protection PLUS 5 SDK .NET Edition
Applications using the Microsoft .NET Framework 4.5 and newer need no modification.
As noted above, applications running any .NET Framework version should automatically fallback to using plain HTTP unless you or your developer explicitly opted to require SSL/TLS. If you customized your implementation to require SSL/TLS, applications using earlier versions of the .NET Framework will require an operating system wide change to a setting as described in this Microsoft support article. This applies to any .NET Framework applications that integrate with SOLO Server web services, and/or use the PLUSManaged library (included with Protection PLUS 5 SDK .NET Edition) to license applications and leverage SOLO Server Automation.
Applications using Protection PLUS 5 Native Edition
The PLUSNative libraries included with Protection PLUS 5 Native Edition offer many different options for linking, both with and without dependencies already included. When using the versions of PLUSNative that include pre-built dependencies, the requirements match the operating system requirements noted above. (Note that this also applies to Protection PLUS 5 SDK Java Edition.)
If, instead, you use your own builds of dependencies (OpenSSL, libcurl, libxml2), you are responsible for determining what your software's requirements are with respect to how you have opted to build these dependencies.
As noted above, applications will fallback to using plain HTTP unless you or your developer explicitly opted to require SSL/TLS by using the SK_FLAGS_REQUIRE_SSL flag.
Applications using Instant Protection PLUS 3 or AutoCrypt SL
The operating system requirements above apply for securing transmissions. As noted above, application licensing will fallback to using plain HTTP when transmissions cannot be secured for some reason.
For .NET Framework applications, communications that occur through Instant Protection PLUS 3 or AutoCrypt SL are separate from any other communications your .NET Framework application may perform. Consequently, the notes above about applications using .NET Framework apply to any custom logic your application may have.
Protection PLUS 4 SDK
The operating system requirements above apply for securing transmissions. As noted above, recent releases of our SDK have been tested and application licensing should fallback to using plain HTTP when transmissions cannot be secured for some reason.
.NET applications using the SwkClientServices library will NOT automatically fall-back to plain-HTTP if HTTPS communication fails. A try/catch block would need to be added with logic to fall-back to plain-HTTP for the URL and retry. Without this additional logic, older versions of Windows (Vista and earlier, or where IE10 and earlier are installed) are going to likely experience issues with online activation.
Some of your customers could opt to use proxy servers on their networks, which can be configured in a wide variety of ways. With respect to this particular subject, it is worth noting that some proxy servers could be configured in a way that causes Protection PLUS licensing clients to fallback to using plain HTTP.
For more information on proxy servers and troubleshooting related issues, check out this knowledgebase article.