Type: New Feature
Fix Version/s: Exasol 7.1.0
Exasol 7.1 has introduced TLS as the default cryptographic protocol for all connections. Thus, all connections created using Exasol-provided 7.1 drivers will try to establish TLS connections to Exasol per default. Previously, only WebSocket connections supported TLS.
As a part of the TLS handshake, the drivers require SSL/TLS certificate used by Exasol to be verified. This is the standard practice that increases the security of connections by preventing man-in-the-middle attacks, for example.
If the certificate used by Exasol is not signed by a publicly recognized certificate authority (CA) or if the necessary CA certificate has not been provided to the client to use for verification, the connection will fail.
If another certificate has not been uploaded using EXAoperation, a self-signed certificate is used by Exasol per default. Since this certificate is self-signed, TLS connections to Exasol will fail by default. If this self-signed certificate should nevertheless be used, the certificate verification method must be changed.
A custom (i.e. non-default) certificate to be used by Exasol can be uploaded via EXAoperation. For more information on using a TLS certificate with Exasol, please see the following.
Since a single option for the verification of SSL/TLS certificates used by Exasol is not feasible for all environments, there are three possible methods to use for this.
- Full, TLS-standard verification (default)
- Fingerprint-based verification
- No verification
The following table provides an overview of how to set the verification methods for each driver. The first two columns show how to explicitly set the default method, the second one is identical, but shorter by making use of the default.
For further details, see below.
|Standard Verification (default - explicit)||Standard Verification (default - implicit)||Fingerprint-based Verification||No 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 CA.
If the certificate and the client's corresponding CA certificates are properly configured, then no additional configuration is necessary.
This method provides the highest level of security.
If creating a connection fails for any reason, an error message indicating the problem will be provided. Additionally, the fingerprint of the server's certificate will be provided in case the problem cannot be fixed, but the certificate should still be trusted using 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.
This method still provides some level of security, as opposed to simply disabling certificate verification entirely.
To employ this method, the fingerprint (SHA-256 hash) of the certificate is provided in the client's connection string following the host and a forward slash. Using this, the client can compare this given hash to the computed hash of the certificate received during the TLS handshake with Exasol. If the hashes match, the connection is allowed. If they do not match, the connection is rejected because the client assumes it is communicating with a host which is not allowed.
If creating a connection fails for any reason, an error message indicating the problem will be provided.
The fingerprint of the certificate currently in use by Exasol can be viewed in EXAoperation.
However, a certificate's fingerprint can also be generated manually using openssl. This could be useful as a manual check or, for example, if another certificate has been manually set using the Exasol parameter -tlsCertificatePath.
To directly generate the fingerprint without colons, the following can be used as well.
The fingerprint can be provided following the host and a '/' character. A port can then be specified following the fingerprint.
To use the fingerprint-based method with JDBC, the fingerprint should be provided in the connection string as described above.
To use the fingerprint-based method with ODBC, the fingerprint should be provided in the connection string as described above.
To use the fingerprint-based method with ADO.NET, the fingerprint should be provided in the connection string as described above.
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 actually connected to the specified server in the connection string. As such, this method is not recommended.
This method provides the lowest level of security.
To disable certificate verification with JDBC, the following parameter should be set in the connection string: validateservercertificate=0.
To disable certificate verification with ODBC, the following parameter should be set in the odbc.ini file: SSLCertificate=SSL_VERIFY_NONE.
To disable certificate verification with ADO.NET, the following parameter should be set in the connection string: SSLCertificate=VERIFYNONE.
Exasol driver-initiated connections (i.e. non-WebSocket connections) are supported in Exasol and all Exasol drivers as of version 7.1.0. Additionally, support for Exasol driver-initiated connections has been added to Exasol versions 6.2.15+ and 7.0.10+.
The compatibility matrix below provides an overview of TLS support.
|6.2 Driver encryption (ODBC, JDBC, ADO.NET)||7.0 Driver encryption (ODBC, JDBC, ADO.NET)||7.1.0+ Driver encryption (ODBC, JDBC, ADO.NET)||WebSocket encryption|
|Database Version Exasol 6.2.x||ChaCha20||ChaCha20||ChaCha20
TLS Support (6.2.15+)
|Database Version Exasol 7.0.x||ChaCha20||ChaCha20||ChaCha20
TLS Support (7.0.10+)
|Database Version Exasol 7.1.x||ChaCha20||ChaCha20
|TLS Support||TLS Support|
If a 7.1.0+ driver is used to connect to an Exasol version that does not support TLS, then the driver will automatically establish a connection using the legacy ChaCha20 encryption method. Since the driver doesn't know the database version before establishing the connection, the driver will always create a TLS connection first and then switch to the legacy ChaCha20 encryption protocol, if necessary, after receiving the version information from the Exasol. The TLS connection will be closed before opening the ChaCha20 connection.
Because a TLS connection is always created first, either the certificate must be valid, the check must be deactivated, or the fingerprint must be used. To avoid this and the additional TLS login, it is recommended to set the legacy encryption connection string parameter for older databases.
Also for the latest versions where TLS is the preferred method for encryption, ChaCha can still be used if necessary.
If for some reason the use of ChaCha20 is preferred to TLS, it can be manually enabled using the following settings.
|Legacy Encryption Parameter|
To connect to the server you have to use EXAServerConnect() like before. In 7.1.0 and newer SSL will the default encryption in the client-server communication.
You can use EXASetConnectAttr() to change the connection behavior by means of the following attributes:
|EXA_SOCKET_ENCRYPTION (string)||Can be "Y" or "N", default "Y"|
|EXA_SSL_CERTIFICATE (string)||A certificate file name or "SSL_VERIFY_NONE" or "SSL_VERIFY_SERVER". Default: "SSL_VERIFY_SERVER"|
|EXA_FINGERPRINT(string)||Fingerprint used for SSL server verification, default NULL|
|EXA_SSL_CA_PATH (string)||Path where to search for certificates, default NULL|
|EXA_USE_LEGACY_ENCRYPTION (string)||Can be "Y" or "N", default "N"|
The fingerprint can also be added to the host name used to connect, like in Exasol ODBC: "<my_host_nane>/<fingerprint_string>" as parameter to EXAServerConnect().
If nothing else specified, the driver will use the certificate from the system store, like ODBC does.
IMPORT / EXPORT from EXA also uses SDK and, therefore, starting from DB version 7.1.0 it requires certificate / fingerprint / legacy encryption.