[coverage] Conformance findings: AUTH-012

Start with the AUTH-012 xfail tests under tests/ in coverage PR 1115 and compare the intended behavior with reference PR 463. Reproduce the Thrift and SEA cases, then trace the affected connection paths. Done means both protocols reject the untrusted certificate without sending OpenSession or CreateSession, expose a certificate/TLS-related error, and avoid doomed retries.

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-nodejs. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-nodejs) is fixed, then flips green as a tripwire.

Findings

• AUTH-012 [thrift]: Thrift path accepts a server certificate that chains to nothing in its trust set: the connection succeeds and one OpenSession (carrying the bearer token) reaches the untrusted MITM endpoint, so server-certificate verification is not on by default on the proxied Thrift transport
  • failing test: server certificate validation is enabled by default [thrift] [xfail] (see the coverage PR diff under tests/)
• AUTH-012 [sea]: SEA/kernel rejects the untrusted certificate (0 CreateSession on the wire) but surfaces only the opaque 'HTTP request failed after 5 attempts: error sending request for url (...)' with no certificate/TLS reason in the error or its cause chain, and retries the doomed handshake 5x
  • failing test: server certificate validation is enabled by default [sea] [xfail] (see the coverage PR diff under tests/)
• AUTH-012: Thrift path accepts a server certificate that chains to nothing in its trust set: connecting through an interception proxy whose CA is absent from the trust configuration succeeds and sends OpenSession (with the bearer token) to the untrusted peer, so server-certificate verification is not enabled by default on the proxied Thrift transport
• AUTH-012: SEA/kernel correctly rejects an untrusted server certificate (no CreateSession is sent) but reports it as the opaque "HTTP request failed after 5 attempts: error sending request for url (...)" with no certificate/TLS reason in the error or its cause chain, and retries the doomed handshake 5 times, so callers cannot distinguish a TLS trust failure from a network outage

Reproduce & Expected

AUTH-012 — Verifies the driver is secure-by-default: with NO TLS options supplied, the driver performs full chain + hostname verification of the server certificate, and a server whose certificate does NOT chain…

Expected (per the shared spec):

• [thrift] exactly 0 OpenSession call(s)
• [sea] exactly 0 CreateSession call(s)
• full assertion contract:

result:
- error:
    contains:
    - certificate
    - cert
    - self-signed
    - self signed
    - unable to verify
    - unable to get local issuer
    - tls
    - ssl
    - handshake
protocol:
  thrift:
  - call_count:
      method: OpenSession
      expected: 0
  sea:
  - call_count:
      operation: CreateSession
      expected: 0

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-sql-nodejs/pull/463 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-nodejs; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1115