Different TLS default behaviour for JDBC, ODBC and other drivers
Hi,
Checking sessions system view, all ODBC connections are reporting SSL_state = Server, TLS_version=TLSv1.2. All JDBC connections reports SSL_state = None, and empty string for TLS_version.
All ODBC connections are from clients v12.0 and above, while JDBC connections are from v6 to 24.
It appears, ODBC driver by default behave opportunistically: if Server support TLS, it is using TLS, otherwise it does not use TLS.
JDBC driver, require special parameter in JDBC URL - tlsmode=require. Then it start using TLS, otherwise it is plain text.
That is "grossly" incorrect behaviour of JDBC driver, it should behave same way as ODBC driver: try to use TLS by default, and fallback to plain text if not possible.
Checking other drivers, most recent versions:
vsql, ODBC, OLE DB Driver, vsql and vertica-sql-go are by default doing TLS.
JDBC, vertica-python, Node.js are doing plain text by default.
"vertica connect" - CONNECT TO VERTICA - is doing TLS by default. Technically, it is not a client driver.
Please ask client team to review default TLS behaviour for JDBC, vertica-python, Node.js drivers. They should behave same as ODBC and other good drivers - by default try to use TLS, and if not possible, fallback to plain text. Current behaviour - always use plain text by default - is "not good".
Other question - I can see accidental vsql session that are not using TLS, for no apparent reasons - there are millions of vsql sessions and 0.0003% are non-TLS. I tend to think connections are not using TLS because of networking problems at time of establishing connection (???). Typically non-TLS vsql connections happens in short periods of time.
Any way I can force all client connections to use TLS for network transfer? Rolling out certificates to clients is not feasible, client authentication will not use TLS.
Thank you
Sergey