Использование SSL в IntraWeb.

 

Николай Ренжиглов ®

 

В этой главе мы обсудим технологию создания клиентских и серверных IntraWeb-приложений для обмена данными в WEB по защищенным каналам с использованием слоя SSL, а также работу с сертификатами X.509.

 

Введение.

 

            Многие программисты, имеющие опыт разработки сложных интерактивных приложений для WEB, в процессе своей работы не выходили за рамки “открытого” канала  обмена по протоколу HTTP. Обмен текстом по этому протоколу не предполагает защиты от несанкционированного доступа к пакетам данных, поэтому  использование программного обеспечения такого рода не так распространено, как другие аспекты WEB-программирования в Delphi. Как правило, за защиту информации в сети отвечает сетевой администратор проекта, а не программист. Хотя настройка для работы со слоем SSL в проекте IntraWeb Stand Alone сводится к установке пары свойств контроллера сервера, программист должен знать технологию работы с защищенным слоем достаточно подробно, поскольку SSL становится частью программ, разработанных с использованием IntraWeb.

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

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

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

В 70-х годах прошлого века авторами Диффи и Хельманом была предложена схема шифрования с открытым ключом. Принципиально, что в ней ключи для шифрования и расшифровки различаются. Один ключ становится доступным некоему сообществу отправителей и используется для шифрования, а другой остается private-ключом, которым распоряжается один человек - адресат. Этот секретный ключ применяется для расшифровки сообщений. Возможно и обратное: private-ключ используется для шифрования, а открытый для раскодирования сообщений. На первый взгляд кажется, что "секретность" этого метода снижается ровно наполовину по сравнению с симметричной схемой, ведь второй ключ известен многим людям.

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

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

Предположим, что необходимо по сети осуществить оплату за товары с клиентского счета в банке. Клиент дает указание банку перечислить деньги на требуемый счет. Перед началом процедуры сервер банка должен установить личность клиента. Применить систему паролей в этой ситуации небезопасно – сам пароль не защищен от перехвата злоумышленниками. В отличие от парольной системы SSL предполагает наличие у клиента двух ключей: общедоступного (public) и секретного (private). Ключи используются во взаимно противоположных процессах: первый используется для рассекречивания данных, зашифрованных с применением другого и наоборот. Например, цифровую подпись клиент шифрует с помощью своего private-ключа. Читать эту подпись можно из любого места сети – public-ключ для расшифровки подписи доступен везде. Однако подделать подпись без знания private-ключа (т.е. фактически взломать private-ключ) невозможно. Это гарантирует закон не просто больших, а невообразимо больших чисел: как минимум десять в тридцать восьмой степени переборов для алгоритма RC4 128 бит (напомним, что время существования вселенной в секундах намного меньше: 10¹⁸ - 10²⁰ ).

В свою очередь сервер банка также имеет private-ключ для шифрования своих сообщений. Public-ключ находится у клиента и используется им, например, для расшифровки идентификационной информации банка. Такой обмен и опознание дают гарантию того, что клиент не отправил информацию о своих банковских реквизитах злоумышленникам. Существовал (да наверное существует и по сей день) такой способ воровства информации, рассчитанный на невнимательность, когда клиент при наборе URL-банка делает ошибку (например, вместо alpha.com указывает alfa.com) и попадает на сайт-двойник с неотличимым от оригинала интерфейсом. Далее схема ясна: персональная информация клиента попадает в третьи руки и используется втайне от него. Взаимная идентификация  позволяет исключить такого рода возможности несанкционированного доступа к информации.

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

Из всего вышесказанного ясно, что для обслуживания процесса применения private и public-ключей необходимы услуги третьей стороны, подтверждающей, что public-ключ, применяемый клиентом, будет соответствовать в нашем примере private-ключу конкретного банка. Такая третья сторона называется сертификационным центром. Основная задача сертификационного центра при выдаче private-ключа – это убедиться, что лицо, запрашиваемое такой ключ, не имеет целью выдать себя за кого-то другого – то есть идентифицировать личность. Работы по этой части хватает (вспомните нотариальные конторы), поэтому один сертификационный центр (Certificate Authority или CA) может выдавать лицензии другому, тот третьему и так далее. При этом принимаются меры к тому, чтоб не возникало дублирование публикуемых ключей  и ситуаций, когда субъект этого процесса выдает сертификат сам себе. Одна из самых успешных и известных фирм, работающих в области выдачи сертификатов - VeriSign[1]. Однако Вы сами можете организовать сертификационный центр у себя в Интрасети, где достаточно просто теми или иными способами идентифицировать клиента.

 

 

