How does NetTcpBinding (reading WindowsStreamSecurityBindingElement) encrypt / sign messages?

Question

I wanted to understand the mechanism for encrypting and signing messages used by NetTcpBinding when Windows credentials are used with transport security. What if my AD uses NTLM instead of Kerberos? Will messages still be signed and encrypted? If so, how?

Thanks Advance,

Akshat

Answer 1

The short answer is that, yes, with NTLM authentication, messages will still be signed and encrypted if you set the Security SecurityLevel value for security to EncryptAndSign (by default).

It describes how this works:

• Choosing transport security configures the WindowsStreamSecurityBindingElement in the channel stack. This inserts (see below)
• In the NetTcpBinding message, the message exchange between the client and the service takes place in the .NET Message Framing Protocol , which provides both message generation and the client and service negotiation mechanism for stream modernization, the main use of which is to establish transport security. If there is a stream of the update provider configured on the channel stack, this will be called during the pre-development phase of the Framing Protocol when the client opens the channel.
• updating the provider for WindowsStreamSecurityBindingElement causes an SSPI connection between the client and server using the SPNEGO security package: in NetTcpBinding, this usually causes Kerberos to be selected as the primary security provider, if available, but will choose NTLM if not.
• If NTLM is the resulting authentication provider, SSPI handshaking will be associated with the NTLM three-legged NTLM token exchange described in the NTLM specification . This protocol includes a key exchange mechanism for signing and encrypting messages. After the SSPI handshake has formed the appropriate security context, then all exchanged messages are signed and encrypted in the update channel provider of the stack channel of the transmitting channel and decrypted and checked in the update provider of the stream stack channel of the receive channel, in each case, using calls to NTLM security provider through the abbreviation SSPI message support features .

Answer 2

This alignment with Microsoft is not documented and perhaps specifically designed to prevent attackers from taking advantage of it.

As far as I know, this usually happens at the TCP level, with a special token generated by the user credentials and transmitted along with the request. It is intercepted by the Windows security channel and authenticates against AD.

This token is used as a key (or as a basis for generating a key) for encrypting communications.

I think that if you look at the TCP packet, you should see the token, although I have never seen it.

Answer 3

If you do all this in code, you can find it here (search for "NetTcpBinding"). Transport security is provided through Windows builtin TLS .

The diagram here should be useful for your scenario.