[coverage] Conformance findings: AUTH-012

Comienza con las pruebas xfail de AUTH-012 en tests/ en el PR de cobertura 1115 y compara el comportamiento previsto con el PR de referencia 463. Reproduce los casos de Thrift y SEA y, después, rastrea las rutas de conexión afectadas. La tarea estará terminada cuando ambos protocolos rechacen el certificado no fiable sin enviar OpenSession ni CreateSession, expongan un error relacionado con el certificado/TLS y eviten reintentos condenados al fracaso.

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