Привет, коллеги! Я на RouterOS 7.16.2 и столкнулся с проблемой проверки сертификата DoH. Спойлер: /ip/dns/set verify-doh-cert=no|yes|yes-without-crl
Детали: DNS-конфигурация следующая:
servers: 1.1.1.1
dynamic-servers:
use-doh-server:
verify-doh-cert: no
doh-max-server-connections: 5
doh-max-concurrent-queries: 50
doh-timeout: 5s
Если сертификаты не установлены, то при использовании “/ip/dns/set verify-doh-cert=no” всё работает. Это заставляет думать, что “verify-doh-cert=no” полностью отключает все проверки; такое поведение меня не устраивает (оборудование находится в абсолютно ненадёжной среде), поэтому я хочу избежать MITM и включить проверку.
Если я устанавливаю цепочку сертификатов (промежуточный и корневой для cloudflare-dns.com) и включаю verify-doh-cert, то всё равно не работает, поскольку не может проверить сертификат по CRL, полученному из сертификата, и в логе появляется сообщение:
17:32:08 dns,error DoH server connection error: SSL: ssl: crl not found for: "C=US, S=California, L=San Francisco, O=Cloudflare, Inc., CN=cloudflare-dns.com" (6)
CRL в полученном сертификате следующие, и оба доступны онлайн, но отсутствуют в /certificate/crl/print после импорта промежуточного/корневого сертификата:
X509v3 CRL Distribution Points:
Full Name:
URI:
Full Name:
URI:
Когда я вручную добавляю эти два URL через /certificate/crl/add url=…, включение verify-doh-cert начинает работать. И вот в чём проблема. Ручное добавление CRL URL из конечных сертификатов – это путь к провалу: удалённый сайт может поменять сертификат без предупреждений, и если появятся другие CRL URL, разрешение DNS снова перестанет работать.
Так что, если я ничего не упускаю, это нужно исправить, и есть два варианта:
- как сделано для /tool/fetch check-certificate=(no|yes|yes-without-crl), добавить ‘yes-without-crl’ к параметру verify-doh-cert;
- динамически загружать CRL из полученных данных с разумным таймаутом, так что первый запрос будет задержан, а последующие будут использовать кеш.
Лично мне кажется, что первый вариант проще в реализации (код уже есть для /tool/fetch) и достаточно безопасен. Буду благодарен за любые комментарии. Если что-то упустил — пожалуйста, поправьте. Если это действительно проблема — есть ли шансы на её исправление? Спасибо!
Детали: DNS-конфигурация следующая:
servers: 1.1.1.1
dynamic-servers:
use-doh-server:
verify-doh-cert: no
doh-max-server-connections: 5
doh-max-concurrent-queries: 50
doh-timeout: 5s
Если сертификаты не установлены, то при использовании “/ip/dns/set verify-doh-cert=no” всё работает. Это заставляет думать, что “verify-doh-cert=no” полностью отключает все проверки; такое поведение меня не устраивает (оборудование находится в абсолютно ненадёжной среде), поэтому я хочу избежать MITM и включить проверку.
Если я устанавливаю цепочку сертификатов (промежуточный и корневой для cloudflare-dns.com) и включаю verify-doh-cert, то всё равно не работает, поскольку не может проверить сертификат по CRL, полученному из сертификата, и в логе появляется сообщение:
17:32:08 dns,error DoH server connection error: SSL: ssl: crl not found for: "C=US, S=California, L=San Francisco, O=Cloudflare, Inc., CN=cloudflare-dns.com" (6)
CRL в полученном сертификате следующие, и оба доступны онлайн, но отсутствуют в /certificate/crl/print после импорта промежуточного/корневого сертификата:
X509v3 CRL Distribution Points:
Full Name:
URI:
Full Name:
URI:
Когда я вручную добавляю эти два URL через /certificate/crl/add url=…, включение verify-doh-cert начинает работать. И вот в чём проблема. Ручное добавление CRL URL из конечных сертификатов – это путь к провалу: удалённый сайт может поменять сертификат без предупреждений, и если появятся другие CRL URL, разрешение DNS снова перестанет работать.
Так что, если я ничего не упускаю, это нужно исправить, и есть два варианта:
- как сделано для /tool/fetch check-certificate=(no|yes|yes-without-crl), добавить ‘yes-without-crl’ к параметру verify-doh-cert;
- динамически загружать CRL из полученных данных с разумным таймаутом, так что первый запрос будет задержан, а последующие будут использовать кеш.
Лично мне кажется, что первый вариант проще в реализации (код уже есть для /tool/fetch) и достаточно безопасен. Буду благодарен за любые комментарии. Если что-то упустил — пожалуйста, поправьте. Если это действительно проблема — есть ли шансы на её исправление? Спасибо!
