Certificate Revocation Lists (CRL, список отозванных сертификатов) появился в 1999 году в RFC2585. Принцип его работы прост до безобразия: агент пользователя с некоторой периодичностью загружает списки отозванных TLS-сертификатов у известных ему удостоверяющих центров (УЦ) и сверяет по ним сертификаты, предъявляемые сайтами для защиты соединения.
В конце XX века кто бы мог подумать, что количество сайтов будет измеряться миллионами и значительная их часть, если не большинство, станут защищать соединение с собой, что подразумевает использование TLS-сертификата. А сертификаты по разным причинам отзывают, а сайтов миллионы, а списки пухнут, а трафик и нагрузка на сервера УЦ растут экспоненциально… В общем, вы понимаете масштаб проблемы с CRL к середине третьего десятка лет XXI века.
Одновременно с CRL появился Online Certificate Status Protocol (OCSP, протокол онлайн [проверки] статуса сертификата). Агент пользователя получает от сайта TLS-сертификат и запрашивает у выдавшего его УЦ статус оного сертификата: айс или не айс? Современно, «бюджетно», молодежно; казалось бы, что могло пойти не так? Но кто в конце XX века задумывался о privacy, интернет-слежке, цифровых отпечатках и вот этом вот всем? Авторы RFC2560 точно не задумывались и зевнули деликатный момент: при запросе статуса сертификата чувствительная информация неизбежно раскрывается третьей стороне – УЦ, которому агент пользователя рапортует, на какой сайт зашел этот самый пользователь.
Есть у OCSP и другие недостатки, например, если сайт УЦ недоступен, проверить статус предъявленного TLS-сертификата невозможно. Кроме того, OCSP подвержен той же уязвимости, что и CRL: поскольку запрос статуса сертификата как правило производится через незащищенное соединение (HTTP), цена ответу на этот запрос – грош, да и тот ломаный. OCSP хотя бы пытался в HTTPS, а CRL не умеет by design.
Впрочем, основные проблемы OCSP решались его расширением Certificate Status Request, более известным как OCSP Stapling (сшивание [ответов] OCSP). Сайт, с которым агент пользователя устанавливал защищенное соединение, отправлял в дополнение к TLS-сертификату свежую «справку» от УЦ: сертификат не отозван. Справка «подшивалась» к сертификату и заверялась все тем же открытым ключом выдавшего ее и сертификат УЦ.
Таким образом, посетители сайта не устанавливали еще одно соединение – с сайтом УЦ, его недоступность в данный момент роли не играла, сайт УЦ не дергали постоянно десятки, тысячи, миллионы посетителей окормляемых УЦ сайтов (а только сами эти сайты, и то куда реже), чувствительная информация никуда не утекала, и все это ценой незначительного в масштабах
Мечта? Мечта, но в эту мечту поверили чуть более чем никто и OCSP Stapling до настоящего времени не стал популярным. За все время существования нашего проекта «Монитор госсайтов» мы встречали сертификаты с поддержкой OCSP Stapling хорошо если на каждом десятом исследуемом сайте (причем, на сайтах региональных госорганов они используются заметно чаще, чем федеральных).
Вот и сказочке конец: год назад CA/Browser Forum решил, что поддержку OCSP его члены могут обеспечивать по настроению левой пятки, тогда как CRL – в обязательном порядке. Google Let’s Encrypt уже обогнала паровоз, пригрозив в обозримой перспективе вовсе дропнуть поддержку OCSP, вся надежда на Microsoft, которая не входит в CA/Browser Forum и могла бы состроить Корпорации Злого Бобра козью морду, включив требование поддержки OCSP Stapling в условия участия в Microsoft Trusted Root Program. Как думаете, разразится эта битва якодзун?
Комментарии (12)
MountainGoat
29.07.2024 11:49+4OCSP хотя бы пытался в HTTPS, а CRL не умеет by design.
Ну и это правильно же! CRL - это публичный текст, одинаковый для всех, защищённый от модификации цифровой подписью. Нафиг его шифровать ещё сверху? Шифрование ради шифрования всех достало уже и подпортило Интернет.
Lets Encrypt понятно почему предпочитает CRL: у них сертификаты краткосрочные, а просроченные сертификаты в список добавлять смысла нет, поэтому список всегда небольшой получается. Кто сертификаты на 5 лет выдаёт, у тех иное мнение бывает.
dartraiden
29.07.2024 11:49+3Ну и это правильно же! CRL - это публичный текст, одинаковый для всех, защищённый от модификации цифровой подписью. Нафиг его шифровать ещё сверху? Шифрование ради шифрования всех достало уже и подпортило Интернет.
Нет, это не правильно - это даёт атакующему возможность даунгрейднуть список. Например, атакующий завладел валидным сертификатом для example.com и одновременно имеет ресурсы, чтобы провести на вас MitM-атаку. Он подсунет вам по HTTP старую версию списка отозванных сертификатов, который валиден, подписан, но, вот беда, в этой старой версии ещё не содержится запись об отозванном сертификате example.com
Бывают и более неочевидные моменты, скажем, нашумевшая уязвимость, позволявшая прослушивать трафик беспроводной сети Wi-Fi без прохождения авторизации. Понадеялись на шифрование уровнем выше? А оно оказалось дырявым и злоумышленник уже проник через периметр, внутри которого защиты нет, потому что админа что-то там достало. Ну, а теперь его ещё и атакующий достал, лол.
Поэтому шифрование ради шифрования это наше всё, а полагаться на один слой защиты не стоит.
С другой стороны, как представитель лагеря любителей пролезать туда, куда меня не хотят пускать, я всячески поддерживаю админов-шифрофобов и прочих раздолбаев - они здорово облегчают жизнь. Мой любимый пример: когда разработчик одного интересного ПО отправил сам себе на почту SSH-ключ от своего сервера. Ключ он скачал, но письмо не удалил. И всё бы ничего, но этот замечательный человек был ярым противником двухфакторной авторизации, что позволило довольно быстро сбрутить пароль от почты.
supermaxus
29.07.2024 11:49Не понятен наезд на crl. Это просто файл. Передавать его можно как по http, так и по https. Либо строго по https. Вопрос только в том, чтобы клиентская сторона tls всегда запрашивала сертификат сервера и проверяла его валидность. Чтобы так работал tls протокол, нужно его настроить соответствующим образом на клиенте и на сервере.
В итоге, клиент проверяет сертификат сервера и затем - подписанный crl уц. Первое - гарантирует, что crl пришел из правильного места. Второе- что сам crl валидный.
Т.о. при правильной настройке проблем с безопасностью для crl-нет.
Другое дело, что если УЦ и публикующий сервер- это разные информационные системы, то могут быть задержки со своевременной публикацией нового crl, какие-то проблемы с недонастроенными цепочками сертификатов уц и web-сервера. и т.д. Но это - уже тонкости конкретных реализаций и к общей концепции безопасности pki они отношения не имеют.
ifap Автор
29.07.2024 11:49Претензии к CRL известны: большой объем данных для загрузки, нагрузка на сервер УЦ, неработоспособность схемы из-за недоступности третьей стороны (списка отзыва). В общем, все то, что решает OCSP со сшиванием. А еще CRL прекрасно MitMться путем подсовывания корректно подписанного, но не актуального списка отзыва.
MrFuNTiK
29.07.2024 11:49Если речь об аутентичном CRL, выпущенном УЦ на момент действия сертификата, то этот CRL должен быть отклонен, если текущая дата больше даты notAfter в CRL. Если речь создании CRL третьей стороной от имени УЦ, то это уже компрометация УЦ, и вопрос должен решать CRL вышестоящего УЦ
ifap Автор
29.07.2024 11:49notAfter легко может быть позже даты компроментации и отзыва конкретного сертификата.
supermaxus
29.07.2024 11:49механизм crl -старый и не рассчитан на большие нагрузки (отзыв сертификатов каждый час), но там есть разные костыли, которые позволяют использовать его до сих пор.
например, не обязательно выпускать все сертификаты строго на одном са. можно сделать несколько sub-ca и тогда список crl сокращается в несколько раз. а уж несколько тысяч строк в crl-это разговор ни о чем. файл о несколько десятков килобайт.
если все сертификаты в crl имеют not after меньше текущей даты, то список можно обнулить. ну или выбить из него такие сертификаты.
можно выдавать сертификаты на ограниченный срок. практически все центры выдают их на год или меньший срок.
про корректно подписанный, но не актуальный- не понял. если вы имеете ввиду ныне устаревший, но ранее валидный crl, так их нужно брать со строго установленного источника по https с обменом на сертификатах, я об этом говорил.
если даже некто попытается стать man in the middle,то поскольку шифрование в tls соединении происходит на сертификатах и их ключах, то такой man тупо не сможет завершить даже handshake tls, а не то чтобы передать устаревший crl.
опять же, говорил ранее, что сам tls может работать и вообще без шифрования, может и на слабых ключах, может и на прегенеренных ключах без клиентского сертификата. эти все штуковины нужно отключать на сервере для такого случая. а у клиента должен быть готов сертификат, который сервер опознает валидным для целей обмена по tls.
это нормально, когда ваша система вводится в эксплуатацию, вы определяете круг источников сертификатов+crl и прописываете у себя их ca (напомню, есть еще ctl списки, их тоже нужно учитывать). просто тупо брать в инете чей-то crl и пытаться его использовать - это дыра в безопасности. с течением времени, безопасники добавляют новые источники и удаляют не действующие. обычная история в банке. сам делал такие процессы.
т.о. 1 задача здесь сводится к установлению НАДЕЖНОГО (не на словах) соединения к вполне конкретному источнику и уж потом ставится задача предачи в таком соединении списка crl.
что касается новых вариантов обмена. их надо изучать на предмет различных угроз. ввиду сложности новых механизмов, безопасники не спешат их разрешать, пока не появятся вменяемые исследования кибер-специалистов.
например, идея сшивки мне кажется очень подозрительной. и нужно долго моделировать ситуации, чтобы убедиться, что это будет работать не хуже
ifap Автор
29.07.2024 11:49про корректно подписанный, но не актуальный- не понял. если вы имеете ввиду ныне устаревший, но ранее валидный crl, так их нужно брать со строго установленного источника по https с обменом на сертификатах, я об этом говорил.
Да, берем настоящий список, компрометируем один сертификат из него и творим свое черное дело. Если наша хитрость раскрывается и скомпрометированный сертификат вносят в список как отозванный - митмим клиентов и отдаем им по HTTP тот самый настоящий, но старый список, в котором нет еще скомпрометированного сертификата. Клиент хочет HTTPS? Извините, не поддерживается. Клиент настаивает? Извините, host not found, timeout request, 403 (нужное - подчеркнуть)!
OCSP Stapling избавляет от описанного и назвать ее новой как-то жестоко. CRL вон тоже недавно называли устаревшим и дропали его в пользу простой OCSP, а поди ж ты - теперь снова живее всех живых. ЧСХ, на сайте LE сертификат с OCSP и без CRL.
У себя в корпоративной сети мы можем закрутить гайки по самое небалуй и вообще устанавливать TLS на сертификатах с двух сторон, но есть еще остальной Интернет с его зоопарком более-менее стандартизированных агентов пользователя (часть из которых уже не умеет в CRL) и скорее менее, чем более квалифицированных пользователей, которые пользуются тем, что дают без дальнейших настроек.
supermaxus
29.07.2024 11:49если говорить про юзеров в инете, то им вообще по барабану crl. Т.е. устанавливается шифрованное соединение с сервером и норм. И пофиг, что сертификат сервера протух. Конечно, браузеры пищат и пытаются что-то там проверять, но как указал ранее, они не знают откуда брать правильные crl-ы. Далеко не во всех ca указаны точки дистрибьюции crl. И здесь помимо crl-а может быть куча мест для подлога.
Имеет смысл говорить о crl именно для случаев авторизации клиента, например, в госуслугах. Т.е. когда серверу ОЧЕНЬ важно проверить валидность сертификата клыента. Но, как уже сказал, сервер является корпоративной системой. И в ней можно настроить все то, о чем говорил.
Были у нас случаи в банке, когда прилетал непонятный сертификат и проверить его не получалось на известных СА УЦ. Безопасники описали эту ситуацию так: клиент че-то там важное присылает и делает квалифицир. подпись сертификатом какого-то нового УЦ. При этом, клиент готов ждать минут 5, после чего идет в другой банк. Возник вопрос - а чего вы от разработки то хотите? Чтобы мы автоматом в систему закинули чей-то ca,crl, ctl и на них валидировали документы вашего клыента? Безопасники ушли чесать репу.
Ну, то есть, со стороны сервера доверенные точки дистрибьюции crl известны заранее. И это проблема безопасников их своевременно как-то обновлять.
А проблема удостоверения серверных сертификатов пока решается только лишь путем успешного хендшейка на сертификатах. Никакие crl-ы или иные механизмы вас здесь не спасут.
К слову, ocsp решает какие-то проблемы только если сама прога УЦ выставляет этот сервис в инет. Иначе, опять возникают интеграционные задержки. А это, как понимаете, не самая мудрая мысль ввиду ddos,так на переполнение буфера и прочих прелестей, которые пойдут мимо всех файрволов прямиком в систему УЦ.
Так что, улучшая механизм crl, вы получаете новые риски в карту безопасности общего решения. А серьезные дядьки на каждый такой риск должны сделать систему мониторинга наступления этого риска, описать сценарий действий при наступлении риска. Установить sla устранения риска.Короче, заняться риск-менеджментом. И делать это никому не хочется. Со старыми crl куда как проще: все риски давно прописаны, а обновление crl раз в пару дней - никого не напрягает. В те редкие случаи, когда надо быстро отозвать сертификат - вызванивают руками нужный уц.
Worst_su
Погодите-ка... Т.е. я правильно понимаю, что можно CRL использовать для блокировок по домену при ставшей для нас обыденностью MITM атаке втч со стороны провайдера?
psi_lion
CRL подписываются так же, как и сами сертификаты. Если CA не отозвала сертификат, то атакующему просто нечего вставлять в трафик, поэтому конкретно от отзыва сертификата без ведома CA этот протокол защищён