Безопасность сообщений WCF без сертификата и windows auth

У меня есть служба WCF и клиент, который будет развернут в нескольких компаниях (сотни). Некоторые компании будут запускать программное обеспечение в своей сети, а некоторые будут запускать его через Интернет (сервер WCF на офисе, клиент WCF - на другой).

Мы хотим зашифровать связь между сервером WCF и клиентом. У нас нет никакой потребности в аутентификации пользователя/подписчика с использованием безопасности WCF, потому что у нас есть свое собственное имя пользователя/пароль, к которому клиенты будут использовать для входа на сервер.

Мы не можем полагаться на Windows auth, потому что некоторые пользователи будут запускать его через Интернет, а сервер WCF может находиться не в том же домене, что и клиент WCF.
Если мы используем "реальные" сертификаты *, компаниям, использующим программное обеспечение, придется приобретать сертификаты из ЦС и устанавливать их, а затем настраивать наше программное обеспечение для его использования, но это слишком сложно для большинства из них.
Мы могли бы автоматически создавать сертификаты во время установки WCF-сервера, но тогда нам пришлось бы автоматически устанавливать его в хранилище сертификатов и как-то автоматически предоставлять разрешения IIS для чтения сертификата. Это сложнее, чем хотелось бы.

Короче говоря, нам нужно простое решение, в котором шифрование основано только на секретном, в нашем случае имя пользователя/пароль, с которым пользователь входит в систему. Я понимаю, что это не даст наилучшего доступного шифрования, но мы готовы обменять часть безопасности, чтобы упростить развертывание программного обеспечения.

Возможно ли это?

* С "реальными" сертификатами я имею в виду сертификаты, приобретенные у центра сертификации, а не те, которые я создал сам/самостоятельно.

Ответ 1

Если вы хотите зашифровать сообщения на транспорте (это действительно хорошая идея!), должны существовать некоторые общие знания между отправителем (клиентом) и сервером. Это может быть жестко запрограммировано, но это действительно не очень хорошая идея - если это "общее общее" знание когда-либо скомпрометировано, злоумышленник может расшифровать и прочитать все ваши сообщения.

Кроме того, поскольку это определенно не рекомендуемая практика, в WCF нет никакой поддержки для упрощения использования общего секрета. Вы сами по себе - вам нужно катиться на 100%.

только жизнеспособный способ иметь общий общий секрет, безопасно замененный, - это использовать сертификат. Ни в коем случае, извините. Сертификат даже не должен использоваться для аутентификации пользователя или чего-либо еще, но он устанавливает общий секрет между вызывающим абонентом и службой и, таким образом, позволяет вызывающему абоненту шифровать сообщения таким образом, что только предполагаемый получатель может фактически расшифровать и использовать их.

Таким образом, я действительно не вижу, как вы можете обойтись с сертификатами на своих серверах - не обязательно на каждом клиенте, но на каждом сервере, на котором работает ваш сервис.

Марк

PS: если вы действительно хотите изучить подход "жестко закодированный общий секрет", вам нужно подумать об этом:

Как вы храните общий секрет безопасно для каждого из ваших клиентов?
как вы используете информацию из сохраненного общего секрета для шифрования ваших сообщений?

Как правило, подход будет двояким:

обменять какую-либо форму частной/открытой пары ключей; сервер генерирует пару ключей и сохраняет закрытый ключ для себя и разделяет открытый ключ с клиентом (например, над сообщением WCF, например).
используя эту частную/открытую пару ключей, обмениваются общим общим секретом, например. "ключ шифрования", который будет симметрично шифровать ваши сообщения (и поскольку он симметричен, сервер может использовать один и тот же ключ для дешифрования сообщений).
настроить инфраструктуру на вашем клиенте (например, расширение WCF, называемое поведением), чтобы проверить сообщение до его выхода и зашифровать его с помощью общего секретного

В целом, это действительно не тривиально - ничего проще, чем это не стоит называть "безопасностью" вообще.

Если вы посмотрите на всю эту работу, вам придется делать - не будет ли проще использовать встроенные механизмы сертификации WCF?

Достойная безопасность, стоящая на ее соли , тяжелая - поэтому почему бы не использовать то, что доступно, а не делать всю работу самостоятельно или, что еще хуже: придумать полубеленое решение, которое так легко взломать можно так же легко отправить все в cleartext..... не оценивайте сложность и количество кода, необходимого для обработки даже самых основных сценариев безопасности - WCF делает все это для вас - бесплатно и надежно и безопасно - используй это! Вы не пожалеете об этом!

Ответ 2

Ну, с WCF вы можете использовать учетные данные паролей на уровне сообщений и SSL на уровне транспорта, чего, как мне кажется, будет достаточно в вашем случае.

Смотрите здесь.

Ответ 3

Для обеспечения безопасности сообщений клиент предоставляет некоторые учетные данные, а сервер предоставляет некоторые учетные данные. Для этой настройки и с помощью вашего сценария вы не можете использовать имя пользователя и пароль клиента с помощью Custom User Validator и сертификата сервера для предоставления сервера полномочия. Этот Application Scenario обеспечивает справедливую последовательность настройки конфигурации, которая вам нужна для этого, за исключением разделов членства aspNet, которые вам придется заменить с вашей настраиваемой конфигурацией проверки.

Вам все равно понадобятся действительные сертификаты на ваших серверах (сертификаты не требуются для клиентов), но я не вижу никакого способа обойти это.

Ответ 4

Взгляните на следующий пример:

http://www.codeproject.com/KB/WCF/wcfcertificates.aspx

Он использует сертификаты, но без хранилища сертификатов, поэтому настройка не требуется.

Ответ 5

Хм.. может быть, что-то простое может быть использовано. Переместите шифрование с программного обеспечения на оборудование. VPN от каждой клиентской сети до вашей собственной, а затем вы можете делать все, что хотите для транспорта WCF. Строка не является четким текстом, и проблема решена.

Конечно, это проще сказать, чем сделать, но большинство сетевых поставщиков предоставляют довольно простой VPN-конфигуратор, и, возможно, это проще, чем пытаться разработать установщик для сертификатов SSL и настроить клиента.

Надеюсь, это поможет!