Протокол SSL.

 

Технически существует несколько распространенных способов организации “закрытого” канала. Наиболее популярным и стандартизованным (хотя и не официально) на сегодняшний день является протокол SSL (Secret Socket Layer), разработанный NetScape[2]. Этот протокол представляет собой некоторую надстройку над протоколом TCP/IP и промежуточный слой, на котором располагается протокол HTTP и уровень приложений:

 

 

 

IMAP

LDAP

HTTP

                                                               Уровень клиентских или

                                                               серверных WEB-приложений

 

 

TCP/IP

SSL

                                                               Уровень обмена данными по протоколу

                                                               TCP/IP

 

 

 

 

Ясно, что работа с использованием SSL невозможна только на сервере или только в клиентском приложении: оба участника обмена информацией должны использовать безопасный слой. Другое дело, что некоторые WEB-серверы, функционирующие с использованием SSL, позволяют обмениваться данными по открытому каналу (как правило, в пределах домена и при передаче не конфиденциальных данных). Но если сервер настаивает на использовании SSL, причем с высокой степенью секретности, то соединиться с ним и получить информацию для отображения в окне браузера без соответствия этим требованиям бывает невозможно.

В самом SSL не заложено никаких алгоритмов шифрования. Слой только позволяет использовать некоторое их множество:

·                  Отсутствие шифрования (тоже алгоритм, причем самый быстрый)

·                  Потоковые методы

o                                     RC4 с 40-битным ключом

o                                     RC4 с 128-битным ключом. Обеспечивает вероятность “угадывания” ключа при случайном переборе 3.4 * 10^-38.

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

o                                     RC2 with 40 bit key (более медленный алгоритм шифрования, чем RC4)

o                                     DES with 40 bit key

o                                     DES with 54 bit key

o                                     Triple-DES with 168 bit key. Наиболее мощный  на сегодняшний день. Работает медленнее, чем RC4 c 128-битным ключом, но вероятность взлома исчезающе мала: 3.7 * 10^-50.

o                                     Idea (128 bit key)

o                                     Fortezza (96 bit key)

 

 

Содержимое сертификата.

 

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

 

Subject: Distinguished Name, Public Key Issuer: Distinguished Name, Signature Period of Validity: Not Before Date, Not After Date Administrative Information: Version, Serial Number Extended Information: Basic Contraints, Netscape Flags, etc.

 

 

Двоичное представление сертификакта описывается стандартом ASN.1, который определяет правила шифровки. Если передача по сети двоичной информации невозможна,  используется ASCII-формат, известный как PEM-шифрование (Privacy Enhanced Mail). Пример PEM-кода показан ниже:

-----BEGIN CERTIFICATE-----

MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx

FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG

A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv

cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz

bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL

vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa

lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV

2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7

dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==

-----END CERTIFICATE-----

Библиотеки SSL.

            Для работы с программным обеспечением IntraWeb нам понадобятся библиотеки LIBEAY.DLL и SSLEAY.DLL, работающие со слоем SSL. Библиотеки разработанны Эриком Янгом и Тимом Хадсоном (Eric A. Young и Tim J. Hudson.)[3] . Не входят ни в поставку IntraWeb 5.0 – 5.1, ни в Delphi (Indy-компоненты). Они доступны по адресу [4] для использования без всяких ограничений.

На самом деле ограничения есть. США и Канада ввели жесткий контроль  на экспорт использования технологии SSL. Разработчики Indy компонентов (как и OpenSSL.org)  поставляют библиотеки без исходных текстов. Речь о поставке лицензий на их использование вообще не идет. Это может явиться препятствием  при попытке подписать свой сертификат в CA, которые расположены в Северной Америке – такие агентства не подписывают сертификаты со стойкой криптографией (длина ключа 128 бит и более) для клиентов из не “ либеральных европейских стран” ( liberal countries in Europe). Подробнее об OpenSSL см. раздел “Проект OpenSSL”.

