You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ca, cert, and key are passed through, but with rejectUnauthorized: false the server certificate is never actually validated, so supplying a CA has no effect on verification. Every connection made through DBSQLClient.connect() on the Thrift path — including OAuth bearer-token traffic — accepts any certificate (self-signed, expired, wrong hostname).
Impact
A misrouted DNS/PrivateLink path or an on-path attacker who can terminate TLS receives bearer-authenticated requests without triggering any client-side error. For a driver that carries workspace credentials this is a significant silent weakening of transport security, and it is not documented on ConnectionOptions.
Expected behavior
Either of:
Verify by default — matching Node's own https default, the JDBC/ODBC drivers, and the kernel/SEA backend added in 2.0.0 (which, per its typings, verifies the chain and hostname by default) — with an explicit opt-out for users who need permissive behavior.
I understand from the history of #407 that the permissive default was kept deliberately for backwards compatibility, but right now strict verification is not even possible on the Thrift path — that seems worth fixing independently of the default. #197 is related (surfacing agent TLS settings publicly) but does not cover the hardcoded rejectUnauthorized.
Environment
@databricks/sql 2.0.0 (also present on current main)
Node.js 22.x
Workaround
We currently patch the package (via patch-package) to set rejectUnauthorized: true, which works because Databricks endpoints present publicly trusted certificates — but a supported option would be much better.
Body:
Description
The default (Thrift) backend builds its HTTPS agent with certificate verification disabled, and there is no public option to turn it on:
https://github.com/databricks/databricks-sql-nodejs/blob/main/lib/connection/connections/HttpConnection.ts#L68-L77
ca,cert, andkeyare passed through, but withrejectUnauthorized: falsethe server certificate is never actually validated, so supplying a CA has no effect on verification. Every connection made throughDBSQLClient.connect()on the Thrift path — including OAuth bearer-token traffic — accepts any certificate (self-signed, expired, wrong hostname).Impact
A misrouted DNS/PrivateLink path or an on-path attacker who can terminate TLS receives bearer-authenticated requests without triggering any client-side error. For a driver that carries workspace credentials this is a significant silent weakening of transport security, and it is not documented on
ConnectionOptions.Expected behavior
Either of:
httpsdefault, the JDBC/ODBC drivers, and the kernel/SEA backend added in 2.0.0 (which, per its typings, verifies the chain and hostname by default) — with an explicit opt-out for users who need permissive behavior.ConnectionOptions(e.g. thecheckServerCertificate/customCaCertoptions that [SEA-NodeJS] Kernel backend: connection/statement options, TLS & configurable sync/async execution #416 added for the SEA path) so callers can require strict validation on the Thrift path without patching the package.I understand from the history of #407 that the permissive default was kept deliberately for backwards compatibility, but right now strict verification is not even possible on the Thrift path — that seems worth fixing independently of the default. #197 is related (surfacing agent TLS settings publicly) but does not cover the hardcoded
rejectUnauthorized.Environment
@databricks/sql2.0.0 (also present on currentmain)Workaround
We currently patch the package (via patch-package) to set
rejectUnauthorized: true, which works because Databricks endpoints present publicly trusted certificates — but a supported option would be much better.