Overview
Exasol is always looking to improve the security of our offerings. In Exasol 7.1, we have improved the security around connections to the database. While earlier versions of Exasol already supported TLS, with Exasol 7.1 TLS is now the default cryptographic protocol for all connections. This may require changes in your connection settings.
The Change
Exasol 7.1 enforces verification of TLS certificates by default. Prior to version 7.1, TLS certificate verification was optional. This change has been made to ensure that all connections that use non-standard security configurations are configured intentionally. This approach improves overall system security.
Reasoning
This change has been introduced to improve the level of security within the Exasol environment. As a part of the TLS handshake, the drivers require SSL/TLS certificate used by Exasol to be verified. This is a standard practice in network security that increases the security of connections. For example, it can help prevent man-in-the-middle attacks.
Impact
After upgrading to Exasol 7.1, you may notice that connections that previously worked fine are now having problems connecting. If this is the case, it is likely that the connections in question are not using a TLS certificate signed by an official Certificate Authority (e.g., IdenTrust, or DigiCert to name a few). Please know that while Exasol still supports connections using self-signed certificates, these connections now require explicit configuration.
In addition, if you simply update the drivers you are using for your pre-7.1 Exasol installation, you will also experience issues connecting. The following compatibility matrix describes the default cryptographic connections for each Database and Driver Version:
Default Cryptographic Protocols
| 6.2 Driver (ODBC, JDBC, ADO.NET) | 7.0 Driver (ODBC, JDBC, ADO.NET) | 7.1.0+ Driver (ODBC, JDBC, ADO.NET) | WebSocket encryption | |
|---|---|---|---|---|
| Database Version Exasol 6.2.x | ChaCha20 | ChaCha20 | Pre 6.2.15: ChaCha20 6.2.15+: TLS | TLS |
| Database Version Exasol 7.0.x | ChaCha20 | ChaCha20 | Pre 7.0.10: ChaCha20 7.0.10+: TLS | TLS |
| Database Version Exasol 7.1.x | ChaCha20 | ChaCha20 | TLS | TLS |
⚠️ A 7.1 driver will always try to establish a TLS connection first, regardless of the database version. This means using a 7.1 driver to connect to any database version requires you to take action to make a connection to the database (see options below). If the database does not fully support TLS (versions < 6.2.15 and < 7.0.10), then the driver will reconnect with ChaCha20.
Action Required
The action that is required depends on the current setup for your connection that is failing. The following are the most common setups that would result in an issue related to this change. Options for addressing each of these scenarios are listed in a table further below.
| Scenario | Description |
|---|---|
| Using default Exasol certificate | The default Exasol certificate is a self-signed certificate belonging to the Exasol installation. You will need to make changes either to the certificate or to the connection strings in your clients. |
| Using a self-signed certificate | If the certificate you uploaded to Exasol is self-signed, you will need to make changes either to the certificate or to the connection strings in your clients. |
In each of these cases, the options for addressing the issue are the same. Since a single option for the verification of TLS certificates used by Exasol is not feasible for all environments, there are five methods to use for this. These methods are briefly described in the below table in order from most secure to least secure. Further details for each option are provided below.
| Option | Description |
|---|---|
| 1) Standard verification using a CA-signed Certificate | The most secure option is to obtain a certificate signed by an officially recognized certificate authority and upload this certificate to your Exasol instance using EXAoperation. This will result in your clients being able to connect in a fully TLS protected manner. |
| 2) Fingerprint verification | If Option 1 is not feasible, the next best option is to use the certificate fingerprint for verification. |
| 3) Disabling verification *not recommended* | In some cases, it may be necessary to disable verification. While this is supported, it is not recommended. |
| 4) Using ChaCha20 encryption | If you wish, a connection can be configured to use ChaCha20 instead of TLS |
| 5) Turn off encryption | You can configure the connection to turn off encryption entirely. |
Standard Verification
This is the standard certificate verification process used by default. The certificate is verified to be valid for the Exasol node (host or IP address check) from which it was received and that the certificate is properly signed by a recognized Certificate Authority.
While this is the default option, if for any reason you wish to explicitly force the full TLS verification process, this is possible by adding it to the connection strings. The following table provides examples for this explicit callout.
| Connection string examples – Full TLS Verification, Explicit | |
|---|---|
| JDBC | jdbc:exa:exadb1.example.com:8563;validateservercertificate=1 |
| ODBC | EXAHOST=exadb1.example.com SSLCertificate=SSL_VERIFY_SERVER |
| ADO.NET | Server=exadb1.example.com;Port=8563;SSLCertificate=VERIFYSERVER |
If the certificate and the client’s corresponding CA certificates are properly configured, then no additional configuration is necessary.
More information on how to upload and create TLS certificates can be found on the Exasol Docs site for each specific deployment:
Fingerprint-based Verification
If it is not possible or desired for the client to verify the SSL/TLS certificate using the standard verification process, an additional method using the certificate’s fingerprint has been provided to check it. For example, if the certificate is self-signed, this method can still check that the certificate used by Exasol is the expected certificate even if the signatures cannot be verified.
The following table provides examples of how you can configure connection strings to use Fingerprint verification.
| Connection string examples – Fingerprint VerifcationVerification | |
|---|---|
| JDBC | jdbc:exa:exadb1.example.com/<fingerprint>:8563 |
| ODBC | EXAHOST=exadb1.example.com/<fingerprint>:8563 |
| ADO.NET | Server=exadb1.example.com/<fingerprint>;Port=8563 |
Disabling Verification
If it is not possible or desired to perform any verification of the certificate at all, then verification can be completely disabled. By disabling certificate verification, however, a man-in-the-middle attack is possible because it cannot be verified that the client is connected to the specified server in the connection string. As such, this method is not recommended.
The following table provides examples of how you can configure connection strings to disable verification.
| Connection string examples – Verification Disabled | |
|---|---|
| JDBC | jdbc:exa:exadb1.example.com:8563;validateservercertificate=0 |
| ODBC | EXAHOST=exadb1.example.com SSLCertificate=SSL_VERIFY_NONE |
| ADO.NET | Server=exadb1.example.com;Port=8563;SSLCertificate=VERIFYNONE |
Legacy Encryption
If for some reason the use of ChaCha20 is preferred to TLS, it can be manually enabled using the following settings.
| Legacy Encryption Parameter | |
|---|---|
| JDBC | jdbc:exa:exadb1.example.com:8563;legacyencryption=1 |
| ODBC | UseLegacyEncryption=Y |
| ADO.NET | Server=exadb1.example.com;Port=8563;LegacyEncryption=yes |
Turn off encryption
If none of the other options above are viable, the last option is to disable encryption altogether. With this option, data will be transferred between the client and the server in an insecure manner.
| Legacy Encryption Parameter | |
|---|---|
| JDBC | jdbc:exa:exadb1.example.com:8563;encryption =0 |
| ODBC | encryption=N |
| ADO.NET | Server=exadb1.example.com;Port=8563;Encryption=off |
In case you don’t want to change the client connection string and could not timely configure the certificate on the database side you might consider downgrading the driver from version 7.1 to the latest available driver of version 7.0 (see https://www.exasol.com/portal/display/DOWNLOAD/7.0) as a temporary workaround.
Resources
Exasol has authored a Community article that provides guidance on how to implement Options 1-3 above.
The Exasol Docs pages provide information on enabling Options 4 and 5:
EXASOL-2936 has full details on the change and all aspects of the management of connection security.
As always, if you have questions about this or any other aspect of Exasol, please do not hesitate to reach out to Exasol Support at service@exasol.com