Р
Разумеется первым, что бросилось в глаза было отсутствие рекламы. Появился резонный вопрос: за счёт чего окупается подобное решение, не бесплатный ли это сыр (конечно, просто бесплатное ПО уже никого не удивляет, но поддержание WEB-сервера требует приличных расходов)? Ответ нашёлся прямо в описании сервиса : компания позиционирует себя как поставщика комплексных решений для организаций и в том числе продаёт расширенную коммерческую версию данного сервиса.
Сразу оговорюсь, что проверялась только бесплатная версия данного сервиса. Не забывайте об этом, особенно читая последний пункт: "приципиальные недостатки".
Недостатки собственно сервиса.
Стойкость данного сервиса зависит от двух компонентов:
стойкости клиентского ПО;
стойкости самого сервера ( в меньшей степени);
Результаты проверки клиентского ПО
Предполагалось, что пользователь не держит одновременно открытых окон с другими страничками из неизвестных источников и использует последние версии браузеров свободные от ошибок. Вообще хочу подчеркнуть, что при работе с любой Web-почтой недопустимо открывать предложенные в письмах неизвестные ссылки не выйдя из сервиса. Особенно в сервисах с поддержкой процессов Java.
Рассматривались две типовые схемы:
а) Возможность несанкционированного исполнения тегов и JavaScript в письме.
Наличие такой возможности позволило бы атакующему выполнять любые команды криптобиблиотеки.
Использованный S-Mail подход был достаточно кардинален: фильтруются все
теги и опасные символы. К сожалению вкралась пара ошибок в автоматическое распознавание и обработку ссылок привёдшая к возможности вставит в них операторы обработки событий (например onMouseOver срабатывавший при наведении мышки).
При этом операторы JS виднелись в тексте ссылки, что позволяло опытному пользователю избежать атаки.
Рекомендации: внимательнее смотреть на текст письма и пользоваться своевременно обновляемыми браузерами.
б) ошибки криптобиблиотеки, позволяющие лицу имеющими доступ к к серверу дешифровать отдельные письма.
Практически применимых слабостей обнаружено не было.
Имелись лишь некоторые теоретические слабости, недостаточные для самостоятельного использования (при выполнении вышеописанных условий).
Ни одна из описанных уязвимостей не позволяла украсть пароль или секретный ключ.
В этом форуме и на bankir.ru активно обсуждаются потенциальные слабости генерации секретного ключа, но к единому мнению пока не пришли. Скорее всего слабость останется в разряде теоретических.
Ошибки сервера:
Найти ошибку позволившую взломать сервер ( имеется в виду хотя бы получение контроля над WWW) мне не удалось.
Задача получения доступа к хранилищу (логам) почты (списку абонентов и адресатов, теме (subj), дате писем) относится к более лёгким и её удалось решить дважды. В обеих случаях найденная ошибка устранялась почти мгновенно ( в течении пары часов с момента отправки письма). Разумеется, доступ к логам не означал каких-то дополнительных возможностей по прочтению текста письма, т.к. для шифрования используются очень стойкие методы. Заодно это служило неплохим подтверждением пользы хранения писем в зашифрованном виде, т. к. аналогичная возможность на обычных серверах приводила к свободному чтению корреспонденции.
Должен сказать, что количество и опасность обнаруженных ошибок по отношению к затраченному времени были очень малыми для службы насчитывающей меньше полугода от роду. Обычно, даже поверхностный взгляд на новую web-почту давал более серьёзные последствия.
Принципиальные недостатки использованных решений:
Самым спорным решением авторов системы безусловно является пароль. Как уже отмечалось во "вступлении" он же является ключом для шифрования секретных ключей. Его размер конечно, не ограничен.
В то же время, как отметили в обсуждении на bankir.ru почти все присутствовавшие там специалисты по криптографии (А. Волчков, А. Репан,"Экспертик") редкого пользователя удаётся заставить использовать более чем десяти-символьный моно-алфавитный пароль.
Соответственно количество вариантов для перебора у большинства пользователей составит не более, чем 70^10 ~= 10^19. Этого, разумеется, мало.
Но трудно обвинять в этом почту, просто потому, что никто не мешает пользователю выбрать ключ любого размер и алфавита. Например фразу. Также следует учесть, что пока не видно других простых и удобных решений по защите секретного ключа хранящегося на сервере. В общем: "Спасение утопающих- дело рук...". Единственное, что можно поставить в упрёк - отсутствие указаний на роль пароля при его выборе.
Другим слабым моментом является хранение открытых ключей на самом сервисе s-mail что приводит к объединению каналов получения ключа и передачи данных (см. ч.3 "АШК и Интернет"). Причина этого решения также очевидна - известные мне другие хранилища ключей платные.
О том, как бороться с этими недостатками читайте в ч.2.
|
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
