It’s Time to Change the Channel: Security Updates in Synergy/DE 12.1

By John Brunett, Senior Software Engineer, Synergex

When Synergex introduced encryption—starting with the HTTP API in v8.1, and adding xfServer/xfServerPlus in v9 and SQL Connection in v10.3.3—it was implemented on all supported platforms using the third-party software OpenSSL. This provided a good common implementation on multiple platforms, but keeping up with the latest security flaws could be a nightmare, especially on Windows, where maintaining OpenSSL updates is not automatic as it is with Windows Update. With the release of Synergy/DE 12.1, the nightmare is over! On Windows, OpenSSL has been replaced with the native implementation of Windows Secure Channel. So, what does this mean for you and your applications?

Windows Secure Channel, or Schannel, is a Security Support Provider (SSP) that implements Secure Socket Layer (SSL) and Transport Layer Security (TLS) internet-standard authentication protocols, much like OpenSSL. However, since it is built directly into the Windows operating system, Windows Update maintains the latest security patches – so there is no need to wonder if your third-party security software is up to date.

After you install the latest LTS release of Synergy/DE on Windows, all encrypted communication will go through Schannel using your existing PEM certificate files. No code changes are required. PEM files are not typically used with Schannel, but to allow full compatibility with prior Synergy versions, our Schannel implementation continues to support them. (See below for important info about your existing PEM files.)

So, how do you make the most of this new implementation? The first change I would make would be to get rid of my PEM files and start using the built-in Windows Certificate Store. This is where all the cryptographic certificates are stored on Windows for use by web browsers and other facilities that use encryption. The certificates in your PEM files can be imported into the Store, but this can’t be done directly because the key won’t be imported. You first need to convert your PEM file into a .pfx file (PKCS12). Windows utilities are not very friendly with PEM files, so unless you find a better method you’ll need to use OpenSSL to do this:

openssl pkcs12 -inkey servercertkey.pem -in servercert.pem -export -out server.pfx

If you need to create a new certificate, see Creating a local certificate authority using PowerShell (Windows) in the Synergy/DE documentation.

Once you’ve successfully imported your certificate, you’ll need to change all the places that used to specify your PEM file to instead refer to the certificate in the Windows Store, using one of these formats:

Location\Store\CertificateName (e.g., LocalMachine\MY\ServerCert)

Location\Store\Thumbprint (e.g., LocalMachine\MY\2779C7928D055B21AAA0Cfe2F6BE1A5C2CA83B30)

We recommend you use the certificate name format because the certificate thumbprint will change when you renew your certificate, which may be as often as every 30 days. But the thumbprint form is available in case your certificate name is not unique.

Also, when there is an option to specify the CA file parameter (currently exclusive to HTTP API routines), the Schannel implementation allows you replace the PEM filename with the literal value “cert_store,” which tells the Synergy Runtime to validate certificates directly against the Trusted Root Certification Authorities list in the Windows Certificate Store.

Another encryption change you should be aware of is the new certificate validation feature that was added in v12 to xfServer, xfServerPlus, and SQL OpenNet on Windows and UNIX. The Synergy Runtime does not (as yet) provide the ability to validate a certified encrypted connection to xfServer or xfServerPlus, mainly because those products use a proprietary API; however, as another step toward better security, these servers now validate the specified cryptographic certificate on startup and terminate if it’s invalid. It is very possible that you might discover your old PEM file has expired sometime in the past and your pre-v12.1 servers didn’t care—it happened to us. If you do run into an invalid certificate, the server products allow you to temporarily change this new feature to a warning by specifying a new command-line argument, -invcertOK, that will do just that. For xfServer and xfServerPlus, the Synergy Configuration Program has a new checkbox “Allow startup with an invalid certificate” which, when checked, produces only a warning. This gives you time to acquire a valid certificate without experiencing any down time.

Rest assured, if you have cross-platform servers (Unix or VMS), or even pre-v12.1 Windows still using OpenSSL, Schannel is eager and willing to communicate with either kind.

Security is important. Maintaining that security is an ongoing task. Windows Secure Channel simplifies that task.