[coverage] Conformance findings: AUTH-012

从 coverage PR 1115 中 tests/ 下的 AUTH-012 xfail 测试开始，并将预期行为与参考 PR 463 进行比较。重现 Thrift 和 SEA 用例，然后跟踪受影响的连接路径。完成标准是两个协议都拒绝不受信任的证书，不发送 OpenSession 或 CreateSession，暴露证书/TLS 相关错误，并避免注定失败的重试。

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