on 2013 Nov 08 2:21 PM
As of version 16.0 build 1690 and version 12.0.1 build 3994, SQL Anywhere uses OpenSSL to provide strong encryption routines. What impact will this change have for SQL Anywhere customers using strong encryption?
In short, unless you are using the SQL Anywhere FIPS module, you will likely not notice any changes. Existing encrypted databases will continue to work, data encrypted using the encrypt()
function before the change can be decrypted using decrypt()
after the change, and clients can connect to servers using TLS even if they are using different versions of the software.
There are a couple of behaviour changes that apply:
If you are using a self-signed certificate in your identity file, the certificate must have the Certificate Signing attribute set. You can use the viewcert utility to see if that attribute is set (under Key Usage). If it is not set, then you must generate a new certificate that has this attribute set.
If you are using client-side certificates with MobiLink, the certificate now requires the Digital Signature attribute to be set. As above, you can use the viewcert utility to see if that attribute is set but if not, you must generate a new certificate.
With Certicom, a client could trust any certificate in the signing chain and the TLS handshake would succeed. With OpenSSL, the client must trust the root certificate in the chain.
However, if you are using FIPS, there are more changes. These are listed and described below.
If your database or MobiLink server is accepting TLS or HTTPS connections with FIPS, or your MobiLink server is using end-to-end encryption with FIPS, the identity file you used before must be modified before it can be used with new software. The Certicom FIPS module only accepted identity files containing private keys that were encrypted with the 3DES algorithm. However, OpenSSL will not accept such identity files in FIPS mode, so the private key must be re-encrypted with AES. To do this, you can use the viewcert utility. You need to specify the existing identity file, its password, the new identify file you want to create, and the new password. The new password can be the same as the old one if you want. Use the following command:
viewcert -p -o new-file-name -op new-password -ip old-password old-file-name
Note that only the identity file needs to be modified - the trusted certificate files on client machines will still work as-is.
If it seems odd to be using viewcert to change something, realize that you're not actually changing anything. You are displaying an existing certificate in a different format.
Note that the new identity file you create cannot be used with older servers (i.e. those that use Certicom software) since the Certicom FIPS module does not support private keys encrypted with AES.
These utilities now default to using AES to encrypt private keys. AES is a more secure algorithm than 3DES, and as previously mentioned, the OpenSSL FIPS module does not support 3DES. However, the Certicom FIPS module does not support AES, so it is not possible to create an identity file that can be used with both. If you need to use a new (OpenSSL) version of createcert to create a certificate that can be used by an old (Certicom) version of the server, you will need to specify the -3des
switch so that the key is encrypted using 3DES.
Similarly, if you're using viewcert -p
to view a certificate in PEM format, you must use the -3des
switch to encrypt the private key with 3DES rather than the default AES.
If you are deploying SQL Anywhere as part of your application and you are including the FIPS module, there are some changes in the list of files you must include. The DLLs and shared objects that were required before were:
The sbgse2 library has been removed and replaced with two different libraries. On Windows, a Microsoft runtime library is also required. The files now required are:
There are some deployment changes for MobiLink as well. Depending on whether you are using FIPS or end-to-end encryption, there are three sets of instructions below.
These steps update the client identity certificates twice if the Digital Signature attribute is missing from client-side identity certificates. This procedure can make the update less disruptive because synchronizations can continue without having to coordinate the client-side and server-side updates to occur at the same time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This information is also available in the Support Package readme.html file, as well as in the feature description in an updated What's New guide topic, SQL Anywhere 16.0 Support Package enhancements
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Unfortunately, we do not have a mechanism for refreshing the 12.0.1 docs with this material. However, we can certainly place the content of the write up as a DCX comment in the list of 12.0.1 features.
Not highlighted but worth a mention. This change also introduced support for the TLS v1.2 protocol as well.
User | Count |
---|---|
70 | |
10 | |
9 | |
6 | |
6 | |
6 | |
6 | |
5 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.