Комментарии 13
Погодите-ка... Т.е. я правильно понимаю, что можно CRL использовать для блокировок по домену при ставшей для нас обыденностью MITM атаке втч со стороны провайдера?
OCSP хотя бы пытался в HTTPS, а CRL не умеет by design.
Ну и это правильно же! CRL - это публичный текст, одинаковый для всех, защищённый от модификации цифровой подписью. Нафиг его шифровать ещё сверху? Шифрование ради шифрования всех достало уже и подпортило Интернет.
Lets Encrypt понятно почему предпочитает CRL: у них сертификаты краткосрочные, а просроченные сертификаты в список добавлять смысла нет, поэтому список всегда небольшой получается. Кто сертификаты на 5 лет выдаёт, у тех иное мнение бывает.
Ну и это правильно же! CRL - это публичный текст, одинаковый для всех, защищённый от модификации цифровой подписью. Нафиг его шифровать ещё сверху? Шифрование ради шифрования всех достало уже и подпортило Интернет.
Нет, это не правильно - это даёт атакующему возможность даунгрейднуть список. Например, атакующий завладел валидным сертификатом для example.com и одновременно имеет ресурсы, чтобы провести на вас MitM-атаку. Он подсунет вам по HTTP старую версию списка отозванных сертификатов, который валиден, подписан, но, вот беда, в этой старой версии ещё не содержится запись об отозванном сертификате example.com
Бывают и более неочевидные моменты, скажем, нашумевшая уязвимость, позволявшая прослушивать трафик беспроводной сети Wi-Fi без прохождения авторизации. Понадеялись на шифрование уровнем выше? А оно оказалось дырявым и злоумышленник уже проник через периметр, внутри которого защиты нет, потому что админа что-то там достало. Ну, а теперь его ещё и атакующий достал, лол.
Поэтому шифрование ради шифрования это наше всё, а полагаться на один слой защиты не стоит.
С другой стороны, как представитель лагеря любителей пролезать туда, куда меня не хотят пускать, я всячески поддерживаю админов-шифрофобов и прочих раздолбаев - они здорово облегчают жизнь. Мой любимый пример: когда разработчик одного интересного ПО отправил сам себе на почту SSH-ключ от своего сервера. Ключ он скачал, но письмо не удалил. И всё бы ничего, но этот замечательный человек был ярым противником двухфакторной авторизации, что позволило довольно быстро сбрутить пароль от почты.
Не понятен наезд на crl. Это просто файл. Передавать его можно как по http, так и по https. Либо строго по https. Вопрос только в том, чтобы клиентская сторона tls всегда запрашивала сертификат сервера и проверяла его валидность. Чтобы так работал tls протокол, нужно его настроить соответствующим образом на клиенте и на сервере.
В итоге, клиент проверяет сертификат сервера и затем - подписанный crl уц. Первое - гарантирует, что crl пришел из правильного места. Второе- что сам crl валидный.
Т.о. при правильной настройке проблем с безопасностью для crl-нет.
Другое дело, что если УЦ и публикующий сервер- это разные информационные системы, то могут быть задержки со своевременной публикацией нового crl, какие-то проблемы с недонастроенными цепочками сертификатов уц и web-сервера. и т.д. Но это - уже тонкости конкретных реализаций и к общей концепции безопасности pki они отношения не имеют.
Претензии к CRL известны: большой объем данных для загрузки, нагрузка на сервер УЦ, неработоспособность схемы из-за недоступности третьей стороны (списка отзыва). В общем, все то, что решает OCSP со сшиванием. А еще CRL прекрасно MitMться путем подсовывания корректно подписанного, но не актуального списка отзыва.
Если речь об аутентичном CRL, выпущенном УЦ на момент действия сертификата, то этот CRL должен быть отклонен, если текущая дата больше даты notAfter в CRL. Если речь создании CRL третьей стороной от имени УЦ, то это уже компрометация УЦ, и вопрос должен решать CRL вышестоящего УЦ
механизм 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.
что касается новых вариантов обмена. их надо изучать на предмет различных угроз. ввиду сложности новых механизмов, безопасники не спешат их разрешать, пока не появятся вменяемые исследования кибер-специалистов.
например, идея сшивки мне кажется очень подозрительной. и нужно долго моделировать ситуации, чтобы убедиться, что это будет работать не хуже
про корректно подписанный, но не актуальный- не понял. если вы имеете ввиду ныне устаревший, но ранее валидный crl, так их нужно брать со строго установленного источника по https с обменом на сертификатах, я об этом говорил.
Да, берем настоящий список, компрометируем один сертификат из него и творим свое черное дело. Если наша хитрость раскрывается и скомпрометированный сертификат вносят в список как отозванный - митмим клиентов и отдаем им по HTTP тот самый настоящий, но старый список, в котором нет еще скомпрометированного сертификата. Клиент хочет HTTPS? Извините, не поддерживается. Клиент настаивает? Извините, host not found, timeout request, 403 (нужное - подчеркнуть)!
OCSP Stapling избавляет от описанного и назвать ее новой как-то жестоко. CRL вон тоже недавно называли устаревшим и дропали его в пользу простой OCSP, а поди ж ты - теперь снова живее всех живых. ЧСХ, на сайте LE сертификат с OCSP и без CRL.
У себя в корпоративной сети мы можем закрутить гайки по самое небалуй и вообще устанавливать TLS на сертификатах с двух сторон, но есть еще остальной Интернет с его зоопарком более-менее стандартизированных агентов пользователя (часть из которых уже не умеет в CRL) и скорее менее, чем более квалифицированных пользователей, которые пользуются тем, что дают без дальнейших настроек.
если говорить про юзеров в инете, то им вообще по барабану crl. Т.е. устанавливается шифрованное соединение с сервером и норм. И пофиг, что сертификат сервера протух. Конечно, браузеры пищат и пытаются что-то там проверять, но как указал ранее, они не знают откуда брать правильные crl-ы. Далеко не во всех ca указаны точки дистрибьюции crl. И здесь помимо crl-а может быть куча мест для подлога.
Имеет смысл говорить о crl именно для случаев авторизации клиента, например, в госуслугах. Т.е. когда серверу ОЧЕНЬ важно проверить валидность сертификата клыента. Но, как уже сказал, сервер является корпоративной системой. И в ней можно настроить все то, о чем говорил.
Были у нас случаи в банке, когда прилетал непонятный сертификат и проверить его не получалось на известных СА УЦ. Безопасники описали эту ситуацию так: клиент че-то там важное присылает и делает квалифицир. подпись сертификатом какого-то нового УЦ. При этом, клиент готов ждать минут 5, после чего идет в другой банк. Возник вопрос - а чего вы от разработки то хотите? Чтобы мы автоматом в систему закинули чей-то ca,crl, ctl и на них валидировали документы вашего клыента? Безопасники ушли чесать репу.
Ну, то есть, со стороны сервера доверенные точки дистрибьюции crl известны заранее. И это проблема безопасников их своевременно как-то обновлять.
А проблема удостоверения серверных сертификатов пока решается только лишь путем успешного хендшейка на сертификатах. Никакие crl-ы или иные механизмы вас здесь не спасут.
К слову, ocsp решает какие-то проблемы только если сама прога УЦ выставляет этот сервис в инет. Иначе, опять возникают интеграционные задержки. А это, как понимаете, не самая мудрая мысль ввиду ddos,так на переполнение буфера и прочих прелестей, которые пойдут мимо всех файрволов прямиком в систему УЦ.
Так что, улучшая механизм crl, вы получаете новые риски в карту безопасности общего решения. А серьезные дядьки на каждый такой риск должны сделать систему мониторинга наступления этого риска, описать сценарий действий при наступлении риска. Установить sla устранения риска.Короче, заняться риск-менеджментом. И делать это никому не хочется. Со старыми crl куда как проще: все риски давно прописаны, а обновление crl раз в пару дней - никого не напрягает. В те редкие случаи, когда надо быстро отозвать сертификат - вызванивают руками нужный уц.
Были у нас случаи в банке, когда прилетал непонятный сертификат и проверить его не получалось на известных СА УЦ.
Именно что это не забота разрабов, или не только и не в первую очередь их, т.к. сперва есть куча НПА по ЭП вообще и в банковском секторе в частности, затем договор банка с клиентом, и лишь затем... В сферическом случае в вакууме я бы сказал, что это суверенное право клиента пользоваться сертом хоть от УЦ "Фишинг и скаминг", но см. выше.
Товарищ автор, ваши фантазии ничего общего с реальностью не имеют
OCSP всё?