Установите эти библиотеки на свой серверный компьютер в папку /WINNT/SYSTEM32.

 

Проект OpenSSL[5].

            Проект OpenSSL основан на предоставлении как самих библиотек LIBEAY.DLL и SSLEAY.DLL, так и утилит для работы с ними. Поддерживается и развивается программистами на добровольных началах. На сайте организации представлена полная документация по использованию библиотек, их интерфейсы и примеры на языке Perl и PHP. Программисты OpenSSL разработали утилиту командной строки OpenSSL.exe и снабдили ее отличной документацией. Программа предназанчена для:

·                  Создания X.509 сертификатов. 

·                  Шифрования с использованием библиотеки Ciphers.

·                  Тестирования SSL-клиентов и серверов.

·                  Управления почтовыми отправлениями с использованием SSL.

Программа OpenSSL.exe работает в режиме командной строки и в дальнейшем мы будем ее использовать для работы с ключами и сертификатами.

 

Получение и подписывание сертификатов.

Существует два пути получения подписанного сертификата.

1.               С использованием услуг СА. Следуя по этому пути, вам необходимо получить свой собственный private key. Для этой цели запустите программу OpenSSL с командной строкой:

>OPENSSL genrsa –out privkey.pem

            Далее сгенерируйте csr-сертификат (вернее, запрос Certificate signing request):

>OPENSSL req –new –key privkey.pem –out cert.csr –config openssl.conf

Оба файла теперь необходимо отправить CA, пользующемуся вашим полным доверием, например, Verisign. CA “ставит печать” в вашей заявке csr (не очень быстро и совсем небезвозмездно: для организации своего СА фирма запросит максимально дорого, а для некоммерческих целей может быть и бесплатно) и отправляет вам обратно текстовые файлы в каком-либо формате для использования всего этого как X.509-сертификата. Это рекомендуемый путь для работы с проектами, которые уже отлажены и переданы в коммерческую эксплуатацию.

2.               Без использования услуг СА. Этот путь лучше всего подходит для для создания тестовых проектов IntraWeb. Здесь не надо платить за чьи-либо СА-услуги, ждать подписи, а главное  - можно экспериментировать с сертификатами, меняя их параметры и исследуя результаты работы. Этот способ мы рассмотрим более подробно.

 

Самоподписанный сертификат.

            Роль разработчика IntraWeb-проектов в терминах SSL можно определить как  пользователь клиентского и серверного ПО. Роль СА как такового мы здесь рассматривать не будем (о том, как действовать в роли СА при выдаче сертификатов описано в [[6]]).

            При создании ключей с использованием OpenSSL.exe, необходимо описать конфигурационную среду владельца сертификата. Эта среда хранится в текстовом файле, подключаемом в момент работы программы OpenSSL. Вот текст такого файла с именем openssl.cnf, используемого автором при тестировании примеров книги:

[req]

default_bits=1024

default_keyfile=privkey.pem

distinguished_name=req_distinguished_name

encrypt_rsa_key=no

[req_distinguished_name]

countryName=RU

countryName_default=RU

stateOrProvinceName=Rostov region

localityName=Rostov upon Don

localityName_default=Rostov upon Don

organizationName=IVCZKZD

organizationName_default=IVCSKZD

organizationalUnitName=Payroll accounting

commonName=Renzhiglov Nick

emailAddress=Renzhiglov@ivc.skzd.mps

 

Поместите этот файл в папку, в которой расположен OpenSSL.exe. Создайте свой private key способом, описанным выше. Ключ privkey.pem будет помещен программой в ту же папку.

            Теперь необходимо создать самоподписанный сертификат сроком действия, скажем, три года. В командной строке наберите

>OPENSSL req –new –x509 –key privkey.pem –out cert.pem –days 1095 –config openssl.cnf

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

            Теперь в вашем распоряжении имеется два файла: privkey.pem и cert.pem. Третий файл root.pem, необходимый для работы с IntraWeb, получите простым копированием cert.pem в root.pem.

