Недействительные цифровые сертификаты -- норма жизни?

Source: http://www.itblogs.ru/blogs/borkus/archive/2008/04/02/26712.aspx

Последнее время у меня стойкое впечатление, что народ не очень понимает, что такое сертификаты ЭЦП и зачем они нужны. Все обзавелись такими сертификатами, но по каким-то своим соображениям, не считают нужным их, например, продлевать. Если бы примеры были единичны, то все бы было ничего, но подобные случаи все чаще становится нормой. Вот два случая из моей практики:
1. Почтовый сервер, предоставляемый клиентам хостинга Zenon, может поддерживать защищенный канал связи. Аутентификация — по просроченному сертификату [выданному сервером компании самому себе]. Причем, в FAQ провайдера так прямо и написано: то, что сертификат такой старый -- это нормально, принимайте как есть. Норма жизни.

[Другая ситуация с почтовым сервером mail.tochka.ru -- там сертификат просрочен с 19 марта]

Характерно, что я столкнулся с таким явлением уже не на первом сервере интернет. Firefox ругается и предлагается выбор: доверять ли устаревшему удостоверению. Вроде бы все нормально, но ведь если паспорт просрочен, то он недействителен? В чем тогда его смысл?

2. Второй пример — более неприятный для меня.

«Промсвязьбанк» с марта радует просроченным сертификатом Java-приложения дистанционного обслуживания Юридических лиц. Браузер ругался по-черному. «Сертификат из доверенного источника, но просрочен». С учетом того, что через систему могут проходить платежи на миллионы рублей, подобное отношение к безопасности выглядит странновато.

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

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

Published 2 апреля 2008 г. 15:27 by Vlad Borkus Edit
Filed under: Безопасность, Практика [Edit Tags]

Comments

WS-Security: начинание благое, но безопасность SOA не обеспечивает

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/08/19/ws-security.aspx

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

Примерно так обстоит дело со стандартами в области безопасности SOA. В стеке WS-* запланирована очень глобальная модель безопасности, включающая почти десяток всяких спецификаций (WS-Security, WS-Secure Conversation, WS-Trust, WS-Federation, WS-Policy, а также XML Digital Signature, Security Tokens Profiles (для SAML, Kerberos,X.509) и т. п.

Благодаря этому возникает целый комплекс очевидных проблем для SOA:
1) Не все эти стандарты реализованы одинаково во всех продуктах, что делает разные компоненты SOA несовместимыми.
2) Так как общие стандарты разрабатываются медленно, открывается поле для "частных" расширений вендоров, которые еще более снижают совместимость.

Я бы не стал писать про это статью, но на днях натолкнулся на интересное выступление на эту тему специалиста в области безопасности Брэда Хилла (http://www.isecpartners.com/files/iSEC_HILL_AttackingXMLSecurity_bh07.pdf). В почти 200-страничной презентации обстоятельно показывается, почему стек WS-S -- пока не лучший способ для обеспечения безопасности для открытых в Интернете сервисов,B2B-сервисов и внутрикорпоративных web-сервисов.

Во первых, для любых внутрикорпоративных и B2B ИТ-систем характерна более высокая степень доверия к их пользователям, и проблемы безопасности как правило решаются "не внутрикорпоративными фаерволами, а организационными мероприятиями и [в случае B2B] адвокатами". Главное, что должна обеспечить общая инфраструктура безопасности -- это протоколирование всех действий и точную идентификацию пользователей, получивших доступ к конкретной системе. Это тезис, с которым сложно не согласиться.

Но для этих задач ЛУЧШЕ всего подходит стандартный SSL, при одновременном применении _клиентского_ и северного сертификатов. В самом деле, у него есть набор явных преимуществ:

1) Он решает как задачу безопасной аутентификации (по сертификату);
2) Он защищает трафик от пользователя к системе;
3) Что еще более важно -- он совершенно ОДИНАКОВО реализован во всех системах, в том числе старых -- пяти и даже более летней давности;
4) Он покрывает 99% процентов того, что нужно для решения реальных задач.

Модель же безопасности на уровне сообщений, примененная в WS-S, не дает в этом смысле никаких преимуществ, так как опять-таки в 99% случая все, что от нее требуется -- это аутентификация пользователей. Но он также неодинаково реализован на новых и старых системах, а применение агентов-посредников тоже не всегда удобно и эффективно. Также WS-S (в конечном итоге за счет XML Digital Signature) опирается на шифрование больших объемов данных открытыми ключами – очень ресурсоемкая операция по сравнению с симметричным шифрованием в SSL. Поэтому при использовании для интеграции внутрикорпоративных систем WS-Security оказывается менее адекватен, чем SSL.

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

WS-Security плох тем, что для его реализации используется работа многих слоев (от XML Encryption, XML Digital Signature, Security Tokens Profiles (SAML, Kerberos, X.509), WS-Trust, WS-Federation и т.п) -- слишком много точек для потенциальной атаки, слишком сложно заставить все это скоординировано работать.

Брэд Хилл показывает в своей презентации как можно эти уязвимости использовать, какие есть стандартные "дыры" в реализации этих спецификаций, например, в XML Парсере. Эти дыры можно было бы отключить настройками, но сегодняшние продукты таких настроек не предоставляют. И в любом случае получается слишком много предположений о квалификации среднего корпоративного разработчика.

Вместе с тем, стек WS-S создает ряд бизнес-возможностей, таких, как цифровые деньги, DRM-применения, распределенная аутентификация, и транзакции, в которых участвуют много сторон. Но так как последствия для безопасности от самостоятельного использования этих протоколов пока до конца не изучены, то WS-S рекомендуется применять не самостоятельно, а вместе с отлаженной базой SSL.

//Влад Боркус, www.konnasi.ru

Published 19 августа 2007 г. 23:09 by Vlad Borkus Edit
Filed under: SOA, Безопасность

Comments