Временно загрузите ключ клиента SSL для аутентификации клиента в C #

Question

Я использую элемент управления WebBrowser для добавления WebInterface в приложение C #. Я хочу убедиться, что только такое приложение может подключаться к нашему веб-серверу, используя SSL-сертификаты клиента.

Моя идея заключалась в том, чтобы встроить сертификат клиента в приложение и просто использовать его при подключении через мое приложение. У кого-нибудь есть предложение, как это сделать? Или единственный способ заставить его работать - это загрузить ключ в X509Store.

Если я положу его в X509Store, он сделает мой ключ доступным для общего использования Internet Explorer?

Answer 1

Итак, несколько мыслей здесь:

1

Я согласен с «erickson», что с вашим текущим дизайном почти невозможно проверить, что ТОЛЬКО ваше приложение может взаимодействовать с приложением. Это всего лишь вопрос времени, когда кто-то обратит внимание на ваше приложение, а затем на его игру (если это только ваша форма безопасности). Если вы хотите подтвердить, что это ваше приложение и действительный пользователь, то вам нужно аутентифицировать пользователя, а также какой-то механизм проверки подписи рассматриваемого приложения (что, я не думаю, возможно в модели клиент-сервер). ... в конце концов, я всегда могу лгать и говорить, что мое приложение "hackyou" имеет ту же подпись, что и ваше "realapp", и вы не можете проверить это со стороны сервера)

2

Помните, что элемент управления WebBrowser, по сути, является оболочкой для IE, поэтому без некоторых уловок (о которых я расскажу через секунду) вам придется добавить сертификат в хранилище пользователя.

3.

Вот хакерский способ выполнить то, что вы просите (даже если это плохая идея):

• Сначала используйте WebRequest.Create для создания объекта HttpWebRequest
• Загрузка объекта X509Certificate2 вручную из файла или двоичного потока, закодированного в программе
• используйте HttpWebRequest.ClientCertificates , чтобы добавить свой сертификат в веб-запрос
• Отправьте запрос, получите ответ
• Отправьте ответ в веб-браузер, отправив ResponseStream HttpWebResponse в DocumentStream веб-браузера

Это, по сути, означает, что вам придется написать несколько классов-оболочек для обработки запросов и ответов на сервер и с сервера и просто использовать веб-браузер для обработки просмотра HTML-кода.

На самом деле вам нужно изменить дизайн и посмотреть на угрозы, с которыми вы пытаетесь справиться!

Answer 2

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

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

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

Answer 3

Целью использования ключа является не столько проверка пользователей, сколько ограничение доступа пользователей приложения вместо использования какого-либо веб-браузера. Это своего рода интранет-поведение в общедоступном Интернете.

Это DRM бедняка. Потери, связанные с тем, что люди извлекают ключ, не так важны. Я думаю, что риск этого невелик, а то, что мы можем потерять, минимально.

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