Все больше и больше сайтов получают сертификаты безопасности – необходимые документы для внедрения HTTPS. Однако на сегодняшний день действующего механизма от злоупотреблений SSL не существует. Здесь вы найдете основную информацию о том, что делать в случае кражи секретного ключа и что необходимо предпринять, чтобы свести этот риск к минимуму.
Сертификаты
Темпы внедрения HTTPS сегодня достаточно быстрые – безопасность в сети достаточно актуальная тема. SSL сертификаты, обеспечивающие это безопасное соединение, становятся все более востребованными. Это актуально еще и потому, что самый популярный браузер объявил о предъявлении массового ультиматума сайтам, которые предлагают пользователям регистрироваться на сайтах, работающих по незащищенному протоколу http.
Процент сайтов из первого миллиона самых популярных сайтов по статистике Alexa, где стоит редирект на версию HTTPS
Как можно видеть на диаграмме, скорость внедрения HTTPS увеличивается. Судя по всему, это настоящий прогресс. При этом процесс получения сертификата безопасности становится более простым, в том числе, благодаря их бесплатным версиям от Let’s Encrypt.
Если вкратце, нужно просто отправить запрос на получение сертификата (Certificate Signing Request, CSR) в центр сертификации (CA), на что тот предложит доказать факт владения доменом. Обычно это делается с помощью изменения записи DNS TXT или размещения специального кода где-нибудь по случайному URL на домене. Как только задание выполнено, CA выдает сертификат, и мы можем предъявлять его браузерам и наслаждаться зеленым замком и указанием HTTPS в адресной строке.
Однако, что-то всегда может пойти не по плану.
Если вас хакнули
Как это не печально, но при наличии доступа к вашему серверу, хакеры могут получить что угодно. И зачастую им нужен именно секретный ключ. Сертификаты HTTPS – это публичные документы, которые вы отправляете каждому посетителю вашего сайта, но единственная вещь, которая не позволяет другим использовать такой же сертификат – отсутствие вашего секретного ключа. Когда браузер устанавливает защищенное соединение с сайтом, он проверяет, что у сервера есть секретный ключ для используемого сертификата. Вот почему никто не может использовать ваш сертификат. Однако, если этот секретный ключ заполучит хакер, ситуация резко меняется.
Если злоумышленник завладел вашим секретным ключом, в интернете он с легкостью сможет выдать себя за вас. То есть вероятность упустить свой секретный ключ существует и, если это случится, нужен способ помешать злоумышленнику использовать этот сертификат. Нужно его отозвать.
Отзыв сертификата
Итак, в случае компрометации возникает необходимость отозвать сертификат, чтобы исключить возможность злоупотреблений. Как только сертификат помечен как отозванный, браузер знает, что ему нельзя доверять, даже если у него не закончился срок действия. После того, как владелец запросил отзыв, ни один клиент принимать этот сертификат не должен.
Сертификат необходимо отзывать, как только факт взлома был установлен. Необходимо связываться с CA и попросить отозвать ваш сертификат. При этом нужно доказать факт владения сертификатом и после этого CA пометит сертификат как отозванный. Теперь нужен способ сообщить об этом факте каждому клиенту, которому может потребоваться данная информация. Прямо в этот момент браузер, конечно, ничего не знает, и это проблема. Есть два механизма, которые используются для распространения информации: это список отозванных сертификатов (Certificate Revocation List, CRL) и протокол проверки статуса сертификата (Online Certificate Status Protocol, OCSP).
Списки отозванных сертификатов
CRL – действительно очень простая концепция, это просто список всех сертификатов, которые CA пометил как отозванные. Клиент может отправить запрос к серверу CRL и скачать копию списка. Имея копию этого списка, браузер сверяет с ним предъявленный сертификат. Если он там присутствует, то браузер знает, что сертификат недействителен и ему нельзя доверять, он тогда выдаст ошибку и разорвет соединение. Если сертификата в списке нет, то все нормально – и браузер продолжит работу.
Проблема CRL в том, что списки содержат много сертификатов от конкретных центров сертификации. Не вдаваясь в излишние детали, они разбиваются на промежуточные сертификаты CA, а центр сертификации может выдавать списки меньшими частями, но проблема остается той же. Список CRL достаточно большой. Другая проблема в том, что у клиента нет свежей копии CRL, ему нужно запросить ее при первоначальном подключении к сайту, что может сделать всю процедуру заметно медленнее. Выглядит все это не очень приятно, так что посмотрим на OCSP.
Протокол проверки статуса сертификата
OCSP предлагает намного более красивое решение проблемы и имеет значительное преимущество перед CRL. Здесь нужно спросить у CA статус единственного, конкретного сертификата. Это значит, что CA должен вернуть только простой ответ: сертификат либо хороший, либо отозван, и такой ответ гораздо меньше по размеру, чем список CRL.
Конечно, OCSP превосходит CRL по скорости получения ответа, однако за это преимущество нужно платить и плата довольно высокая – ваша приватность… Если подумать о сути запроса OCSP, это очень конкретный запрос на единственный сертификат HTTPS. По сути, происходит утечка информации. Когда вы отправляете запрос OCSP, вы буквально спрашиваете у центра сертификации:
Сертификат для pornhub.com валидный?
Так что этот сценарий, к сожалению, не идеальный. Потому как таким образом вы выдаете историю посещенных сайтов некоей третьей стороне, о которой даже ничего не знаете, и все ради HTTPS, который вроде как должен повысить вашу приватность и безопасность. Но не спешите отчаиваться, есть кое-что еще…
Полный сбой
Выше сказано о CRL и OCSP, двух механизмах проверки сертификатов браузером, и они выглядят таким образом.
После получения сертификата, браузер обратится к одному из этих сервисов и отправит запрос для окончательного выяснения статуса сертификата. Но что будет, если у вашего CA плохой день и его инфраструктура в офлайне? Что, если ситуация выглядит так?
В таком случае у браузера может быть только два варианта решения ситуации. Он может отказаться принимать сертификат, так как попросту не способен проверить его статус. Или же взять на себя риск принять сертификат, не зная его статус (отозван он или нет). У обоих вариантов есть свои преимущества и недостатки. Если браузер откажется принимать сертификат, то каждый раз при уходе инфраструктуры центра сертификации в офлайн, ваши сайты тоже уйдут туда же. Если браузер продолжит принимать сертификаты, то он рискует принять сертификат, который был украден, и подвергнуть пользователей риску. Однако на сегодня ничего такого на самом деле не происходит.
Частичный сбой
Сегодня браузеры выполняют так называемую проверку отзыва сертификата с частичным сбоем. То есть браузер попытается проверить статус сертификата, но если ответ не пришел совсем или не пришел за короткий промежуток времени, браузер об этом просто “забывает”. Хуже всего, что Chrome даже не пытается проверить статус сертификата, который к нему поступает. Однако это вовсе не странно. Проблема с полным сбоем очевидна: если у CA плохой день, то он будет и у вас – так мы приходим к логике частичного сбоя. Браузер теперь пытается осуществить проверку сертификата на предмет отзыва, но полностью отказывается от нее, если она занимает слишком много времени или если кажется, что CA ушел в офлайн. То есть проверка сертификата на предмет отзыва отменяется, «если кажется, что CA ушел в офлайн». Интересно, может ли злоумышленник имитировать такие условия?
При осуществлении атаки MiTM для этого блокируется запрос на проверку сертификата и создается впечатление, что CA не работает. Браузер тогда столкнется с частичным сбоем проверки и продолжит использовать отозванный сертификат. Если вас никто не атакует, то каждый раз при проверке этого конкретного сертификата вы будете тратить время и ресурсы на проверку, что сертификат не отозван. И один раз, когда вас атакуют – тот единственный раз, когда вам по-настоящему нужна такая проверка – злоумышленник просто заблокирует соединение, и браузер будет проходить через частичный сбой.
Что ж, Адам Лэнгли из Google сравнил отзыв сертификата с ремнем безопасности, который вроде всегда должен вас защищать, но тут же подводит в момент аварии.
Исправление проблемы
На данный момент изменить эту ситуацию в корне возможности нет. Тем не менее, кое-что сделать можно и, возможно, в будущем механизм отзыва сертификатов станет по-настоящему надежным.
Приоритетные механизмы
Если сайт скомпрометирован и злоумышленник получил секретный ключ, он может подделать этот сайт и запустить этот фейк в сеть. Если это крупный информационный ресурс или же коммерческая организация, масштаб вероятной трагедии очевиден. Однако может быть и хуже. Что если CA скомпрометирован и злоумышленник получил секретный ключ для промежуточного сертификата? Это было бы катастрофой, потому что тогда злоумышленник может подделать буквально любой сайт, который захочет, подписав собственный сертификат. Поэтому вместо онлайновой проверки промежуточных сертификатов на предмет отзыва у Chrome и Firefox есть собственные механизмы для той же задачи.
В Chrome он называется CRLsets, а в Firefox – OneCRL. Эти механизмы проверяют списки отозванных сертификатов, объединяя доступные CRL и выбирая оттуда сертификаты. Так проверяются особо ценные сертификаты вроде промежуточных, но что насчет обычных?
OCSP Must-Staple
Чтобы объяснить, что такое OCSP Must-Staple, нужно сначала вкратце разобраться, что такое OCSP Stapling. Он избавляет браузер от необходимости отправлять запрос OCSP, выдавая ответ OCSP вместе с самим сертификатом. Название OCSP Stapling в буквальном смысле означает, что сервер должен «скрепить» (staple) ответ OCSP с сертификатом и выдать их вместе.
На первый взгляд это может показаться странным, потому что сервер как будто «сам удостоверяет» собственный сертификат как неотозванный, но все работает правильно. Ответ OCSP действует только короткий промежуток времени и подписан CA точно так же, как сертификат. Так что если браузер может удостовериться, что сертификат подписан CA, то точно так он может удостовериться, что ответ OCSP тоже подписан этим CA. Это устраняет большую проблему приватности и избавляет клиента от бремени выполнять внешний запрос. Но это так же не лучший вариант… OCSP Stapling – отличная вещь, и все мы должны поддерживать эту технологию на своих сайтах, однако злоумышленник этого делать не будет. Поэтому, действительно, что в этом случае нужно – это заставить сервер поддерживать OCSP Stapling, и вот для чего нужен OCSP Must-Staple. При запросе сертификата у CA нужно попросить установить на нем флаг OCSP Must-Staple. Этот флаг указывает браузеру, что сертификат должен поставляться с откликом OCSP или он будет отвергнут. Устанавливается он легко.
После установки этого флага вы должны гарантировать, что используется OCSP Staple, иначе браузер отвергнет сертификат. В случае компрометации, если злоумышленник получит ваш ключ, ему также придется использовать OCSP Staple вместе с нашим сертификатом, а если он не включит OCSP Staple, то ответ OCSP скажет, что сертификат отозван, и браузер его не примет.
OCSP Expect-Staple
Несмотря на то, что Must-Staple кажется отличным решением проверки отзыва сертификатом, это не совсем так. Одной из самых больших проблем является то, что оператор сайта не может точно знать, насколько надежны метки OCSP Staple и как их принимает клиент. Без включенного OCSP Must-Staple в этом не будет ничего страшного, но если включить OCSP Must-Staple, а в надежности или правильности OCSP Staple вы не уверены, для сайта это будет проблема. Чтобы попытаться и получить некую обратную связь о качестве меток OCSP Staple, можно активировать функцию под названием OCSP Expect-Staple. Подробности вы можете узнать в блоге OCSP Expect-Staple, здесь будет описано вкратце. Вдобавок к списку предзагрузки HSTS вы запрашиваете браузер прислать отчет, удовлетворен ли он меткой OCSP Staple. Вы можете собирать отчеты сами или использовать сервис report-uri.io – в обоих случаях вы точно узнаете, когда ваш сайт столкнулся с проблемами при работе OCSP Must-Staple. Поскольку использование списка предзагрузки HSTS не настолько очевидно, была создана спецификация для определения нового заголовка безопасности под названием Expect-Staple, чтобы обеспечивать ту же функциональность ценой меньших усилий. Идея заключается в том, что теперь вы можете установить этот заголовок и включить функцию отправки отчетов, которые так нам нужны, еще до активации Must-Staple. Установка заголовка будет простой:
Expect-Staple: max-age=31536000; report-uri="https://scotthelme.report-uri.io/r/d/staple"; includeSubDomains; preloadПоддельные сертификаты
В теме отзывов сертификатов есть место и теме об их подделке. Если некто пытается скомпрометировать CA или еще как-то заполучить чужой сертификат, то владелец ресурса сразу об этом может и не узнать. В компании может даже найтись инсайдер, который получит сертификат в обход внутренних процедур, и делать с ним все что захочет. Именно поэтому всем нам нужна стопроцентная прозрачность, обеспечить которую поможет Certificate Transparency.
Certificate Transparency
CT – новое требование, которое станет обязательным в начале следующего года. Оно предусматривает, что все сертификаты должны заноситься в публичный журнал для того, чтобы браузер им доверял. То есть суть этого нововведения в том, что CA заносит все выданные сертификаты в журнал CT.
Эти журналы полностью открыты, и любой желающий может их полистать. Поэтому, если кто-то получит сертификат на ваш сайт, здесь вы сразу же об этом узнаете. Для этой же цели существует сервис CertSpotter, а так же инструмент Facebook Certificate Transparency Monitoring, который присылает вам письмо каждый раз, когда выдан сертификат на заданный домен.
Авторизация центров сертификации
Предотвратить выдачу сертификата намного проще, чем пытаться отозвать его, и именно для этого нужна авторизация центров сертификации (CAA). Суть этого подхода в том, что вы можете авторизовать только конкретные центры сертификации выдавать вам сертификаты. Авторизация делается так же просто, как создание записи DNS:
scotthelme.co.uk. IN CAA 0 issue "letsencrypt.org"
Хотя авторизация CA – не особенно сильный механизм, и он не способен помочь во всех ситуациях некорректной выдачи сертификатов, но в некоторых случаях он полезен, так что следует заявить о своих предпочтениях, создав запись CAA.
И несколько слов напоследок
Как вы уже поняли, на сегодня отозвать сертификат, если кто-то завладел вашим секретным ключом, очень сложно. Один из вариантов предотвращения этой проблемы – это ограничить размер ущерба от утечки, сократив срок действия своего сертификата. Вместо трех лет указывайте один год или даже меньше. В частности, Let’s Encrypt выдает сертификаты, которые действительны всего лишь 90 дней. Сократив время жизни вашего сертификата, вы тем самым сократите возможный период зловредного использования его мошенником.
Источник: https://habrahabr.ru/
