При обсуждении облачных платформ вполне естественно возникает вопрос о надежности платформы и об ответственности провайдера за ее неполадки. При этом ожидания пользователей самые высокие – все должно идеально работать 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 каждого из сервисов, от которых зависит наш сервис. Заодно не вредно проверять и свой собственный сертификат. Если у какого-нибудь сертификата срок действия истекает менее чем, скажем, через две недели, отправляем себе уведомление. Да, хорошо бы, чтобы эти уведомления читал кто-то, кто сможет на них реагировать.
Теперь, когда за две недели до крайнего срока сертификат все же забудут обновить, это уже не будет ВНЕЗАПНО, можно будет заранее обратиться к провайдеру сервиса, оставить сообщение на форуме поддержки, пообщаться с компанией-перепродавцом сервиса – в общем, остается гораздо больше простора для действий.
Или можно просто верить в провайдера, а потом объяснять своим пользователям, что «это все они виноваты». Виноваты «они», но чьи пользователи пострадают?
Дмитрий Мещеряков,
департамент продуктов для разработчиков
Автор: DmitryMe
