понедельник, 7 марта 2011 г.

Недостатки wildcard-сертификатов

imageПо такому запросу некоторые пользователи заходят ко мне на блог. Что ж, недостатки определенно есть, так что почему бы и не написать об этом? Но сначала: что же из себя представляют эти загадочные сертификаты диких карт или, как иногда это тоже переводят, подстановочные сертификаты.

Чтобы защитить коммуникации с веб-страницами или веб-сервисами (это к примеру, список больше, разумеется) мы используем SSL-сертификаты. Должен сказать, что на самом деле это не означает, что увидев префикс https и валидный сертификат мы можем быть уверены в том, что это настоящий сайт, настоящий сертификат и что общение с сайтом действительно защищены, но это тема отдельной дискуссии. В любом случае, прекрасны сертификаты или ужасны, это наша реальность, с которой нужно жить. Поэтому, как только Вы оказываетесь владельцем хоть сколько-нибудь большой инфраструктуры с множеством веб-сайтов, сервисов и тому подобного, и каждый из таких сервисов должен защищаться своим собственным сертификатом. Почему? Думаю, не раскрою никакого секрета, напомнив, что сертификат выписывается в таких случаях на определенное доменное имя, то есть microsoft.com, www.microsoft.com и technet.microsoft.com должны иметь разные сертификаты. Так что в вышеописанной ситуации Вы оказываетесь погребены под десятками и сотнями сертификатов, которые истекают, их нужно обновлять, наблюдать за их состоянием и так далее. Чертова прорва работы, иной раз, однако “безопасность должна быть безопасной” и все такое.

Впрочем, мир остался бы в каменном веке без ленивых людей, знаете ли. Так что эти лентяи изобрели wildcard-сертификаты. Они выпускаются на имена типа *.microsoft.com и могут таким образом быть использованы с любым поддоменом домена microsoft.com. Это как бы решает все описанные выше проьлемы. Правда ведь? На самом деле это действительно так, но ничто не бывает бесплатным и данный случай вовсе не исключение. Если Вы используете один такой сертификат в своей организации, то его секретный ключ лежит везде, где используется сертификат (существуют сервисы, которые могут выдавать разные сертификаты с одним именем, но тогда зачем вообще заморачиваться?). Статистически это означает, что риск скомпрометировать этот конкретный сертификат возрастает многократно. А сменить его после компрометации придется на всех узлах. Некоторые думают, что это вовсе и не проблема, но тогда зачем использовать сертификаты? =) Предположим, что мы считаем это все-таки проблемой, но не слишком большой, тогда, как я уже говорил выше, добавьте к этой проблеме стоимость аудита всех скомпрометированных систем (а мы ведь можем считать во многих случаях, что все, что работало на этом сертификате - скомпрометировано). Поверьте мне, аудит нескольких систем – вовсе не дешевое занятие. И не дающее стопроцентного результата, зачастую.

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

Подытожим: я однозначно не фанат такого решения. По крайней мере в своем нынешнем положении и на своей работе. Про себя же Вы можете решить сами Winking smile

11 комментариев:

Arman Obosyan комментирует...

...то его секретный ключ лежит везде, где используется сертификат...

Если при импорте указывать чтоб он был нонэкспортебл, то разве есть возможность выдрать его из системы?

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

Arman Obosyan комментирует...

Да и забыл добавить,
обычно при публикации сервисов, выводятся они через Application Firewall ака обратные прокси (Reverse Proxy) паблишер он как правило один или два, там-то только и присутствует тот самый секретный ключ, на всех внутренних серверах уже обычные внутренние сертификаты, как правило такой метод правильней других.

Alexander Trofimov комментирует...

привет.
1) Если бы не было возможности вытащить сертификат, то не появились бы никогда смарт-карты и прочие токены =) По сути, exportable, не exportable, а ключ просто лежит на файловой системе. Да, защищенный, зашифрованный, но все-таки. Разумеется, это не будет делаться как "раз-два-три", но это возможно. По поводу "если злоумышленник проник..." и далее по тексту. Все так, всегда сам это говорил. Только одно дело, "проник в одну систему" или "проник везде". Масштаб проблемы тоже имеет значение, как мне кажется. Опять-таки, раз ты ставишь везде один и тот же ключ, значит, ты его где-то хранишь вместе с секретной частью. Его и оттуда можно вынести. С уникальными ключами проблем меньше - установил и удалил. Или вообще выписал прямо с сервера, тогда и вовсе секретный ключ существовал только на сервере, по сути.
2) Да, это лучше, чем использование везде wildcard-сертификата, но:
а) ты уже говоришь, что то, что внутри используются другие сертификаты, улучшает ситуацию. почему бы не улучшить ее совсем и не использовать их на reverse proxy? =)
б) Даже банальные реверс прокси для этого не всегда и не везде применяются.
Но в целом, я и не говорил, что wildcard certificates определенно зло. Просто нужно понимать, что все имеет свою обратную сторону. Тебе стало удобнее? Посмотри, где может жать в будущем.

Arman Obosyan комментирует...

ИМХО, все немного притянуто по рискам использовать Wildcard

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

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

А вот действительный минус Wildcard так это то что его не везде можно использовать, точнее есть системы которые не поддерживают wildcard к примеру OCS R2…

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

Alexander Trofimov комментирует...

Видно, я тебя не убедил. Бывает. =)

Анонимный комментирует...

Про вытаскивание сертификатов - можно включить агента(ов) восстановления. Точнее, в ряде случаев, это необходимо сделать :)

Alexander Trofimov комментирует...

А это как-то повышает безопасость? Или я что-то не понял?

Vadims Podāns комментирует...

С одной стороны верно, но с другой..учитывая стоимость такого сертификата можно раскошелиться на net hsm и тогда вопрос компрометации можно отложить до лучших времён. Хотя, с hsm свои тараканы есть. Но как вопрос укрепления защиты закрытого ключа — почему бы и нет?

Alexander Trofimov комментирует...

Согласен. Хотя про тараканов тоже было сказано все верно. Тараканы иногда перевешивают.

виктор золочевский комментирует...

есть еще одна большая опасность при использовании вилдкард сертификата:
- возможность создания "невидимого" (для владельца сертификата) сайта с использованием сертификата

Alexander Trofimov комментирует...

Согласен.