Организация SSL транспортного уровня по программно загружаемому клиентскому сертификату.

Мне довольно часто приходится заниматься организацией защищенных соединений:

• Я программист системы Электронная Москва в вашей квартире - смысл этой системы в организации защищенного на транспортном уровне SSL-канала с помощью индивидуального SSL-сертификата. Эта система не описана у меня на моем личном сайте. Есть только некоторый клон боевой системы с вырезанной криптографией - который остался у меня на хостинге в качестве моего портфолио.
• Безопасность Web-приложений - здесь я подверг сомнению устойчивость стандартной SSL-криптографии и дал код (и рекомендации) для устойчивого, непрослушиваемого и н неповторяемого залогинивания пользователей в сайты с помощью моих виртуальных клавиатур (буквенно-цифровых и с цветовыми полосками).
• У меня есть несколько заметок по организации криптографии по ГОСТ - Криптография по ГОСТ, Установка ГОСТ-сертификата на Web-сервер, Установка ГОСТ-сертификата на клиентский компьютер.
• В моем сайте http://www.gisis.ru/ залогинивание происходит именно по клиентскому сертификату.
• Я часто организую криптографические соединения на прикладном уровне - миную стандартную инфраструктуру сертифкатов транспортного уровня. Для этого у меня на хостинге работает специальный сервис - http://activator.vb-net.com/activate.ashx.
• Я сам часто разрабатываю собственные самописные криптографические протоколы - маниакальный протокол моего собственного изобретения описан на этой страничке - WebActivator - клиент/сервер защиты от копирования для платных программ.
• Наконец, я не брезгую и другими методиками защиты трафика - вплоть до зиповки данных с паролем, как это описано на этой моей страничке - Remote SQL execute for PostgreSQL on GSM/GPRS channel with extreme compress and cryptography.
• Я часто работаю с чужими защищенными системами, например описанная у меня на сайте CMS Digimaker вся устроена на WSE - это механизм шифрования данных на прикладном уровне, примерно аналогичный моим самописным протоколам или зиповке с паролем, только основанный на RSA-ключах. На таких же ключах, которые я выдаю со своего хостинга для моих собственных защищенных протоколов http://activator.vb-net.com/activate.ashx

В принципе, защиту трафика можно организовать на различных уровнях:

• На прикладном уровне. Здесь проще всего использовать либо самописные протоколы либо зиповку с паролем, либо уппомянутое выше WSE. В IIS/Apache не загружается никакой сертификат и Web-сервер ничего не знает о том, что они гоняют через себя защифрованные данные.
• На транспортном уровне. В этом случае сертификат с ключами шифрования загружается в IIS/Apache. А проги на прикладном уровне не подозревают что физически трафик в сети зашифрован.
• Можно шифровать данные на уровне оборудования (физический и канальный уровень). Так работает например аппаратура ЗАС.

Протоколы защиты бывают разные:

• Симметричное шифрование. Это быстрый блочный протокол. Грубо говоря это просто перестановки нескольких битов в данных путем наложения на данные секретного пароля. После перестановки (если ты не знаешь пароля) - осмысленные данные выглядят просто как белый шум, просто случайные данные. Один и тот же пароль используется и для зашифровки и для расшифровки. Стандартный размер симметричного ключа в современном интернете - 40 бит (пять букв), что позволяет довольно легко даже на не очень быстрых кампутерах прямо в онлайне наблюдать зашифрованный трафик.
• Асимметричное RSA-шифрование основано на открытом (известном всем ключе, длиной например 1024 бит) и таком же секретном ключе. Открытый ключ отдается любому клиенту, после наложения его на данные - никак данные восстановить невозможно, если не знаешь секретного ключика (который надо хранить в секрете).
• Над RSA-шифрованием есть некая платная надстройка под названием сертификаты. Когда выдаваемый кому угодно подписывается (удостоверяется) открытым ключом некой организации. В свою очередь открытый ключ этой организации заверяется вышестоящей организацией, вплоть до самых вышестоящих thawte или VeriSign. С помощью этой пирамиды можно убедиться чьи именно были самые первые открытые ключи.
• Стандартная SSL работает так, что этот пятибуквенный ключик шифруется при установлении сессии более серьезными методами - например асимметричным RSA-шифрованием с большим ключом. И по протоколу IKE этот пятибуквенный ключик все время меняется. Шифровать асимметрично весь поток - слишком накладно по времени.
• Тоталитарные государства, чтобы не допускать чтобы рабы что-то шифровали от него - придумывают некоторые модификации RSA-шифрования - например шифрование по ГОСТ. В принципе теоретическая математика за шифрованием по ГОСТ стоит неплохая, однако тоталитарные государства запрещают нелицензионное шифрование и лицензируют его. Лицензирование заключается в выдаче ключа, сгенерированного по некоторому принципу из мастер-ключа, который остается в распоряжении тоталитарного государства и его служителей (ФАПСИ например). Таким образом трафик оказывается защищенным от левого лоха, но не от самого государства, располагающего одним из множителей криптографии и служители этого государства (как бы в государственных целях, а на самом деле с личными корыстными умыслами - именно так появляются на рынке все секретные базы) могут онлайново расшифровывать и прослушивать любой трафик (для которого они выдали лицензию и ключи).
• В принципе шифрование (право граждан на приватность) не соответствует интересам любого государства. Поэтому (как бы) в целях борьбы с некой мифической хакерской технологией под названием "фишинг" о любой попытке установки SSL-соединения сообщается сначала в Microsoft, а оттуда заинтересованные лица получают всю информацию. Пример трафика, который уходит в микрософт - я привел в топике - Stop Microsoft (после картинки с пидарасами из Microsoft Gleam). Есть всякие разоблачения (Wikileaks например), опубликованы подлинники документов - когда английская МИ-6 сделала запрос обо всех SSL с территории Англии, а контора Билла Гейтса выдала ведомости - кто когда и куда ходил по SSL. Как правило все платежные шлюзы (Шлюзы к платежным системам интернет-денег) работают именно по SSL. Это сделано не столько для защиты трафика, сколько для фиксации кто куда и когда ходил.

