Неожиданная особенность проверки сертификатов в Windows

Немного затянул с публикацией, но лучше поздно чем никогда. В начале рабочей недели появились задержки при подключении по RDP ко всем компьютерам, оно подвисало на несколько секунд в стадии «Securing remote connection…», которая отвечает за установку шифрованного канала для безопасной передачи реквизитов.
TL; DR
При недоступности ctldl.windowsupdate.com возможны задержки при установке соединений через SSL/TLS, старайтесь этого избегать.

Так как для RDS используются сертификаты от внутреннего CA и уже когда-то забыв обновить CRL корневого офлайнового CA решил проверить его здоровье в pkiview.msc.
Оснастка показала, что всё OK, но напротив обоих CA несколько секунд держался статус Verifying, что странно, так как все данные для проверки доступны внутри домена через LDAP и HTTP. Проверка через certutil -verify также подвисала на 10–15 секунд в стадии CERT_CHAIN_POLICY_BASE, причем с любыми сертификатами — не только от внутренних, но и от внешних CA (StartCom, Comodo и т.д.).

Проблема не ушла и после перерегистрации сертификатов с CRL в CDP и AIA. Отчаявшись, захватил сетевой дамп во время выполнения certutil -verify и увидел там следующее:

35332424b8364f1a92510b8f14bc1df2.png

Трейс до ctldl.windowsupdate.com показал zapret.comcor.ru в пути, а его IP-адрес (CDN Akamai) оказался добавлен 01.08.2016 в реестр блокировки РКН.

Оказывается в Windows 8.1 (и позднее портирован в Vista, 7 и 8) появился механизм динамической загрузки списков доверенных и недоверенных удостоверяющих центров на случай появления новых или их компрометации. Обновление происходит при первой установке SSL-соединения, для проверки можно выполнить команду certutil -syncWithWU C:\Temp, которая выгружает списки в папку для компьютеров без доступа в интернет.

Списки загружаются с адреса ctldl.windowsupdate.com, но у провайдера сломалась страница-заглушка и соединения к запрещённым ресурсам блокировались по IP-адресу, что вызывало таймаут в 15 секунд при установке каждого соединения.

Подробное описание нового механизма есть на TechNet, для обходного решения таймаут можно задать через групповые политики в разделе Public Key Policies > Certificate Path Validation Settings > Network Retreival:

f9f61e24dc7145e084e339a0e1885ab3.png

Пока гуглил описание механизма наткнулся на блог исследователя, где он описывает алгоритм работы на примере своей утилиты CTLInfo, которая умеет показывать содержимое и срок действия списков.

Комментарии (1)

  • 17 августа 2016 в 06:28

    0

    Это вообще проклятие современных сетей — зависимость одного сервиса от сетевой доступности совсем другого, постоянно приходится под капот со сниффером лезть.

© Habrahabr.ru