Exasol 7.1 - Connection Security Changes

[exa-BradleyJ]

• Overview
• The Change
• Reasoning
• Impact
• Action Required
• Resources

 

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

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.

Option 1) Standard Verification 

Spoiler

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:  

• on-premise  
• AWS  
• Azure  
• GCP (Google Cloud Platform) 

Option 2) Fingerprint-based Verification 

Spoiler

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

Option 3) Disabling Verification 

Spoiler

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

Option 4) Legacy Encryption 

Spoiler

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

 Option 5) Turn off encryption 

Spoiler

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

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: 

• JDBC 
• ODBC  
• ADO.NET 

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 

[Hitesh_Sajnani]

@exa-BradleyJ,

1. If a certificated signed by an officially recognized certificate authority is uploaded to Exasol 7.1 instance using EXAoperation, does client need any configuration?
   • In our case, clients will need to connect to the Exasol server using jdbc driver and odbc driver.
     
   • And making changes to the connection strings in clients is less feasible.

2. As mentioned in "Action Required" section: 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. 

   • What changes are required to the self-signed certificate? Kindly provide details.
   • As stated making changes to the connection strings in clients is less feasible.
3. I'm experimenting with the self-signed certificates in local environment. After uploading a self-signed certificate to Exasol 7.1.0, while connecting to the server using EXAplus results in the following error:

EXAplus-7.1.0$ java -jar exaplus.jar
EXAplus 7.1.0 (c) EXASOL AG

User (....): sys
Password: ******
Connection String (localhost:8563): 192.168.1.71/D4F80C16858EBA15ECC38E23FEBFEB7F8264422A940376C20EC4546D8E465958:8563

Error: [08001] Unexpected end of handshake data

Note that the fingerprint is correct and it is same as the one which is shown in EXAoperation portal. Also before uploading a self-signed certificate, the same EXAplus connectivity was working with the help of the earlier fingerprint generated by the Exasol instance by default (in initial state).