Pregunta ¿Cómo encripta / firma NetTcpBinding (leer WindowsStreamSecurityBindingElement)?


Quería entender el mecanismo de cifrado y firma de mensajes utilizado por NetTcpBinding cuando las credenciales de "Windows" se usan con la seguridad de transporte. ¿Qué sucede si mi AD usa NTLM en lugar de Kerberos? ¿Los mensajes aún se firmarán y codificarán? De ser así, ¿cómo?

Gracias por adelantado,

Akshat


7
2017-11-15 18:31


origen


Respuestas:


La respuesta corta es que, sí, con la autenticación NTLM los mensajes seguirán siendo firmados y encriptados si ha configurado la seguridad de transporte ProtectionLevel en EncryptAndSign (el valor predeterminado).

Aquí hay un resumen de cómo funciona:

  • seleccionando Seguridad de transporte configura una WindowsStreamSecurityBindingElement en la pila de canales. Esto inserta un proveedor de actualización de flujo (ver a continuación)
  • en NetTcpBinding, mensaje intercambio entre el cliente y el servicio ocurre dentro del Mensaje de .NET Protocolo de encuadre, que proporciona ambos estructura de mensaje y un mecanismo para cliente y servicio para negociar actualizaciones de la corriente, el uso principal de que es establecer el transporte seguridad. Si hay una transmisión proveedor de actualización configurado en pila de canales, esto será invocado durante la etapa de Preámbulo de la Protocolo de trama cuando el cliente abre el canal
  • la actualización proveedor de WindowsStreamSecurityBindingElement invoca un protocolo de enlace SSPI entre el cliente y el servidor utilizando el paquete de seguridad SPNEGO: en NetTcpBinding esto normalmente dará como resultado que se seleccione Kerberos como el proveedor de seguridad subyacente, si está disponible, pero elegirá NTLM si no.
  • si NTLM es el proveedor de autenticación resultante, el protocolo de enlace SSPI implicará el intercambio NTLM de tres patas de intercambio de tokens descrito en la especificación NTLM. Este protocolo incluye un mecanismo para intercambiar claves para la firma de mensajes y el cifrado. Una vez que el intercambio de SSPI ha generado un contexto de seguridad apropiado, todos los mensajes intercambiados se firman y encriptan en el proveedor de actualización de flujo de la pila emisora, y se descifran y verifican en el proveedor de actualización de flujo de la pila receptora, utilizando llamadas al NTLM proveedor de seguridad a través de la abstraída Funciones de soporte de mensajes de SSPI.

8
2017-11-17 23:22



Esta es una implementación de propiedad de Microsoft y no está debidamente documentada y tal vez a propósito para evitar que los intrusos la aprovechen.

Por lo que yo sé, esto generalmente ocurre en el nivel de TCP con un token especial generado por las credenciales del usuario y pasado junto con la solicitud. Esto es interceptado por el canal de seguridad de Windows y autenticado contra el AD.

Este token se usa como clave (o como base para generar la clave) para encriptar la comunicación.

Creo que si miras el paquete TCP, debes poder ver el token, aunque nunca lo haya visto.


1
2017-11-15 19:46



Si estás haciendo todo esto en código, entonces puedes descubrir las opciones aquí (busque 'NetTcpBinding'). La seguridad del transporte es a través de Windows TLS integrado.

El diagrama aquí debe ser útil para su escenario.


0
2017-11-15 18:55