Какая безопасность транспорта или безопасность сообщений?

У меня есть служба WCF, которая использует привязку net.TCP, и эту службу можно использовать внутри локальной сети или через Интернет.

Я читал, что net.TCP по умолчанию использует безопасность на транспортном уровне, но эта безопасность является точкой к точке, я думаю, что если я использую своего клиента из своей локальной сети, через Интернет, и для связи используется много точек, возможно, некоторые из этих точек не передать сообщение без защиты. Это правильно?

Так, если мне тоже нужна защита сообщений? Я могу использовать ssl-сертификат x509 для шифрования каждого сообщения, и он может быть расшифрован только моей службой, у которой есть закрытый ключ?

Есть ли какой-нибудь документ, объясняющий, как использовать сертификаты с привязкой net.TCP? Могу ли я использовать открытый SSL для создания сертификата и использования его с WCF?

Спасибо.


certificate openssl wcf nettcpbinding
person Álvaro García    schedule 01.04.2013    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Во-первых, оба подхода безопасны и их хватит на 90% случаев. Транспортная безопасность защищает ваш канал связи, но не шифрует ваше фактическое сообщение. Безопасность сообщений шифрует ваше фактическое сообщение, поэтому серверы, через которые оно передается, не могут видеть его содержимое, и им потребуется закрытый ключ для расшифровки ваших сообщений. Таким образом, можно утверждать, что безопасность сообщений более безопасна, по крайней мере, она больше подходит для интернет-общения. Несколько хороших ссылок по безопасности WCF: Безопасность сообщений в WCF и шаблоны и практики Руководство по повышению безопасности веб-служб < / а>

netTcpBinding по умолчанию использует безопасность транспорта, но это не значит, что вы не можете использовать с ним безопасность сообщений. Транспортная безопасность требует меньших затрат на вычисления, чем безопасность сообщений (где каждое сообщение зашифровано), поэтому она имеет лучшую производительность. Одно предостережение при использовании netTcpBinding через Интернет заключается в том, что его постоянная работа не может быть гарантирована (хотя в прошлом я successfully настраивал netTcpBinding через Интернет), поскольку он использует некоторые порты для передачи сообщений, которые не всегда гарантированно работают. оставлено открытым для сетевых маршрутизаторов и брандмауэров (через Интернет ваши сообщения будут проходить через множество маршрутизаторов и брандмауэров). Для интернет-связи рассмотрите одну из привязок HTTP, например basicHttpBinding или wsHttpBinding, которая также поддерживает безопасность сообщений.

Вы можете использовать безопасность сообщений, как и в других привязках:

<netTcpBinding>
    <binding name="securedBinding">
      <security mode="Message">
      </security>
    </binding>
</netTcpBinding>

а затем установите bindingConfiguration на конечных точках на securedBinding.

И на машине, на которой размещена ваша служба (сервер):

<behavoirs>
  <serviceBehavior>
    <behavior name="securityBehaviour">
      <serviceCredentials>
        <serviceCertificate
           findValue="serviceCert"
           storeLocation="LocalMachine"
           storeName="My"
           x509FindType="FindBySubjectName" />
      </serviceCredentials>
    </behavoir>
  </serviceBehavior>
</behavoirs>
<services>
  <service name="Service1"  behaviorConfiguration="securityBehaviour">
        <endpoint address="" binding="netTcpBinding" contract="IService1" bindingConfiguration="securedBinding">
        </endpoint>
  </service>
</services>

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

person Mohammad Sepahvand    schedule 01.04.2013