On Fri, 23 Oct 2026 02:34:32 GMT, Alexey Bakhtin <[email protected]> wrote:
> Please review a fix that makes the SSPI bridge pass channel bindings to > `InitializeSecurityContext`. > > `gss_init_sec_context` in `sspi.cpp` receives `input_chan_bindings`, but > never passes a `SECBUFFER_CHANNEL_BINDINGS` buffer to > `InitializeSecurityContext`. A server that requires channel binding (for > example IIS with Extended Protection "Always") rejects the Kerberos token, > and the client gets 401. > > The patch adds `convert_chan_bindings`. It builds a `SEC_CHANNEL_BINDINGS` > blob from `input_chan_bindings` and passes it as an extra input buffer on > every call, unless the caller passes `GSS_C_NO_CHANNEL_BINDINGS`. > > The patch proposed in the bug report fails with `SEC_E_UNSUPPORTED_FUNCTION` > when either address is non-empty. This patch copies the initiator and > acceptor address types and bytes into the structure instead, for two reasons: > > - The built-in TLS binding (`TlsChannelBindingImpl`) has no addresses (type > 0, empty). But `org.ietf.jgss.ChannelBinding(InetAddress, InetAddress, > byte[])` is public API, so applications can set addresses. The pure-Java > Kerberos initiator supports that, and rejecting it would make the native > bridge behave differently. > - The Kerberos checksum carries an MD5 over the address types, lengths, > address bytes and application data (RFC 4121 section 4.1.1.2). The acceptor > hashes whatever it was given, so dropping the addresses would make the hashes > differ. > > The address type is copied even when the address is empty, because it is part > of the hash. TLS uses 0 and other bindings use `GSS_C_AF_NULLADDR` (255). > These are set by `newGSSCB`. > > **Testing.** > Verified on a non-domain-joined Windows 11 machine. An MIT KDC (realm > TEST.LOCAL) runs in WSL. A Java HTTPS server (Java GSS, SPN > `HTTP/host.test.local`) enforces channel binding with the > `tls-server-end-point` hash of its certificate, to mimic IIS Extended > Protection "Always". The client is `HttpsURLConnection`, started with `runas > /netonly`, `-Dsun.security.jgss.native=true` and > `-Djdk.https.negotiate.cbt=always`. > > The client runs in three modes: > (A) baseline, > (B) A plus `-Djavax.security.auth.useSubjectCredsOnly=false`, > (C) B with no Authenticator and a browser-style User-Agent, as in the bug > report. > > - Without the fix, all three failed with `GSSException: Channel binding > mismatch (Mechanism level: Token missing ChannelBinding!)`. > - With the fix, all three passed (`Auth SUCCESS - client: > [email protected]`). > > --------- > - [X] I confirm that I make this contribution in accordance with t... The fix looks like it addresses the associated bug and has been implemented correctly. I'm in the process of verifying your solution and should have results later this week. Thank you for your contribution! ------------- PR Comment: https://git.openjdk.org/jdk/pull/33528#issuecomment-6622817171
