Connection when both "Force Enryption" and "Extended Protection" are active

Question

I’m trying to connect to a SQL Server (2012) using Windows Authentication where both Force Enryption is set to true and Extended Protection is set to required.

What I’m getting on the Client side is:

Login failed. The login is from an untrusted domain and cannot
be used with Windows authentication.
ClientConnectionId:<redacted>

Server side:

SSPI handshake failed with error code 0x80090346, state 46 while 
establishing a connection with integrated security; the connection 
has been closed. Reason: The Channel Bindings from this client are
missing or do not match the established Transport Layer Security (TLS) 
Channel. The service might be under attack, or the data provider
or client operating system might need to be upgraded to support
Extended Protection. Closing the connection. Client's supplied SSPI
channel bindings were incorrect
[CLIENT: <redacted>]

I’ve tried many different configuration options (client side) including:

• sslProtocol all options
• trustStore alongside trustStorePassword with a self signed cert
• trustServerCertificate
• serverSpn alongside corresponding server setting
• encrypt

All results in the same error combination. OS instances are identical on Windows Sever 2012 R2 latest SP.

Any hints would be highly appreciated.

Thanks Michael

[tkyc]

Just an update for those following the thread, we are still in the middle of investigating this.

From my initial investigation, to enable channel bindings in the driver I applied the following fix to the intAuthHandShake to KerbAuthentication.java file:

InetAddress initiator = InetAddress.getLocalHost();
InetAddress acceptor = InetAddress.getByName(con.activeConnectionProperties
                    .getProperty(SQLServerDriverStringProperty.SERVER_NAME.toString()));

ChannelBinding cb = new ChannelBinding(initiator, acceptor, null);
peerContext.setChannelBinding(cb);

However, the above change doesn’t seem to have an impact and I still receive the login error. I’ll continually post updates as I investigate.

Updates (I’ll post brief updates in this post to avoid spam)

• Aug 17th 2022 - Issue is still on my radar, investigating the difference between the JDBC driver and other drivers to narrow down cause
• Sep 12th 2022 - This might not seem as trivial to implement as I initially thought. From what I learned, the channel binding negotiation needs to happen during the TLS handshake (not after, which was what I was doing). When I looked at how the other drivers implemented this, they all used native cpp code to do so through the SSPI api which takes care of TLS and channel binding altogether. Doing so natively in Java (what we want) isn’t as straightforward, as there isn’t an equivalent existing api that takes care of TLS and channel binding altogether (likely it will be a solution from scratch, which I’m still researching on since I have zero domain knowledge on this topic).
• Sep 19th - After more research, I found out that bc-java provides a channel binding API. Using this API I fetched the CBT for tls-unique (from looking at other drivers, that’s the tls channel binding type). However, login is still failing. I’m still trying to understand the reason.
• Sep 20th - Channel binding for NTLM is working. I’m still in progress of trying to get it working for kerberos.

[michaelenglert]

Hi @cheenamalhotra

Thanks. I really appreciate that you took the time to investigate this!!

Does it make sense to convert this question to an enhancement request then?!

Thanks again Michael