Почему включить SSL (безопасность транспорта) через net.tcp намного сложнее, чем HTTP?

Реализовать веб-службу, использующую безопасность транспортного уровня с WCF через HTTP, довольно просто: Включить SSL для моей службы WCF

Реализовать веб-службу, использующую безопасность транспортного уровня с WCF через net.tcp, довольно сложно: WCF с netTcpBinding и безопасностью транспорта сертификатов

... и решение net.tcp обычно включает что-то подобное как на стороне сервера, так и на стороне клиента:

 <serviceCertificate
       findValue="MyServiceCertificate"
       storeLocation="LocalMachine"
       storeName="My"
       x509FindType="FindBySubjectName" />

В случае с HTTP вам даже не нужно упоминать сертификат ни на клиенте, ни на сервере. В случае NET.TCP вы должны хранить, находить и указывать сертификат как на клиенте, так и на сервере в большинстве источников, которые я читал.

Что делает волшебство, благодаря которому вам не нужно беспокоиться о сертификатах в режиме HTTP? И почему эта магия недоступна вам при использовании net.tcp?


ssl .net wcf nettcpbinding
person Greg Smalter    schedule 22.06.2011    source источник
comment
Есть ли какая-то конкретная причина, по которой вы не можете использовать защиту на уровне сообщений?   -  person Oliver Weichhold    schedule 22.06.2011
comment
Нет конкретной причины, по которой мы не можем использовать безопасность на уровне сообщений. Однако я не знаю, почему это было бы проще реализовать.   -  person Greg Smalter    schedule 23.06.2011

Ответы (2)


arrow_upward
6
arrow_downward

Потому что при использовании WCF поверх HTTPS; IIS управляет согласованием с сертификатами (как и простой SSL). Поскольку нет IIS-сервера со встроенным для TCP, вам придется сделать это самостоятельно. Вы все еще работаете с сертификатами + WCF для HTTPS, но настройка выполняется в IIS.

ИЗМЕНИТЬ:

Для клиентской стороны у вас все еще есть другое программное обеспечение. При просмотре веб-сайта через SSL браузер обрабатывает все это за вас. SSL через HTTP имеет стандартный шаблон согласования, поскольку он является частью протокола HTTPS. Для TCP это не является частью протокола, поэтому клиент должен позаботиться об этом сам.

person vcsjones    schedule 22.06.2011
comment
Это была моя гипотеза на стороне сервера, но она объясняет только сторону сервера. Это не объясняет, почему на стороне клиента дела обстоят сложнее. Почему во всех примерах, которые я прочитал, сертификат хранится в клиентском хранилище и вызывается SetCertificate (как здесь)? - person Greg Smalter; 23.06.2011
comment
Это почти имеет смысл, за исключением двух пунктов. Во-первых, это правда, что браузер обрабатывает все это за вас, но даже если вы не используете браузер (просто приложение Windows Forms с клиентским кодом WCF), он все равно позаботится об этом за вас. Итак, Microsoft должна заниматься этим за нас. Они просто решили не заниматься этим за нас в случае с net.tcp? Наконец, если вы примете все это, то, похоже, дополнительная работа для TCP будет заключаться в реализации вашей собственной обработки сертификатов. Вместо этого мы видим людей, у которых на клиенте установлен новый сертификат, которого даже нет в случае HTTP. - person Greg Smalter; 24.06.2011
comment
@Greg: Microsoft не заботится об этом за вас. Сама природа протокола HTTPS заключается в поддержке согласования. Это часть стандарта, все согласны с тем, как это работает. Однако TCP не имеет такой спецификации, это протокол более низкого уровня. Могла ли Microsoft сделать это за вас? Конечно. Но это затруднило бы взаимодействие. Лучше просто позволить клиенту справиться с этим самостоятельно. SSL имеет спецификацию временных ключей; поэтому клиенту не нужно устанавливать его постоянно. - person vcsjones; 24.06.2011

arrow_upward
0
arrow_downward

Я тоже чертовски боролся с этим и теперь наконец чувствую себя идиотом. Что приятно, потому что это означает, что я действительно понимаю кое-что, над чем раньше просто ломал голову.

При внедрении вашего сервиса ваша цель - защитить связь с помощью SSL. Вам также необходимо иметь возможность сгенерировать файл reference.cs в Visual Studio. Проблема в том, что вы также подключаете обмен метаданными к SSL. Инструменты генерации кода не позволяют вам настроить необходимые разделы конфигурации netTcpBinding для вызовов, которые выполняются для получения метаданных, когда они используются для создания файла reference.cs.

Вы должны создать две отдельные конфигурации привязки в netTcpBinding, одну для вашей службы с:

<security mode="TransportWithMessageCredential">
    <message clientCredentialType="Certificate"/>
</security>

config внутри и еще один с:

<security mode="None" />

вместо. Убедитесь, что все остальные параметры совпадают и конечная точка для вашей службы указывает на ssl bindingConfig, в то время как конечная точка метаданных указывает на отсутствие привязки SSL. После этого вы сможете читать метаданные и снова обновлять ссылку на сервис.

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

person steve    schedule 12.11.2014