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

>

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

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

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

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

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

Реклама

>Недостатки wildcard-сертификатов: 11 комментариев

  1. Arman Obosyan

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

    Нравится

  2. Arman Obosyan

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

    Нравится

  3. Alexander Trofimov

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

    Нравится

  4. Arman Obosyan

    >ИМХО, все немного притянуто по рискам использовать WildcardЕдинственный рикс это оставлять везде ключ, но насчет его хранения тоже не актуальная тема, а пароли все где вы храните? в файле на сервере? или используйте соответствующие системы для этого…Касательно публикаций, забыл добавить что также в основном используются и аппаратные балансировшики в них то и хранятся заветные ключики, тогда можно говорить и о их уязвимостях…А вот действительный минус Wildcard так это то что его не везде можно использовать, точнее есть системы которые не поддерживают wildcard к примеру OCS R2…мой вердикт риски от wildcard на столько малы что не стоит зацикливаться на этом, и в тоже время вся безопасность должна быть как и положена на уровне, а там где халатность там и взломы и проколы…

    Нравится

  5. Anonymous

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

    Нравится

  6. Vadims Podāns

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

    Нравится

  7. Ivan Gunkov

    Есть способ обойтись без wildcard.Если у вас не так много поддоменов к примеру 2 или 3, то можно обойтись установкой тремя обычными сертификатами. К примеру на сайте Emaro-ssl самые дишевые стоят 490 руб.

    Нравится

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s