Теперь, когда я обьяснил что такое сертификат, как он используется для установления SSL-соединения - посмотрим куда его можно поставить - на сервер или на клиент:

• Сертификат можно поставить на сервер. Тогда все клиенты шифруются одним и тем же сертифкатом. Клиент с помощью пирамиды сертификатов может убедиться чьими именно ключами он шифрует свои данные (и кому он их отправляет). Сертификат может быть установлен на транспортный уровень (загружен в IIS) или на прикладной уровень (как в WSE или в моих самописных протоколах).
• Можно организовать SSL с собственными открытыми ключами каждого клиента. Для этого клиент создает свои открытые ключи, а сервер их подписывает своими ключами - и таким образом удостверяет, что это ключи Иванова, это ключи Петрова, а это ключи Сидорова. После подписания ключей на сервере их можно загрузить у клиента на транспортный уровень (в IIS или Apache) или на прикладной уровень (в WSE) и когда на сервер придут запросы от кого-то, можно понять от кого именно - от Иванова, Петрова или Сидорова. Собственно самая первая софтина, с которой я начал этот топик - Электронная Москва в вашей квартире - устроена именно так. Соответственно IIS или Apache, когда расшифровал данные транспортного уровня, состыковал все пакеты и организовал непрерывный поток данных прикладного уровня из отдельных зашифрованных пакетиков данных - Web-сервер выставляет несколько переменных при вызове программы web-сервера - HttpContext.Current.Request.ServerVariables("HTTP_CERTIFICATE_NUMBER") и HttpContext.Current.Request.ServerVariables("HTTP_SUBJECT") - по которым можно поковыряться в базе и найти кто именно тыкается на сервер - Иванов, Петров или Сидоров. Устойчивость SSL при таком механизме организации SSL ровно такая же, как и при установке сертификата на сервер, однако ключей много и у каждого клиента они свои собственные.

Итак, на этой страничке я покажу, как работать с клиентскими сертификатами, но не просто для реквестов на web-сервер, как в моей софтине Электронная Москва в вашей квартире, а для SSL-реквестов к SOAP-WSDL сервису (который не имеет отображаемой в браузере странички). Причем в описании будет присутствовать одна особенность - клиентский сертификат будет не просто загружен в IIS, а будет искаться в хранилище сертификатов моим собственным кодом и загружаться для формирования SOAP-реквестов программно.

Если вы о хотите почитать о SOAP-WSDL сервисах вообще, то можете почитать следующие мои странички:

• WCF_CLIENT - клиент Web-сервиса (вторая версия)
• Как сделать SOAP/WSDL-вебсервис на ASP.NET/MONO для вызова его из FLEX
• SOAP-WSDL сервис - не всегда лучший способ обмена данными между приложениями. Об альтернативных методах обмена данными (XML,TEXT, JSON, SOCKET, FTP/ZIP и других) вы можете почитать на моей страничке - SOAP/WSDL vs XML data exchange.

В виндузне существуют остнастка управления сертификатами - она раскрывает 13 узлов различного назначения из защищенного хранилища, в котором хранятся сертификаты. Этих 13-ти узловых защищенных хранилищ существует два - в контексте текущего пользователя и текущей машины. На скринах ниже видно, как после введения в командной строке MMC (Менеджера управления остнастками) - можно запустить оснастку управления сертифкатами либо по контексту кампутера (LocalMachine) либо по контексту пользователя (CurrentUser):