Тестовый проект IntraWeb SSL.

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

Переименуйте файл privkey.pem в key.pem, так как IW настроен для работы только с таким именем. Начните новый IntraWeb Stand Alone-проект. В директорию проекта скопируйте файлы key.pem, cert.pem и root.pem, созданные способом, описанным выше.

            В контроллере сервера определите номер SSL-порта, например 500. Строку SSLCertificatePassword оставьте пустой, поскольку наш самоподписанный сертификат не требует пароля для доступа к его содержимому.

 

 Для задания паролей такого рода можно использовать параметр командной строки -passin или -passout для входящего и исходящего паролей соответственно.

Напомним, что по умолчанию для обмена через защищенный слой сервером IIS используется порт номер 443. Также как и в случае с портом для обмена по протоколу HTTP 80, используемым по умолчанию, избегайте применять это значение в своих проектах.

Запустите проект на выполнение. Обратите внимание, что окно контроллера сервера отображает два значения порта: “обычный” порт HTTP 1010 и  порт с номером 500 – тот, по которому мы будем осуществлять доступ к ресурсам сервера по протоколу HTTPS.

Укажите в строке URL браузера следующее значение:

https://100.100.100.100:500

(здесь, как и ранее, указан тестовый  IP-адрес). После уведомления о том, что начинается сеанс безопасного соединения, вы, как клиент,  получите сообщение о том, что  сертификат сервера не числится в списке пользующихся доверием (trusted):

Нажмите кнопку “Yes” и продолжите работу. Просмотрите сертификат (View certificate). Вот как он выглядит:

Теперь можно установить его в хранилище корневых CA, которые пользуются вашим доверием (путь для IE Tools|Internet options|Content|Certificates|Trusted…). Вот результат такой установки:

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

Предупреждение о несоответствии сертификата имени сайта (server hostname) возникает при обнаружении того, что CA в конфигурационном файле задан неверно (в нашем случае commonName=Renzhiglov Nick). Укажите в поле commonName имя сайта и создайте новый сертификат - предупреждение исчезнет.

 

Степень шифрования.

            Степень шифрования (длина ключа) в нашем примере целиком определяется браузером. Stand Alone-сервер, использующий SSL, может поддерживать соединение и с 40-битной и со 128-битной длиной ключа. Чтоб использовать высокую степень шифрования, рекомендуйте клиентам вашей интрасети установить соответствующее ПО, увеличивающее надежность шифрования и доступное на сайтах разработчиков браузеров. В частности, для IE существует такое ПО для любой версии и платформы от Windows 95 до Windows 2000/NT.

 

Идентификация клиента.

            В разделе "Проект IntraWeb SSL " мы акцентировали внимание на том, что в тестовом проекте осуществляется только идентификация сервера с клиентской стороны. Конечно, возможна проверка сертификатов и в обратном направлении. Однако в этом случае на серверном компьютере придется организовать службу ведения сертификатов клиентов с соответствующей доработкой серверного ПО. В частности, нужно рекомендовать всем клиентам создать CA-сертификаты, подписать их и затем добавить их в список "trusted CA list" на сервере. Командная строка для запуска утилиты OpenSSL, используемой для контроля сертификатов клиентов, установленных на сервере, следующая (IntraWeb-приложение должно быть запущено):

 

>OPENSSL s_client -connect 100.100.100.100:500 -prexit

 

Недостатки версии IntraWeb 5.0.

            К сожалению, в версии IntraWeb 5.0 нельзя управлять защищенными и незащищенными соединениями. Вы пытались соединиться с каким-либо официальным североамериканским сайтом, используя в WEB-браузере 40-битный ключ? Соединение, как правило, блокируется. В указанной версии IW такую блокировку нужно программировать достаточно сложным способом.

            Бесконтрольное поведение сайт демонстрирует, если пользователь при наборе URL неверно указал протокол безопасного соединения - забыл набрать букву S в конце слова HTTPS. На сервере возникает исключение, которое трудно отловить, используя стандартное событие IWServerController.OnException:

 

 

           

 

           

 

