Как проверить, использует ли приложение толстого клиента на основе WPF Transport Layer Security(TLS) или нет

У нас есть настольное толстое клиентское приложение на базе Windows с внешним интерфейсом, созданным на основе WPF+Telerik, и внутренним обменом данными с использованием веб-служб WCF.

Сейчас общение происходит через SSL3.0

Из-за недавних проблем безопасности с SSL3.0 было решено использовать TLS 1.2 или TLS 1.1 на стороне сервера, чтобы форсировать весь обмен данными только через TLS.

Мы попытались проверить основную связь с веб-сервисом, используя Fiddler и Wireshark. Мы можем видеть, что 200 запросов "Tunnel to" происходят по TLS.

Но есть ли другой способ перекрестной проверки, если TLS явно или неявно используется приложением Thick Client для запросов Web Service...?

Windows установила исправление TLS 15 декабря 2014 г., и оно установлено на серверах приложений Windows 2008 R2. SSL3.0 еще не отключен как запасной вариант, но явно TLS не включен. Но статьи MS KB говорят, что TLS будет иметь приоритет (TLS1.2>TLS1.1>TLS1.0>SSL3.0)

Обновление безопасности (статья базы знаний KB2992611, за которым следует другое обновление KB3018238) было установлено 9 декабря 2014 года, и оно было установлено с помощью HP Monthly Patching 15 декабря 2014 года 
Пожалуйста, проверьте следующие ссылки для более подробной информации о патчах безопасности и их влиянии. Официальные обновления Microsoft для исправления уязвимости SSLv3.0 https://support2.microsoft.com/kb/2992611/en-us Link2: technet.microsoft.com/en-us/library/security/ms14-066.aspx

Дополнительная информация о поддержке TLS Link3: blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx

Проблемы, выявленные с помощью начального исправления KB2992611 и немедленного исправления через KB3018238 Link4 infoworld.com/article/2848574/operating-systems/microsoft-botches-kb-2992611-schannel-patch-tls-alert-code-40-slow-sql-server- блок-МИС-sites.html

Источник

1 ответ

Если вы намереваетесь проверить, включен ли TLS на сервере / можно ли договориться, то вы можете написать некоторый пробный код с помощью TcpClient а также SSLStream форсировать передачу TLS и посмотреть, действительно ли это было согласовано. Увидеть:

Если вы хотите предотвратить откат SSL для всех запросов "https", отправленных любым кодом.NET, установите его следующим образом:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Примечание: применяется к AppDomain и так повлияет на любой HttpWebRequests сделано в том же AppDomain.

Если вы хотите более явный / расширенный контроль стека каналов WCF, который используется для связи с сервером (так что вы можете использовать только безопасность на уровне транспорта TLS), вы можете написать свой собственный StreamUpgradeProvider,

(Я "думаю", вы бы создали свой собственный Stream который использует TLS через использование TcpClient а также SSlStream... а затем вы сделаете обновление канала, чтобы использовать его...(может быть неправильно).... или это вы оберните Stream дано вам в обновлении с SSlStream)

Источник
Другие вопросы по тегам