[coverage] Conformance findings: AUTH-012

Bắt đầu với các kiểm thử xfail AUTH-012 trong tests/ ở PR bao phủ 1115 và so sánh hành vi dự kiến với PR tham chiếu 463. Tái hiện các trường hợp Thrift và SEA, sau đó lần theo các đường dẫn kết nối bị ảnh hưởng. Hoàn tất có nghĩa là cả hai giao thức đều từ chối chứng chỉ không đáng tin cậy mà không gửi OpenSession hoặc CreateSession, hiển thị lỗi liên quan đến chứng chỉ/TLS và tránh các lần thử lại chắc chắn thất bại.

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