Как NetTcpBinding (читать WindowsStreamSecurityBindingElement) шифрует / подписывает сообщения?

Question

Я хотел понять механизм шифрования и подписи сообщений, используемый NetTcpBinding, когда учетные данные «Windows» используются с безопасностью транспорта. Что если моя AD использует NTLM вместо Kerberos? Будут ли сообщения по-прежнему подписываться и шифроваться? Если да, то как?

Заранее спасибо,

Akshat

Answer 1

Краткий ответ: да, при проверке подлинности NTLM сообщения по-прежнему будут подписываться и шифроваться, если вы установили уровень защиты транспорта Transport для EncryptAndSign (по умолчанию).

Вот схема того, как это работает:

• выбор транспортной безопасности настраивает WindowsStreamSecurityBindingElement в стеке каналов. Это вставляет поставщик обновления потока (см. ниже)
• в NetTcpBinding, сообщение обмен между клиентом и служба происходит в сообщении .NET Протокол кадрирования , который обеспечивает как создание сообщений и механизм для клиент и сервис для ведения переговоров обновления потока, основное использование который должен установить транспорт безопасность. Если есть поток провайдер обновления настроен в стек каналов, это будет вызвано на этапе преамбулы Протокол кадрирования, когда клиент открывает канал.
• обновление поставщик для WindowsStreamSecurityBindingElement вызывает рукопожатие SSPI между клиентом и сервером с использованием пакета безопасности SPNEGO: в NetTcpBinding это обычно приводит к тому, что Kerberos выбирается в качестве основного поставщика безопасности, если доступно, но выбирает NTLM, если нет.
• если NTLM является полученным поставщиком аутентификации, квитирование SSPI будет включать в себя обмен токенами запрос-ответ NTLM с тремя участками, описанными в спецификации NTLM . Этот протокол включает в себя механизм обмена ключами для подписи и шифрования сообщений. Как только квитирование SSPI сгенерировало соответствующий контекст безопасности, после этого все обмениваемые сообщения подписываются и шифруются в поставщике обновления потока стека канала-отправителя, а в каждом случае дешифруются и проверяются в поставщике обновления потока стека канала-получателя с использованием обращений к NTLM. провайдер безопасности через абстрактные функции поддержки сообщений SSPI .

Answer 2

Это правильная реализация Microsoft, которая не документирована должным образом и, возможно, специально для того, чтобы не позволить злоумышленникам воспользоваться ею.

Насколько я знаю, это обычно происходит на уровне TCP, при этом специальный токен генерируется учетными данными пользователя и передается вместе с запросом. Это перехватывается каналом безопасности Windows и аутентифицируется по AD.

Этот токен используется в качестве ключа (или в качестве основы для генерации ключа) для шифрования связи.

Я думаю, что если вы посмотрите на пакет TCP, вы должны увидеть токен - хотя я никогда не видел его.

Answer 3

Если вы делаете все это в коде, то вы можете найти опции здесь (поиск «NetTcpBinding»). Транспортная безопасность обеспечивается через встроенный в Windows TLS .

Диаграмма здесь должна быть полезной для вашего сценария.