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

⚠️ 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.

Option 1) Standard Verification 

Show more

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 

Show more

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 

Show more

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 

Show more

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 

Show more

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: 

• 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).

[Hitesh_Sajnani]

@exa-BradleyJ,

Any answers to the aforementioned questions or any links to the existing documentation which answer the queries?

[exa-BradleyJ]

@Hitesh_Sajnani sorry for the delay in getting back to you. I am in the process of confirming the answers to your questions. I should be back soon.

[exa-BradleyJ]

@Hitesh_Sajnani sorry for the delay. Here are answers to your questions:

Question 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.

Answer

• If the client is using earlier version of the drivers (pre-7.1), they should default to ChaCha20, there should be no change necessary.
• If the client is using the 7.1 drivers, no changes would be required as this would be the default state and most recommended setup.

Question 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.

Answer

• I believe this is question comes up due to a poor choice of words by me. What I intended to say is "... you will need to either upload a CA generated certificate or make changes to the connection strings in your clients.". Given this is what you have done, there are no further changes required.

Question 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).

Answer

On this one, we would like to request that you open a Support ticket so that we may investigate. Please ensure that information related to the java version in use is included. You can open a ticket by visiting the Support Dashboard and clicking "Raise a bug or ask a question".

Please let us know of any further questions.

[Hitesh_Sajnani]

Thank you very much! 👍 @exa-BradleyJ .

[Hitesh_Sajnani]

@exa-BradleyJ,

For the 3rd point: "Error: [08001] Unexpected end of handshake data", I went through the Upload TLS Certificate documentation again.

I see that the documentation is updated, and I noticed the following point:

A self-signed or CA-signed TLS certificate using either RSA or ECC encryption algorithms:
If using RSA, the maximum key length is 2048 bits.

Perhaps, the line was present earlier also but I noticed it just now.

I was trying with key length 4096.

Created a self-signed certificate with key length 2048, and now the issue is resolved. 😀

[exa-BradleyJ]

Very glad to hear that. Please let us know of any further questions.

[exa-Nico]

@Hitesh_Sajnani you have a very keen eye 😉. Yes the documentation was updated a few days ago to specify that additional requirement. Sorry for the inconvenience it caused before though! 

[ugamarkj]

It is not clear to me how to use standard verification with clients like Tableau and DataGrip. I'm currently having to do a combination of option 2 and option 3. We got the cert for Exasol from an authority. Do I need to add the cert somewhere on the client machines too?