Кроме того, для загрузки сертификатов в IIS7 нужна специальная оснастка ClientCertificateMapping - она отсутствует в изначальной комплектации IIS.

Кроме того, для преобразования различных форматов сертифкатов друг в друга, генерации ключей и всех прочих операций с сертификатами и ключами вам потребуется установить OpenSSL:

Итак, начинаем операции по организации SSL-шифрования на основе клиентского сертификата начинается с генерации личного секретного ключа:

Создаем пару секретный ключ и публичный ключ:

И отправляем CSR-файл с публичным ключом на подписание на сервер. Там удостоверяют наш публичный ключ своим публичным ключом, записывают в какую-то свою базу на сервере - имя клиента, чтобы когда WEB-сервер поднимет с транспортного уровня Request.ServerVariables("HTTP_CERTIFICATE_NUMBER") и Request.ServerVariables("HTTP_SUBJECT") - можно было понять что именно за клиент обратился по SSL на сервер. И создают собственно сертификат в формате CRT - это уже сертификат, который содержит и наш открытый клиентский ключ и подпись сервера, которым заверен наш ключ. Весь этот процесс называется Enrolment сертификата.

Теперь нужно собрать пакет PFX, который будет содержать и наш секретный ключ, и наш открытый ключ, подписанный сервером.

Теперь этот PFX-сертификат надо установить. Этот сертификат содержит уже не только открыто распространяемую информацию (наш личный открытый ключ, заверенный сервером), но и наш личный секретный ключ, применяемый для расшифровки ответов. Предпочтительно выбирать защищенное Windows-хранилище My.

Теперь надо обеспечить, чтобы учетная запись (под которой выполняется узел IIS) - имела право доступа к этому сертификату. Тут есть тысяча способов. Сейчас мне некогда возиться, я просто зашел на один из своих web-сервером и поставил что этот узел выполняется с правами администратора.

Теперь у нас все подготовительные работы выполнены, создан правильный сертификат, установлен в IIS и к нему обеспечен доступ со стороны нашей проги. Пришло время заняться прогой.

Я отработал себе вот такой шаблон кода для SSL-обращения к защищенному SOAP-WSDL сервису:

• Я создаю webApplication - чтобы сразу же защищенный по SSL-сервис можно было удобно добавлять в ссылки:
  
  
• Далее ставлю ссылку на защищенный сервис:
  
  
• Теперь, когда студия создала прокси-классы по WSDL, который предоставил защищенный SOAP-сервис - в студии появляются подсказки на каждый метод сервера (и его параметры).
  
  
• Сделав небольшие свои собственные врапперы вокруг классов, сформированных студией по WSDL - я уже могу делать собственно код. В данном случае, как вы видите - я использую PostgreSQL (через провайдер npgsql):
  
  
• Номер созданного ранее и установленного в защищенное хранилище My моего SSL-сертификата в формате PFX (содержащего закрытый ключ и открытый ключ, подписанный открытым ключом сервера) - я указывают в конфиге:
  
  
  
• Теперь я покажу, как я добавил поиск сертификата в хранилище и добавил его к защищенному по SSL-обращению:
  
  

  Фрагмент кода, который вы видите на рисунке - выглядит вот так:

     1:  Public Class Gate

     2:   

     3:      Dim ShopService1 As ru.inplat.merchant_remote.ShopService

     4:   

     5:      Public Sub New()

     6:          ShopService1 = New ru.inplat.merchant_remote.ShopService

     7:          Dim ShopServiceCert As System.Security.Cryptography.X509Certificates.X509Certificate2

     8:          Dim CertStore As System.Security.Cryptography.X509Certificates.X509Store = New System.Security.Cryptography.X509Certificates.X509Store

     9:          CertStore.Open(System.Security.Cryptography.X509Certificates.OpenFlags.MaxAllowed)

    10:          For Each OneCert As System.Security.Cryptography.X509Certificates.X509Certificate2 In CertStore.Certificates

    11:              If OneCert.SerialNumber = System.Configuration.ConfigurationManager.AppSettings("CertNumber") Then

    12:                  ShopServiceCert = OneCert

    13:                  GoTo OK1

    14:              End If

    15:          Next

    16:          Throw New Exception("No certificate " & System.Configuration.ConfigurationManager.AppSettings("CertNumber"))

    17:  OK1:    ShopService1.ClientCertificates.Add(ShopServiceCert)

    18:      End Sub

    19:   

    20:  ...

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

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

  
  
  
  Comments ( )
  Link to this page: //www.vb-net.com/ClientSSL/index.htm

  < THANKS ME>

  g2019507">