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 arefivemethods to use for this. These methods are briefly described in the below tablein order from most secure to least secure. Further detailsfor each optionare 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.
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
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.
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.
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.
In caseyoudon'twant to change the clientconnectionstring and could not timelyconfigure the certificate on the databasesideyoumightconsiderdowngrading the driverfromversion 7.1 tothelatestavailabledriverofversion 7.0 (seehttps://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: