Проблемы при попытке установить защищенное клиент-серверное соединение

[poyo_poyo]

Здравствуйте.

Я не флэш-программист, но участвую в написании серверной части проекта, в котором требуется организовать защищенное соединение между клиентом на Флеше и сервером. Для реализации этого со стороны сервера используется библиотека OpenSSL а со стороны клиента мы попытались использовать класс SecureSocket. Как сказал наш флеш-программист, клиент запускается из AIR.
Первая проблема, с которой я столкнулся при реализации - это некоторое несоответствие заявленных возможностей класса SecureSocket реальности. В частности, в документации указано, что SecureSocket поддерживает TLS. Однако при попытке установить контекст SSL на поддержку только TLS соединение не происходило и выходило сообщение об ошибке. Проблему удалось обойти, включив при создании контекста SSL поддержку устаревших типов SSLv2 и SSLv3. После этого пошла попытка соединения TLSv1 с несколько устаревшим шифром RC4-MD5 (128 bits), но тут всплыла проблема 843 порта и приснопамятного crossdomain.xml Для ее решения я написал демон, который слушает этот порт и после получения от клиента запроса <policy-file-request/> отдает ему политику. Выяснилось, что это прекрасно работает для обычного сокета, однако ни в какую не хочет работать для сокета защищенного. Клиент соединяется на 843 порт, успешно проходит рукопожатие SSL, однако потом функция SSL_read вместо строки <policy-file-request/> возвращает ответ нулевой длины и, судя по ряду признаков, нижележащее соединение разрывается. Запрос файла политики так и не приходит. В то время как тестовый клиент, написанный на С, успешно соединяется с демоном файла политики и возвращает оную:

$ ./fspfd_client 
Тестовый клиент демона файлов политики сокетов для Flash
Запуск: client [IP-адрес сервера fspfd]
Инициализация SSL успешно завершена
SSL соединение успешно установлено
Установлено SSL соединение
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
	<allow-access-from domain="*" to-ports="*" />
</cross-domain-policy>

Попытка принудительно послать клиенту политику несмотря на отсутствие запроса <policy-file-request/> успеха не принесла.

При попытке же запустить флеш-клиента вываливаются следующие ошибки:
Запуск из среды разработки:
IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2031: Socket Error. URL: aaa.bbb.ccc.ddd" errorID=2031

Запуск из браузера:
securityErrorHandler: [SecurityErrorEvent type="securityError" bubbles=false cancelable=false eventPhase=2 text="Error #2048"]

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

Сообщения из логов:
Тестовый клиент на С

Apr 24 23:29:57 [4883]: [INFO] client connection established
Apr 24 23:29:57 [4883]: [INFO] SSL handshake success
Apr 24 23:29:57 [4883]: [INFO] SSL connection established: SSL version: TLSv1 cipher: AES256-SHA (256 bits)
Apr 24 23:29:57 _client: [INFO] SSL handshake success
Apr 24 23:29:57 [4883]: [INFO] ssl_shutdown success
Apr 24 23:29:57 [4883]: [INFO] SSL connection shutdown
Apr 24 23:29:57 [4883]: [INFO] client connection shutdown
Apr 24 23:29:57 _client: [INFO] ssl_shutdown success

FLASH

Apr 24 23:40:21 [4937]: [INFO] client connection established
Apr 24 23:40:22 [4937]: [INFO] SSL handshake success
Apr 24 23:40:22 [4937]: [INFO] SSL connection established: SSL version: TLSv1 cipher: RC4-MD5 (128 bits)
Apr 24 23:40:22 [4937]: [ERR] ssl_read error:
Apr 24 23:40:22 [4937]: [ERR] ssl_read error: zero len response
Apr 24 23:40:22 [4937]: [ERR] SSL_shutdown error:
Apr 24 23:40:22 [4937]: [INFO] SSL connection shutdown
Apr 24 23:40:22 [4937]: [INFO] client connection shutdown

Как видно, и тестовый клиент на С, и клиент на флэше успешно устанавливают SSL соединение с сервером, а вот после этого идут различия: сервер спокойно взаимодействует с клиентом на С и штатно завершает соединение, а вот при взаимодействии с клиентом на флэше серверу при попытке прочитать что-либо из SSL соединения в функцию SSL_read возвращается ответ о том, что прочитано 0 байт, после чего наблюдается ошибка при выполнении функции SSL_shutdown (возможно потому что клиент закрыл свой присоединенный сокет). Причина такого поведения остается полной загадкой. Требуется помощь в ее разрешении и вообще любые идеи о причине возникновения и методах нейтрализации проблемы. Надеюсь на вашу помощь.

[maxkar]

С вероятностью 99% процентов flash не принимает сертификат вашего сервера. Поэтому вопрос: кем подписан ваш сертификат (т.е. какая именно CA его выдала)? Знает ли flash о нем, настроена ли нужна CA на клиенте? Как ваш тестовый C-клиент выполняет валидацию сертификата?

Validation of the server certificate is performed using the trust store and certificate validation support of the client platform. In addition you can add your own certificates programmatically with the addBinaryChainBuildingCertificate() method.

The SecureSocket class only connects to servers with valid, trusted certificates. You cannot choose to connect to a server in spite of a problem with its certificate.

Это все из справки по SecureSocket. Второе в принципе понятно, так как без него использование SSL не имеет смысла. После DNS spoofing (или физического доступа к транспортной сети) трафик уйдет а атакующему и он будет видеть весь трафик.

[poyo_poyo]

Сообщение от maxkar

С вероятностью 99% процентов flash не принимает сертификат вашего сервера.

Это конечно интересная гипотеза, однако она несколько противоречит фактам. Как видно из предоставленных в первом посте логов, при соединении клиента и сервера успешно проводится SSL handshake:
Apr 24 23:40:22 [4937]: [INFO] SSL handshake success
Apr 24 23:40:22 [4937]: [INFO] SSL connection established: SSL version: TLSv1 cipher: RC4-MD5 (128 bits)
Насколько я знаю, проведение SSL хэндшейка будет несколько затруднительно если клиент не имеет всех необходимых для этого данных

Сообщение от maxkar

Поэтому вопрос: кем подписан ваш сертификат (т.е. какая именно CA его выдала)? Знает ли flash о нем, настроена ли нужна CA на клиенте? Как ваш тестовый C-клиент выполняет валидацию сертификата?

Сертификат самоподписанный, сертификат CA помещен в хранилище доверенных корневых сертификатов на машине клиента.
По поводу С-клиента: сначала порождается контекст SSL, делаются необходимые настройки в нем а потом вызывается функция SSL_connect. При ее вызове автоматически происходит хэндшейк, во время которого происходят необходимые проверки. В случае успеха устанавливается SSL соединение, а при неудаче в лог вываливается куча ошибок.

Сообщение от maxkar

Это все из справки по SecureSocket. Второе в принципе понятно, так как без него использование SSL не имеет смысла. После DNS spoofing (или физического доступа к транспортной сети) трафик уйдет а атакующему и он будет видеть весь трафик.

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

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

[maxkar]

Не понятно, почему он у вас из среды разработки не может соединиться с сокетом... Там ошибка именно соединения. firewall мешает или что-то еще экзотическое? Вообще, в сообщениях (флеш) об ошибке есть text, но у вас в этом text ничего интересного нет.

Это конечно интересная гипотеза, однако она несколько противоречит фактам.

Если нет других версий, попробуйте на сервере заведомо non-trusted сертификат. Будет ли отличаться вывод на сервер? В принципе, никто ведь не мешает проверять валидность сертификата после ssl handshake, а чего наделали в Adobe неизвестно. Если получите другой результат, значит, версия с неверным сертификатом исключится. Если тот же, то может и сертификат быть неверный. Попробуйте его вручную на клиенте тогда в secure socket подсунуть.

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

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

P.S. Вот здесь есть более приличная расшифровка флешовых кодов. Я у себя тоже достаточно много информации получал то ли выводом text, то ли event.toString... Или, может быть, это было из-за debug-plugin'а.

Добавлено через 4 минуты
Небольшое добавление. Посмотрел пример в адобе, там есть

error.text + ", " + secureSocket.serverCertificateStatus

Мало ли что там будет для crossdomain.xml. Но вдруг... Ну и другие поля можно в случае ошибки во флеш посмотрет, вдруг что-то найдется.

[alexcon314]

Может бред, но послушайте 443 порт на предмет <policy-file-request/> и последующей отправки кроссдоменника клиенту. Я что-то засомневался, что для разрешения ssl соедиения требуется загрузить дополнительно некий файл с другого порта....
Ошибки говорят, что сначала не найден/не загружен кроссдоменник и, как следствие, SecurityError...

[poyo_poyo]

Сообщение от alexcon314

Может бред, но послушайте 443 порт на предмет <policy-file-request/> и последующей отправки кроссдоменника клиенту. Я что-то засомневался, что для разрешения ssl соедиения требуется загрузить дополнительно некий файл с другого порта....
Ошибки говорят, что сначала не найден/не загружен кроссдоменник и, как следствие, SecurityError...

Идет там соединение на 843 порт за данными политики. У меня два демона запущено, оба отрабатывают, причем одинаково - ответ нулевой длины. Там, кстати, не файл загружается, а считывается информация из сокета. Но для очистки совести ничего не мешает и эту версию проверить.

Да, маленькое уточнение для устранения возникшего недопонимания (я про пост maxkar ).

Не понятно, почему он у вас из среды разработки не может соединиться с сокетом... Там ошибка именно соединения. firewall мешает или что-то еще экзотическое?

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

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

Добавлено через 3 часа 53 минуты
Вобщем ничего хорошего сказать не могу. Что я точно выяснил:
1. Трафика по 443 порту не было
2. Попытка чтения из SSL соединения по прежнему безуспешна SSL_read просто возвращает ноль и все. При этом никаких сообщений об ошибках из самой библиотеки OpenSSL не приходит, в логах пусто.

Добавлено через 5 часов 47 минут

Сообщение от poyo_poyo

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

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

Похоже я был слишком оптимистичен по поводу проверок при хэндшейке Буду читать маны.

Добавлено через 5 часов 53 минуты
Дополнение от флеш-программиста:

при запуске из IDE serverCertificateStatus выдал: principalMismatch