В версии IW 5.1 эти недостатки преодолены. Для котроллера сервера Stand Alone-приложения можно задать три возможных варианта обработки не SSL-запроса:

·                 nsAccept. Запрос будет обработан по незащищенному порту.

·                 nsBlock. Запрос будет блокирован с выдачей сообщения.

·                 nsRedirect. Не SSL-запрос будет передан для обработки в режиме защищенного канала.

Приложение 1. Список стандартных команд утилиты OPENSSL.EXE.

Формат запуска утилиты OPENSSL.EXE в общем случае следующий:

>openssl command [ command_opts ] [ command_args ]

 

Перечень стандартных команд, задаваемых в позиции command, представлен ниже.

asn1parse http://www.openssl.org/docs/apps/asn1parse.html	Разбивает последовательность  ASN.1
ca http://www.openssl.org/docs/apps/ca.html	Осуществляет управление сертификационным центром СА.
ciphers http://www.openssl.org/docs/apps/ciphers.html	Определяет дескрипторы шифрования.
crl http://www.openssl.org/docs/apps/crl.html	Управляет списком недействительных (revocation list) сертификатов.
crl2pkcs7 http://www.openssl.org/docs/apps/crl2pkcs.html	Конвертирует CRL в формат PKCS#7.
dsa http://www.openssl.org/docs/apps/dsa.html	Управление областью DSA.
dsaparam http://www.openssl.org/docs/apps/dsparam.html	Генерирование параметров DSA.
enc http://www.openssl.org/docs/apps/enc.html	Шифрует строку
dhparam http://www.openssl.org/docs/apps/dhparam.html	Управление параметрами Диффи-Хельмана (Diffie-Hellman).
gendsa http://www.openssl.org/docs/apps/gendsa.html	Генерирует DSA-параметры.
genrsa http://www.openssl.org/docs/apps/genrsa.html	Генерирует RSA-параметры.
ocsp http://www.openssl.org/docs/apps/ocsp.html	Используется для определения on-line состояния сертификата.
passwd http://www.openssl.org/docs/apps/passwd	Генерирует хэш-код для пароля, введенного в диалоге.
pkcs12 http://www.openssl.org/docs/apps/pkcs12	Управление областью PKCS#12
rand http://www.openssl.org/docs/apps/rand.html	Генерирует псевдослучайную последовательность байт.
req http://www.openssl.org/docs/apps/req.html	Управление запросом на создание X.509-сертификата.
Rsa http://www.openssl.org/docs/apps/rsa.html	Управление областью RSA
Rsautl http://www.openssl.org/docs/apps/rsautl.html	Управление генерированием, сертифицированием и верификацией RSA-сертификатов.
s_client http://www.openssl.org/docs/apps/s_client.html	Тестирует клиентскую часть сервера (например, список сертифицированных клиентов).
s_server http://www.openssl.org/docs/apps/s_server.html	Тестирует соединение путем эмуляции WEB-сервера.
sess_id http://www.openssl.org/docs/apps/sess_id.html	Управление параметрами SSL-сессии.
Smime http://www.openssl.org/docs/apps/smime.html	Работа с почтой по защищенному каналу.
Speed http://www.openssl.org/docs/apps/speed.html	Тестирование скорости алгоритмов шифрования.
Verify http://www.openssl.org/docs/apps/verify.html	Верификация X.509-сертификатов.
Version http://www.openssl.org/docs/apps/version.html	Информация о текущей версии библиотек SSL
x509 http://www.openssl.org/docs/apps/x509.html	Управление X.509-сертификатами.

 

 

Приложение 2. Список портов, используемых по умолчанию.

Открытый порт	Защищенный порт	Назначение
80	443	Связь клиента и WEB-сервера по протоколу HTTP, HTTPS
25	465	Электронная почта и обмен сообщений между серверами.
119	563	Обмен данными конференций usenet (nntp, nntps)
389	636	Работа с адресной книгой
20,21	989,990	Работа по протоколу FTP, FTPS
23	992	Работа с удаленным компьютером по протоколу TELNET, TELNETS
143	993	Каталоги почтового ящика, электронная почта.
	994	Чаты по безопасному каналу J
110	995	POP3, POP3S