Comments 8
Могу порекомендовать ещё пару тематических выпусков подкаста «Security Now», Очень подробное объяснение механизма отзыва и почему оно не очень хорошо работает.
Certificate Revocation Part 1
Certificate Revocation Part 2
Certificate Revocation Part 1
Certificate Revocation Part 2
Хорошее начало, так держать!
Ремарка, по поводу атак повторного использования на CRL.
УЦ выпускает CRL с периодичностью указанной у него в Регламенте, например раз в день.
Клиентский софт, должен загружать к себе CRL тоже с такой же периодичностью.
УЦ может выпустить CRL раньше срока например в середине дня, но клиентский софт его забирать в середине дня не будет, если явно не пнуть.
Когда подойдет время следующего обновления CRL, клиентский софт сам полезет на УЦ за новым CRL.
MITM подсунуть старый CRL (повторное использование) не сможет, поскольку у старого CRL протухнет дата (Next update), а подделать CRL нельзя так как он подписан УЦ.
Таким образом единственным случаем когда возможна атака повторного использования, это когда клиентский софт внепланово лезет за CRL, например проверяет его при каждом запросе, но проверка сертификатов по CRL не предназначена для online режима, как вы это обозначили раньше.
И еще. Проблема всей технологии PKI в том, что каждый интерпретирует/реализовывает ее по разному, а в некоторых случаях некоторые механизмы не реализовываются (не настраиваются админами) вовсе.
Ремарка, по поводу атак повторного использования на CRL.
УЦ выпускает CRL с периодичностью указанной у него в Регламенте, например раз в день.
Клиентский софт, должен загружать к себе CRL тоже с такой же периодичностью.
УЦ может выпустить CRL раньше срока например в середине дня, но клиентский софт его забирать в середине дня не будет, если явно не пнуть.
Когда подойдет время следующего обновления CRL, клиентский софт сам полезет на УЦ за новым CRL.
MITM подсунуть старый CRL (повторное использование) не сможет, поскольку у старого CRL протухнет дата (Next update), а подделать CRL нельзя так как он подписан УЦ.
Таким образом единственным случаем когда возможна атака повторного использования, это когда клиентский софт внепланово лезет за CRL, например проверяет его при каждом запросе, но проверка сертификатов по CRL не предназначена для online режима, как вы это обозначили раньше.
И еще. Проблема всей технологии PKI в том, что каждый интерпретирует/реализовывает ее по разному, а в некоторых случаях некоторые механизмы не реализовываются (не настраиваются админами) вовсе.
Тема очень интересная, конечно.
Но я вот хотел спросить — вы серьезно считаете, что у нас (ну у тех, кому это интересно) есть 40 минут на просмотр вашего видео?
Но я вот хотел спросить — вы серьезно считаете, что у нас (ну у тех, кому это интересно) есть 40 минут на просмотр вашего видео?
Мы не зря добавили 40-минутное видео именно в конец нашей статьи, чтобы те, у кого нет времени его смотреть, ограничились чтением данной статьи, а впоследствии — и ее второй частью, которая скоро выйдет и в которой то, что есть в видео, рассмотрено более подробно и детально.
Будем очень рады, если и у остальных наших читателей найдется время не только на прочтение статьи, но и на просмотр видео :)
Будем очень рады, если и у остальных наших читателей найдется время не только на прочтение статьи, но и на просмотр видео :)
Спасибо, буду ждать вторую часть.
Добрый день! А вот и вторая часть статьи про сертификаты :)
habrahabr.ru/company/neobit/blog/334714
habrahabr.ru/company/neobit/blog/334714
Sign up to leave a comment.
«Человек посередине», использующий отозванные сертификаты. Часть 1