Хабрахабр

[Перевод — recovery mode ] Revocation сертификатов — не работает

Revocation сертификатов не работает

Прямо сейчас в интернете наличествует некая проблема, и, насколько я могу судить, с течением времени она лишь становится серьёзнее: всё большее и большее число сайтов получают сертификаты (что необходимо для запуска HTTPS), но у нас нет способа защитить себя, если «что-то пойдет не так».

Сертификаты

Помимо очевидных преимуществ HTTPS (связанных с безопасностью и конфиденциальностью), есть ещё несколько причин, по которым вам может захотеться перейти на безопасное соединение, которое я описываю в своей статье «Вы всё ещё думаете, что вам не нужен HTTPS?». В настоящее время тема сертификатов довольно актуальна, поскольку все больше и больше сайтов развертывают HTTPS. Каждый день я запрашиваю в интернете страницы первого миллиона сайтов из топа Alexa, и анализирую для каждого различные аспекты безопасности, а затем, раз в 6 месяцев, публикую отчет. Сертификаты (те, что часто называются «SSL-сертификатами» или «сертификатами HTTPS») всё более востребованы, и выдаются со скоростью, которую мы никогда не видели за всю историю интернета. Вы можете посмотреть отчеты здесь, но главный результат, на котором нужно сосредоточиться здесь и сейчас — это всё более растущая распространенность HTTPS.

процент сайтов, перенаправляющих посетителей на версию с https

