Облака, ответственность и неожиданные ситуации с SSL-сертификатами

    При обсуждении облачных платформ вполне естественно возникает вопрос о надежности платформы и об ответственности провайдера за ее неполадки. При этом ожидания пользователей самые высокие – все должно идеально работать 25 часов в сутки, 9 дней в неделю и все дни в году. В реальном мире возникают всевозможные проблемы – то при отключении внешнего электроснабжения не отработает переход на резервное, то на дне емкости с дизтопливом окажется конденсат (вода), то 29 февраля «через год» вычислят увеличением года на единицу.

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

    Кто виноват, и что делать?

    За примерами далеко ходить не нужно — это может случиться с каждым. В конце февраля 2013 года истек срок действия сразу трех сертификатов сервиса Windows Azure Storage. Последовали хаос и череда разрушений, об этом много писали англоязычные сайты. Вообще замена сертификатов была запланирована заранее и выполнена почти полностью. Вот тут описано, почему замена не была проведена до конца и при этом никто ничего не заметил до того момента, когда стало уже слишком поздно. Очень рекомендуется к прочтению хотя бы в качестве сценария эпической трилогии и обязательно к прочтению перед тем как оставлять комментарии о радиусе кривизны рук.

    Давайте рассмотрим эту ситуацию внимательнее. Вскоре после часа Х появились вот эти два поста: раз и два. В них есть некий скриншот, на котором указаны URL, для которого предназначен сертификат, и срок действия сертификата. Примерно такой (только тут сертификат более новый и скриншот из другой программы):



    Откуда взялся этот скриншот? Может быть, это скриншот Enterprise версии какой-то суперпрограммы, доступной только одминам начиная с 80-го уровня, с лицензией за 100500 денег?

    Попробуем следующий эксперимент. То, что описано далее, многим покажется тривиальным (и совершенно справедливо), но оказывается, что очень многие специалисты даже не подозревали о таких запредельных возможностях ПО. Итак…

    Возьмем самый обычный браузер. Огнелис 20 подойдет, от выбора браузера будет зависеть только расположение элементов управления. Создаем пустую вкладку и в адресной строке набираем, например, github.com После того, как открывается заглавная страница GitHub, адресная строка выглядит вот так:



    Видите, там изображение замка и надпись “GitHub, Inc. (US)”. В эту надпись можно ткнуть мышью, появится вот такая форма с кнопкой.



    После нажатия на кнопку появляется форма с подробностями и среди прочего кнопкой View Certificate.



    Жмем на эту кнопку… КРАЙНЕ НЕОЖИДАННО…



    … точно такая же форма, как на самом первом скриншоте, с поправкой на конкретный сертификат.

    Вот так в совершенно произвольный момент времени мы выяснили, что сертификат github.com действителен по конец июля 2013 года. Нам не понадобилось никаких особых привилегий и никакого специального ПО. И самое главное, вся нужная информация постоянно — ежедневно и круглосуточно — была у всех на виду.

    Сейчас читатель уже рвется в комментарии, чтобы ехидно поинтересоваться, «а почему это мы должны проверять срок действия сертификата чужого сервиса». В самом деле, почему, ведь «это же не наш сертификат»?

    Давайте посмотрим, что именно происходит, когда истекает срок действия сертификата. У какого-то сайта был сертификат, действительный до, ну например, 30 февраля. Все браузеры и другие программы с удовольствием устанавливали защищенное соединение с этим сайтом. Вдруг наступило 31 февраля и срок действия сертификата истек. Что изменилось? Криптографические ключи по-прежнему ключи, а подпись на сертификате по-прежнему подходит к сертификату. Какой смысл в сроке действия?

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

    Соответственно, у клиента есть три варианта действия – либо надеяться на лучшее и установить соединение, либо предупредить пользователя (предупреждение наверняка будет проигнорировано) и установить соединение, либо отказаться устанавливать соединение и выдать сообщение об ошибке.

    Значительная доля ПО, в т.ч. Microsoft .NET Framework, по умолчанию идет по третьему пути. Соответственно, если, например, у нашего сервиса ABBYY Cloud OCR SDK истечет срок действия сертификата, многие наши пользователи не смогут работать с нами через защищенное соединение, потому что их ПО просто откажется устанавливать соединение.

    Именно это и произошло c Azure Storage в феврале. В Windows Azure часть сервисов зависит от Azure Storage. Поэтому, когда у Azure Storage истек срок действия сертификата, с ним отказались работать и засбоили не только сторонние сервисы пользователей, но и часть сервисов Windows Azure, в том числе перестало работать развертывание изменений и создание новых сервисов.

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

    Вы еще не передумали спрашивать, почему мы должны проверять сертификат стороннего сервиса?

    Это не особенно и сложно. Код для получения доступа к сертификату на C# занимает в пределах 10 строк – нужно создать WebRequest, отправить HTTP-запрос на сервер, затем обратиться к свойству ServicePoint.Certificate запроса. Примерно так:

    var request = (HttpWebRequest)(WebRequest.Create(uri));
    using(var response = request.GetResponse()) {
    }
    var serverCertificate = request.ServicePoint.Certificate;
    

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

    Теперь, когда за две недели до крайнего срока сертификат все же забудут обновить, это уже не будет ВНЕЗАПНО, можно будет заранее обратиться к провайдеру сервиса, оставить сообщение на форуме поддержки, пообщаться с компанией-перепродавцом сервиса – в общем, остается гораздо больше простора для действий.

    Или можно просто верить в провайдера, а потом объяснять своим пользователям, что «это все они виноваты». Виноваты «они», но чьи пользователи пострадают?

    Дмитрий Мещеряков,
    департамент продуктов для разработчиков
    ABBYY
    167,00
    Решения для интеллектуальной обработки информации
    Поделиться публикацией

    Похожие публикации

    Комментарии 14

      +6
        +2
        Приведённый код при протухшем серте выплюнет исключение в GetResponse, до получения request.ServicePoint.Certificate дело не дойдёт.
        Логику проверки сертификата лучше вынести в ServicePointManager.CertificateValidationCallback, где можно задать свои правила обработки. Например, игнорировать проблемы с истечением срока сертификата пару недель, как раз за это время владелец сервиса всё починит.
          0
          Это из серии «спрятать голову в песок, но не слишком глубоко». Представьте, что все заинтересованные прочитают ваш комментарий и последуют этому совету. Тогда просто у всех все сломается на пару недель позже.
            0
            Приведённый код при протухшем серте выплюнет исключение в GetResponse, до получения request.ServicePoint.Certificate дело не дойдёт.

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

            Перед этим кодом специально написано «примерно». Нужно еще учесть, что, например, Azure Storage возвращает HTTP 400 (Bad Request), если запросить URL, в котором не указан путь к конкретному элементу данных. В этом случае тоже будет исключение, его нужно обрабатывать. Но даже если и будет HTTP 400, сертификат загрузится с сервера и его можно будет проверить.
            +3
            Что хотел сказать автор?
            Что у сертификатов есть срок действия и для https его (ого!) можно увидеть прямо в браузере?
            Или что «большие папы» тоже косячат?
            Или что все сервисы, от которых зависит ваша система, нужно поставить но мониторинг?
              +1
              Вы так спрашиваете, как будто последнее утверждение всем очевидно. Обратите внимание, что истечения срока действия сертификатов Azure Storage в феврале можно было ожидать заранее, но тем не менее никто из пользователей ничего не заметил до момента, когда стало слишком поздно.
                0
                Я так спрашиваю, потому, что мне не понятен посыл статьи.
                Немного расширю свою точку зрения: пользователи Azure Storage и не должны были замечать, что сертификаты скоро закончатся.

                Объясню на личном примере: я работал тех. руководителем в организации, которая (в том числе) подключала десятками поставщиков услуг к своей системе. Т.к. у поставщиков услуг шлюзы, мягко говоря, работали не всегда так, как задумано (даже не по протоколам, разработанными этими поставщиками услуг — вроде и сходство есть, а вроде и не работает), то руководитель отдела интеграции от меня получил очень короткое, но ёмкое указание «предусмотреть ЛЮБУЮ нештатную ситуацию».

                Там и реверс инженеринг протоколов был. Там и сертификаты проверялись хитрым образом (кстати, большинство сертификатов были самоподписные) и система могла продолжить работу даже с невалидным сертификатом (при соблюдении некоторых других условий) и выдать предупреждение на саппорт. И ДНСу мы не доверяли, сохраняя ИПшники и выбирая подходящий вариант. И другой веселухи было много (кстати говоря, не всегда эти ухищрения помогали — один раз партнёр так хитро поменял роутинг, что вместо продакшн шлюза все наши запросы уходили на тест. после этого было желание начать статические маршруты прописывать). Но это всё делалось только из-за того, что партнёры подключались на «взаимовыгодных условиях».

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

                Я понимаю, что сравнивать по SLA несколько стоек в ДЦ и хостинг на Azure не совсем корректно, но какие-то уровни разграничения ответственности должны быть. Лично я бы после такой ерунды просто ушёл бы с Azure.
                  0
                  Посыл статьи предельно простой: есть такой риск, заранее принять меры очень легко и вы сами выбираете — принять меры заранее или надеяться на поставщика сервиса. Это не непредвиденная ситуация, потому что все нужные данные постоянно на виду.
                    0
                    Я вот тут написал абстрактно-развёрнутый комментарий, насколько мы не надеялись на поставщиков :)
              +1
              Все критичные сертификаты давно в Заббикс. Спим спокойно:)
                0
                Хорошо, но почему в феврале это не помогло?
                  +1
                  Мы мониторим свои сертификаты, которые нам критичны. На Azure не хостимся:)
                +2
                У нас в нагиосе есть проверка для наших SSL-сервисов на срок протухания сертификата. За месяц до протухания выдаёт warning, потом CRITICAL.

                Легко гуглится по nagios plugin certificate expiration или подобным.
                  0
                  Можно начать с заданий попроще — например с доменных имен.

                  Infox.ru — достаточно крупный сетевой игрок СМИ, срок регистрации домена истек 2013.05.01, регистратор не сменил делегирование домена, и вот аккурат через месяц 2013.06.01 домен будет выключен и удалён (поправка на ветер — 2013.06.04, выходные всё же).

                  Хотя можно только догадываться, ведь делегирование закончившегося домена должно было сняться автоматически. Либо это VIP-клиент и ему просто так его не снимают (ага, можно вспомнить тот же Хабр или Ulmart), либо на домен наложены судебные санкции (но гуглится мало, только иск о защите деловой репутации, как раз завтра заседание).

                  Интересен другой факт — владельцы доменов частенько узнают об окончании регистрации домена только тогда, когда он будет выключен (читай заменен на заставку регистратора). И уже носятся сломя голову — как продлить домен и пнуть cctld dns сервера.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое