Сдвиги времени в сертификатах Let’s Encrypt
Неочевидные особенности веб-TLS в Интернете. Посмотрим на сертификат узла dxdt.ru, а точнее на разные таймстемпы, присутствующие в этом сертификате, выпущенном удостоверяющим центром (УЦ) Let’s Encrypt. Так, время в SCT-метках: Sep 4 20:35:05 2024 GMT (миллисекунды я не указываю), а начальная граница интервала валидности сертификата: Sep 4 19:36:35 2024 GMT. То есть, время меток позже почти ровно на один час. Как такое могло бы получиться? Естественно, вариант тут только один: УЦ Let’s Encrypt выпускает сертификаты, сдвинув время начала действия на час назад. То есть, что называется, “задним числом” (backdate), но только на один час. Реальное время заказа сертификата ближе к таймстемпу из SCT-метки – понятно, что данный УЦ не мог ждать один час, чтобы отправить пресертификат в лог. Тем не менее, это означает, что сертификат “действовал” за час до того, как его заказали.
Это известная особенность, неоднократно упоминавшаяся в обращениях в Let’s Encrypt. Её традиционно объясняют необходимостью учитывать возможные неточности часов у клиентов: то есть, сертификат выпускается за секунды и должен заработать мгновенно, но если у клиентского компьютера отстают часы, то он покажет ошибку, так как в сертификате время стоит позже момента валидации по “сдвинутым часам”.
Почему достаточно одно часа? Не ясно. Возможно, из-за летнего/зимнего времени. Возможно, из-за того, что в 60 минут укладывается бо́льшая часть обычного “дрейфа” локальных часов (она, конечно, укладывается минут в двадцать, но почему бы не взять один час?).
Как это коррелирует с тем, что в SCT-метке всё равно стоит актуальное время, которое оказывается “в будущем” и валидатор всё равно мог бы заругаться? Ну, наверное, эффект остался с тех пор, когда никакие SCT-метки в сертификаты не ставились, к тому же, опережение на час находится в допустимом интервале и валидаторы браузеров не пугает: лишь бы подписи сходились.
Означает ли это, что Let’s Encrypt выпускает пресертификаты (для добавления в CT-лог) “с упреждением”? Вряд ли. Но проверить это нельзя: технически, УЦ может какие угодно сертификаты у себя штамповать, на то он и УЦ. Выпуск пресертификата без факта его заказа и подтверждения прав управления DNS-именем – будет являться грубейшим нарушением принятых правил, но (пре)сертификат ещё должен утечь. Тем не менее, какого-то смысла в подобных фокусах не просматривается.
Вообще, даже и выпуск сертификатов “задним числом” – довольно серьёзное нарушение для УЦ: в своё время именно его использовали в качестве одной из причин для отзыва доверия браузеров к некоторому китайскому УЦ. Но, наверное, один час – это не так много. Обратите внимание на то, что в сертификатах нет никакого зонирования времени, там просто таймстемп, – в случае с CT-логами – миллисекундный, – поэтому списать данную особенность на разные часовые пояса не получится.
Адрес записки: https://dxdt.ru/2024/10/11/14051/
Похожие записки:
- Влияние систем ИИ на процессы в мире
- Постквантовые криптосистемы на экспериментальном сервере TLS
- Демонстрация утечек через ПЭМИН для видеокамер
- Microsoft и DNS-over-HTTPS
- Согласование траекторий автомобилей-роботов
- Интернет-протокол "дымовой завесы"
- Реестр параметров TLS IANA и именование индексов
- Реплика: программные "демультиплексоры" протоколов уровня приложений
- Симметрии и дискретное логарифмирование
- Системы счисления и системное администрирование
- Говорилки в google-поиске
Написать комментарий