+@Mat Carter<mailto:[email protected]> and @Martijn Verburg<mailto:[email protected]>
________________________________ From: Divang Sharma <[email protected]> Sent: Monday, May 18, 2026 11:05 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; Mahendra Chavan <[email protected]>; David Engel <[email protected]>; Sunil Kumar B.S <[email protected]>; Saurabh Singh (SQL Drivers) <[email protected]> Subject: Proposal: Add tls-unique Channel Binding to SSLSession for TLS 1.2 (RFC 5929) Hi everyone, My name is Divang Sharma, and I work at Microsoft on the SQL Server JDBC driver team. I'm reaching out to propose adding tls-unique channel binding support to `javax.net.ssl.SSLSession` for TLS 1.2 connections. Problem Statement Java applications currently lack access to tls-unique channel binding data (RFC 5929, Section 3) for TLS 1.2 connections. This prevents implementing Extended Protection<https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/connect-to-the-database-engine-using-extended-protection?view=sql-server-ver17> for database authentication. This gap is particularly problematic for: SQL Server * Requires tls-unique channel binding tokens to prevent NTLM relay attacks * SQL Server supports tls-unique, making TLS 1.2 the primary use case Current Situation Other platforms already provide this capability: .NET: Available since .NET Framework 3.5 via `TransportContext.GetChannelBinding` Java is missing this fundamental security capability. Proposed Solution Add a method to `javax.net.ssl.SSLSession` to expose tls-unique channel binding: public interface SSLSession { /** * Returns the tls-unique channel binding value for this session. * Only available for TLS 1.2 and earlier (RFC 5929). * * @return the tls-unique channel binding bytes, or null if not * available (e.g., TLS 1.3 or no handshake completed) / byte[] getTlsUniqueChannelBinding(); * } Scope: TLS 1.2 Only This proposal focuses specifically on tls-unique for TLS 1.2 because: * SQL Server Extended Protection requires tls-unique channel binding * TLS 1.3 already provides `SSLSocket.exportKeyingMaterial()` for tls-exporter * TLS 1.2 remains widely deployed in enterprise environments * A focused change is simpler to review and maintain Implementation Approach The implementation would: * Store the TLS Finished message `verify_data` during the TLS 1.2 handshake * Return the concatenated client/server `verify_data` as defined in RFC 5929 * Return `null` for TLS 1.3 (not defined per RFC 7627) * Return `null` if the handshake has not completed or the session is invalid * Have zero performance impact when the API is not used Questions 1. Are there any concerns with the proposed API design? 2. Would anyone be willing to sponsor this work? Background * OCA: Signed and under review (submitted 2026-05-14) * GitHub: `@divang` * Work: Microsoft SQL Server JDBC team I’m happy to provide more details, implement the changes, and contribute comprehensive tests. I’m also open to feedback and alternative approaches. Looking forward to your thoughts. Thanks, Divang Sharma [email protected]