переводчика: очевидно, до точки насыщения). Мало того, что мы продолжаем внедрять HTTPS, но и сама скорость, с которой мы это делаем, увеличивается (прим. Процесс получения сертификата с течением времени становился все более и более простым, а сейчас, благодаря удивительному сервису Let’s Encrypt, получение их стало ещё и бесплатным. Выше вы можете видеть, как выглядел прогресс в последние годы, а Firefox Telemetry дает еще более наглядные цифры на графике процента страниц, загруженных по HTTPS.

Как только эта проверка удастся, CA выпустит необходимый сертификат, и мы сможем использовать его при настройке HTTPS на веб-сервере. Грубо говоря, мы отправляем в Центр сертификации (Certificate Authority, или CA) запрос на выпуск сертификата (Certificate Signing Request, или, короче, CSR), CA, со своей стороны, проверяет, действительно ли мы управляем доменым именем, для которого запросили сертификат (для этого нас просят создать в DNS-зоне домена определенного вида TXT-запись, либо разместить файл со трудноугадываемым именем и определенным содержимым по случайному пути на сайте, работающем на нашем домене).

процесс получения сертификата

посты по поводу get started, smart renewal и dual certificates). Я даже сделал несколько руководств, чтобы помочь вам с получением и настройкой использования сертификатов (см. Проблема в том, что не всё идет, как задумывалось, и новости для нас не самые приятные. Это все здорово, и что же тут плохого?

«Нас взломали»

Хакеры пробуют пробраться на наш сервер множеством уже известных (и новых) способов, и, когда они получают доступ к нашему серверу, они могут получить и секретную часть нашего сертификата, так называемый Private Key. Никто никогда не хочет услышать подобные слова, но печальная реальность заключается в том, что их всё же приходится слышать, и чаще, чем любой из нас хотел бы.

Публичная часть сертификата, который мы использовали для настройки HTTPS, являются общедоступной; наш веб-сервер отправляем её любому, кто подключается к нашему сайту, и браузер этого посетителя использует полученную от нас публичную часть нашего сертификата, чтобы зашифровать информацию, передаваемую от браузера на наш сервер — при этом расшифровать эту зашифрованную информацию можно только при помощи второй, секретной, части того же сертификата. Как вы знаете, сертификат состоит из двух частей: секретной (private key) и публичной (public key), обе эти части должны размещаться на веб-сервере для того, чтобы настроить HTTPS. Но если злоумышленник получит доступ к секретной части сертификата, картина существенно изменится. Поскольку ни у кого, кроме нас, нет секретной части сертификата, то никто не сможет использовать наш сертификат.

server compromise gives attacker our private key

показывать всем, что он — это мы. Если злоумышленнику удастся заполучить секретный ключ нашего сертификата, он сможет изображать нас (точнее, наш сервер), т.е. Это действительно проблема, и, прежде чем вы решите, что «со мной такого никогда не случится», вспомните пресловутый [Heartbleed] (http://heartbleed.com/)! Ещё раз: в Интернете окажется кто-то, кто может доказать, что он — это вы, при этом не будучи вами. Кроме того, секретные ключи могут оказаться известны злоумышленникам случайно или по неосторожности — и вероятность такого события также следует учитывать. В тот раз крошечная ошибка в коде библиотеки OpenSSL позволяла злоумышленнику украсть закрытый ключ сертификата с веб-сервера даже при отсутствии ошибок в конфигурации веб-сервера. Другими словами, нам нужно будет отозвать сертификат. Примите как данность, что наш закрытый ключ может тем или иным образом стать известным кому-то плохому, и, когда это произойдет, нам понадобится механизм, как не дать злоумышленнику использовать наш сертификат.

Аннулирование (revocation) сертификата

Как только сертификат окажется помечен как отозванный, браузер поймет, что ему нельзя доверять, даже если он не истёк по времени. Столкнувшись с утечкой частей сертификата, мы, как это называется, аннулируем, или отзываем (помечаем как отозванный) наш сертификат, чтобы злоумышленник не смог его использовать. Если владелец сертификата запросил аннулирование сертификата для своего домена, ни один клиент, очевидно, не должен принимать этот сертификат.

requesting a revocation

Нам потребуется подтвердить право владения соответствующим сертификатом, и, как только мы это сделаем, центр сертификации пометит у себя в системе сертификат как отозванный. Как только мы узнаём, что у нас случилась утечка данных сертификата, мы связываемся с CA, выпустивший сертификат, и просим их, чтобы они произвели отзыв сертификата. Пока браузер не узнает об отзыве, он продолжит принимать сертификат, как если бы никакого аннулирования не произошло. Теперь сертификат отозван, и нам нужно как-то сообщить об этом факте любому веб-клиенту в мире. На сегодня существуют два механизма, которые мы можем использовать, чтобы сделать эту информацию доступной всем:

  1. Списки отозванных сертификатов (Certificate Revocation List, или CRL)
  2. Протокол состояния сетевого сертификата (Online Certificate Status Protocol, или OCSP).

Certificate Revocation List, более известные как CRL

Клиент может связаться со специальным сервером CRL этого CA, и загрузить их CRL. CRL в буквальном смысле представляет собой список всех сертификатов, которые конкретный СА (выпустивший их ранее) пометил как отозванные. Если сертификат в списке, браузер точно знает, что сертификату нельзя доверять, а следует вывести ошибку и прекратить соединение. Вооруженный копией списка, браузер сможет проверить, указан ли сертификат, который ему предоставили, в этом списке. Если же сертификата нет в списке, то все в порядке, и браузер может продолжить соединение.

downloading a CRL

Очень много. Проблема с CRL состоит в том, что они содержат много отозванных сертификатов от конкретного CA. Более того, что, если у клиента нет свежей копии CRL данного CA, он должен как-то загрузить её во время первоначального подключения к сайту, что может заметно замедлить процесс первого соединения. Да, эти списки разбиваются по промежуточным сертификатам, которые есть у CA, плюс CA может разбивать списки на более мелкие фрагменты по другим принципам, но суть, которую я хочу подчеркнуть, остается неизменной: CRL, как правило, имеют весьма приличный размер, что мешает загрузить такой список быстро. Другими словами, не всё так просто, поэтому давайте познакомимся со вторым вариантом, а именно с OCSP.

Online Certificate Status Protocol, или OCSP

С помощью OCSP мы запрашиваем у CA статус отдельного конкретного сертификата. OCSP обеспечивает более красивое решение вопрос проверки статуса сертификата, плюс имеет другие преимущества по сравнению с подходом CRL. Прекрасно! Всё, что CA должен в ответ сделать — это дать простой и короткий ответ, не отозван ли этот сертификат (буквально, сообщить, сертификат «валиден» или «отозван»; такой ответ по размеру куда меньший, чем передача всего CRL).

fetching an OCSP response

В данном случае платой выступает ваша конфиденциальность. Действительно, OCSP даёт значительное преимущество в скорости по сравнению с получением объемного CRL, но за всё приходится платить (вы, наверное, ненавидите эту фразу?).

запрос о статусе одного конкретного сертификата — означает разглашение информации о том, на какой конкретно сайт вы заходите. Если вдуматься, то запрос OCSP — т.е. Когда вы (ваш браузер) отправляете запрос OCSP, вы, по сути, спрашиваете CA:

Валиден ли сертификат для pornhub.com?

Вы (возможно, даже не осознавая этого) сообщаете какой-то третьей стороне свою историю посещений, и всё это во имя HTTPS, который задумывался с целью обеспечить вам больше безопасности и конфиденциальности. Не самый идеальный вариант, правда? Но подождите, это ещё не всё! Иронично, не так ли?

А если проверка не удалась?

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

crl and ocsp checks

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

crl and ocsp servers down

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

Если ответ не был получен, либо (что вернее) не был получен в течение достаточно короткого периода времени, браузер просто «забудет» про необходимость проверки. На сегодня мы имеем такое поведение браузера: он пробует произвести проверку аннулирования сертификата. Да, вы правильно прочитали: Chrome даже не пытается проверить статус отзыва сертификатов, с которыми он сталкивается. Хуже того, Chrome вообще не проверяет аннулирование. Однако, если вдуматься, в этом есть смысл.

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

Проверка аннулирования отменяется, если «как кажется, сервера CA недоступны». Стоп, что это была за последняя фраза? Интересно, может ли злоумышленник смоделировать такую ситуацию?

an attacker blocking a revocation check

сделать так, чтобы для клиента сервера CA были недоступны. Если у нас есть (некий воображаемый) злоумышленник, способный и желающий выполнить атаку MiTM, всё, что ему нужно, просто заблокировать запрос статуса аннулирования, т.е. Неприятно: вы можете годами заходить на сайт, пока он не взломан, и на каждом заходе ваш браузер будет производить все проверки аннулирования сертификата, а в тот раз, когда вы зайдёте на этот же сайт, но подвергшийся взлому, проверка аннулирования не среагирует, поскольку взломщик сделает так, что проверка не даст никакого ответа — и браузер примет такой итог за разрешение зайти на сайт. После этого браузер провалит проверку и продолжит успешно использовать, возможно, уже отозванный сертификат. Годы затрат ресурсов клиента на проверки — а в нужный момент проверка просто не произойдет и не убережет нас!

Решения вопроса

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

Собственные, проприетарные механизмы

Это не хорошо, но может быть и хуже. Если сервер оказался взломан, и злоумышленник завладел закрытым ключом, он может выдать сайт на своем сервере за исходный сайт, и причинить немало вреда. Это будет катастрофа совсем другого масштаба, потому что злоумышленник сможет выдать себя за любой другой сайт, подписав свои собственные сертификаты для любого домена. Представьте, что случится, если окажется скомпрометирован сам CA, и злоумышленник получит доступ к закрытому ключу для промежуточного сертификата CA? Вместо того, чтобы проводить онлайн-проверки для отзыва промежуточных сертификатов, Chrome и Firefox имеют свои собственные механизмы, которые работают одинаково.

CRLsets and OneCRL

Обе компании формируют собственные списки отозванных сертификатов, выбирая для них данные из доступных списков отзыва сертификатов. Chrome называет их CRLsets, а Firefox — OneCRL. Так что, ценные сертификаты, такие, как промежуточные сертификаты CA, оказываются прикрытыми, но как насчет ваших и моих?

OCSP Must-Staple

Я не буду вдаваться в подробности (вы можете прочесть подробнее в моем блоге: OCSP Stapling. Чтобы объяснить, что такое OCSP Must-Staple, нам сначала понадобится краткая справка о идее под названием OCSP Stapling. Это называется Stapling (буквально — подшивка), потому что смысл идеи в том, что сервер запрашивает OCSP ответ от CA, затем, словно бы степлером, «подшивает» полученный ответ OCSP к сертификату на домен сайта, и отправляет клиенту их оба вместе. Вкратце, OCSP Stapling позволяет браузеру выполнить проверку OCSP, получив ответ OCSP вместе с сертификатом.

OCSP stapling in action

Ответ OCSP действителен только в течение короткого периода времени, и он подписан со стороны CA так же, как и сам сертификат. На первый взгляд это кажется немного странным, потому что сервер почти «самосертифицирует» свой собственный сертификат как не отозванный, но, по сути, всё разумно. Это решает проблему конфиденциальности с OCSP, а также избавляет клиента от необходимости выполнять этот внешний запрос. Таким образом, если браузер может проверить, что сертификат был получен от CA, он может проверить и что ответ OCSP также пришел от CA. Победа!

OCSP Stapling как идея — великолепна, и мы все должны использовать его на наших сайтах, но можем ли быть уверены, что злоумышленник включит OCSP Stapling у себя на сервере? Но на самом деле все не так радужно. Нам нужен способ заставить сервер использовать OCSP Staple, этой цели и служит вещь под названием OCSP Must-Staple. Я так не думаю. Это всего лишь флаг, который устанавливается CA в сертификате при его выдаче, и этот флаг указывает браузеру, что сертификат обязательно будет передан с сервера в комплекте с ответом OCSP, в противном случае должен быть отклонен.

ocsp must-staple in CSR

В случае компрометации и получения злоумышленником нашего ключа, для его использования ему также придется настроить работу OCSP Staple. Теперь, когда у нас есть сертификат с установленным соответствующим флагом, мы, как хост, должны убедиться, что мы правильно настроили OCSP Staple, иначе ни один браузер не примет наш сертификат. Класс! Если злоумышленник не настроит поддержку OCSP Staple, браузер отклонит сертификат (потому что флаг OCSP Must-Staple в сертификате предпишет это сделать), а если всё же настроит OCSP Staple, то в ответе OCSP будет указано, что сертификат отозван, и браузер отклонит его.

an attacker trying to use a must-staple certificate

OCSP Expect-Staple

Одна из самых больших проблем, с которыми я сталкиваюсь, заключается в том, что я, как оператор сайта, на самом деле не знаю, насколько надежно я использую OCSP и всех ли клиентов устраивают «сшитые», благодаря OCSP Staple, ответы моего веб-сервера. Хотя Must-Staple звучит как отличное решение проблемы отзыва, это еще не совсем так. Чтобы попытаться получить некоторую обратную связь о том, как мы работаем с точки зрения сшивания OCSP, мы можем включить функцию под названием OCSP Expect-Staple. Без включенного OCSP Must-Staple это не было бы проблемой, но если мы включим OCSP Must-Staple, а затем не будем правильно или надежно использовать OCSP Staple, наш сайт перестанет открываться.

Вы можете собирать отчеты самостоятельно, или использовать мой сервис report-uri.io, главное, что вы сможете точно узнавать, когда столкнетесь с проблемами, если вы включили OCSP Must-Staple. Я писал об этом раньше, и вы можете получить все подробности в моем блоге в посте OCSP Expect-Staple, вкратце это выглядит так: вы запрашиваете добавление в список HSTS preload записи, заставляющей браузер отправлять вам отчёт, если ему почему-то не понравится настройка OCSP Staple на вашем сервере. Идея заключается в том, что теперь вы можете установить этот заголовок и включить отчеты, чтобы получить обратную связь, в которой мы отчаянно нуждаемся, прежде чем включать Must-Staple. Поскольку добавление в список предварительной загрузки HSTS не так просто, как хотелось бы, я подготовил спецификацию для определения нового заголовка безопасности под названием Expect-Staple для предоставления той же функциональности, но с меньшими затратами усилий. Включение заголовка будет простым, как и все другие заголовки безопасности:

Expect-Staple: max-age=31536000; report-uri="https://scotthelme.report-uri.io/r/d/staple«; includeSubDomains; preload

Мошеннические сертификаты

Если кому-то удастся взломать CA, или иным образом получить сертификат на доменное имя, которым не владеет, как мы об этом узнаем? Еще одна вещь, которую мы должны учитывать, когда говорим об отзывах сертификатов — это так называемые мошеннические сертификаты. Возможно, у вас в организации есть нечестные сотрудники, которые в обход всех ваших внутренних процедур получили сертификат на домен организации (у другого CA, нежели тот, у кого получала сертификат ваша компания), и используют его для своих целей. Если бы я прямо сейчас нашёл дыру в защите CA, и получил бы сертификат на домен вашего сайта, не сказав вам об этом, вы бы никогда не узнали об этом, пока новость об этом не разошлась бы достаточно широко. Нам нужен механизм обеспечения полной прозрачность процесса выдачи сертификатов, и он называется Certificate Transparency.

Certificate Transparency

Вы можете прочитать про CT поподробнее, но в общем случае CA регистрирует все сертификаты, которые он выдает, в журнале CT. CT — это требование, чтобы все сертификаты, которым браузер должен доверять, были бы зарегистрированы в открыто доступном журнале.

certificate transparency log

Например, здесь вы можете видеть все сертификаты, выданные для моего домена, или использовать для того же сервис CertSpotter от sslmate. Эти журналы являются общедоступными, и каждый желающий, например, может поискать в них имя своего домена, поэтому конечный смысл CT состоит в том, что, если каким-то из CA для вашего сайта будет выдан сертификат, вы узнаете об этом. CT — фантастически хорошая идея, но (как обычно) есть момент, на который следует обратить внимание: CT — это только первый шаг. Я использую инструмент Facebook Certificate Transparency Monitoring, который умеет отправлять по электронной почте уведомление каждый раз, когда происходит выдача нового сертификата для конкретного домена. Тем не менее, если мы можем решить только одну проблему за раз, то лучше начинать с CT, поскольку даже существование лучших в мире механизмов отзыва не имеет смысла, если мы не знаем о сертификатах, которые нам необходимо отозвать. Знание списка выдаваемых сертификатов — это здорово, но у нас сохраняются все вышеупомянутые проблемы с отзывом их.

Certificate Authority Authorization (CAA)

Если кратко, то идея заключается в том, что мы можем разрешить выдавать нам сертификаты только определенным CA. Остановить выдачу сертификата гораздо проще, чем пытаться отозвать его, и это именно то, зачем придумана Certificate Authority Authorization. Это очень просто, достаточно создать одну запись DNS:

scotthelme.co.uk. IN CAA 0 issue "letsencrypt.org"

Хотя CAA не является особенно мощным механизмом, чтобы помочь во всех возможных сценариях ошибочной выдачи сертификатов, кое в чём он точно полезен, так что стоит выразить свои предпочтения в смысле выбора CA, и создать запись CAA для своего домена.

Несколько слов напоследок

Только представьте, чем это закончится в следующий раз, когда появится очередной Heartbleed! В настоящее время существует реальная проблема: мы не можем отозвать сертификат, даже если кто-то тем или иным образом получит его закрытый ключ. Вместо трех лет брать его на один год или даже меньше. Чтобы попытаться ограничить влияние утечки, вы можете сократить срок действия сертификатов, которые вы получаете. С уменьшением срока валидности вашего сертификата у вас будет меньше проблем, даже если случится утечка сертификата, потому что у злоумышленника останется меньше времени на злоупотребление сертификатом до окончания срока его действия. Let’s Encrypt выдает сертификаты вообще на срок в 90 дней! Помимо этого, мы пока мало что можем сделать.

Но, кажется, это та еще история! Итак, у нас остается исходный вопрос: должны ли мы исправить механизмы аннулирования сертификатов, и как?

06. Оригинальный текст датирован 03. Тем не менее, я изменил часть текста так, чтобы изложенное отражало текущее положение дел — однако выдавать статью за свою всё же не считаю возможным. 2017, однако, к сожалению, материал не утратил актуальность.

Теги
Показать больше

Похожие статьи

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть