20 Апрель 2017

Использование DNS для управления выдачей SSL-сертификатов

Using DNS to control SSL certs issuance

Вопросы обеспечения безопасности различных сервисов в сети Интернет занимают существенное место в тематике статей этого сайта. Это не случайно, поскольку именно эта проблематика с каждым годом становится всё более важной частью работы во всемирной сети являясь существенным стимулом для технологического прогресса.

Среди последних проявлений такого прогресса можно отметить и недавнее решение CA/Browser Forum о необходимости обязательного использования контроля DNS-записей типа CAA (Certification Authority Authorization) в процессе выдачи SSL-сертификатов начиная с сентября 2017 года.

1. Механизм

Сам механизм Certification Authority Authorization впервые был описан в RFC6844 и определяет специальный новый тип DNS-записей CAA при посредстве которых центры сертификации (CA) должны принимать решение о выдаче или не выдаче запрошенного данным хостом сертификата. При помощи таких записей владелец домена может заявить о том, какой именно центр сертификации имеет право выдавать SSL-сертификаты для данного домена, а также способ уведомления о попытке неавторизованной выдачи таковых.

Запись типа CAA имеет три подтипа, которые регулируют выдачу сертификатов для конкретного домена и его поддоменов (ключ issue), выдачу сертификатов типа wildcard (ключ issuewild), а также упомянутый выше способ уведомления о проблемах (ключ iodef). Например, для домена kostikov.co в рамках которого работает этот сайт, DNS записи для реализации Certification Authority Authorization могут выглядеть следующим образом.

kostikov.co        IN CAA  0 issue "letsencrypt.org"
kostikov.co        IN CAA  0 issuewild ";"
kostikov.co        IN CAA  0 iodef "mailto:abuse@kostikov.co"

В первой строке указано, что сертификаты kostikov.co может выдавать исключительно центр сертификации Let's Encrypt многие аспекты работы с сертификатами которого были рассмотрены в ранее опубликованных статьях. Выдача сертификатов типа wildcard запрещена, о чём свидетельствует специальный служебный символ ";" во второй строке. Соответственно, при данной конфигурации записей CAA любой центр сертификации, кроме Let's Encrypt, не должен выпускать сертификаты для данного домена. И, наконец, уведомления о возможных несанкционированных попытках выдачи таких сертификатов будет отправляться на указанную электронную почту. Здесь также возможно указать и адрес автоматизированного обработчика в соответствии со стандартом RFC5070.

Если есть необходимость в том, чтобы для поддоменов сертификаты мог выдавать другой CA, то можно сформировать отдельню запись. К примеру, для www она может выглядеть так.

www.kostikov.co    IN CAA  0 issue "comodo.com"

Или, по аналогии c приведённым выше примером для issuewild, можно запретить выдачу.

www.kostikov.co    IN CAA  0 issue ";"

Использование значения 0 в CAA записи означает, что если центр сертификации не распознал содержание указанное в подтипе, то он волен выдать сертификат для такого домена. В этой связи, более безопасным представляется выставление так называемого "критического бита" путём указания значения 128 вместо нулевого. В этом случае любые ошибки в DNS-записи CAA будут трактоваться в качестве политики отказа выдачи сертификата.

2. Внедрение

Переходя от теории к практике внедрения Certification Authority Authorization, следует обратить внимание на два важных фактора.

Во-первых, поддерживает ли на сегодня ваш DNS-сервер записи типа CAA. На момент написания данной статьи они поддерживались:

  • BIND (до версии 9.9.6 следует использовать синтаксис согласно RFC3597);
  • NSD (до версии 4.0.1 также см. RFC3597);
  • PowerDNS ≥4.0.0;
  • Knot DNS ≥2.2.0;
  • Google Cloud DNS;
  • DNSimple;
  • UltraDNS.

В противоположность этому, Akamai DNS, Amazon AWS Route 53, Cloudflare, DynDNS, GoDaddy DNS, Network Solutions DNS такой поддержки сейчас не имеют.

Во-вторых, следует учесть поддерживает ли сам центр сертификации данных механизм и в какой мере. К чести Let's Encrypt на сей момент только он полностью обеспечивает выполнение данного стандарта. Однако, к осени 2017 следует ожидать аналогичной поддержки и ото всех прочих крупных игроков на рынке SSL-сертификатов.

В качестве удобного способа для того, чтобы сформировать корректные DNS-записи типа CAA можно порекомендовать онлайн мастер от SSLmate.

SSLmate CAA DNS record wizard

В качестве практических мер по повышению уровня защиты при использовании CAA можно назвать:

  1. Использование установки уже упоминавшегося выше "критического бита".
  2. Использование более одного довернного центра сертификации для вашего домена. Ситуации бывают разные. Вспомним, к примеру, отзыв корневых сертификатов WoSign и StartSSL из списка доверенных всеми популярными браузерами.
  3. Использование большего числа поддерживающих зону DNS-серверов и размещение их у различных провайдеров. Это позволит подстраховаться как от магистральных сбоев, так и от возможного взятия под контроль управления самим DNS-сервером злоумышленниками.
  4. Установление более длительного, нежели стандартный, времени TTL для CAA записей. Соображения тут примерно те же, что и в п.2. К примеру, срок в неделю или TTL 604800 выглядит разумным.
  5. Ну и, конечно же, ещё раз хотелось бы подчеркнуть чрезвычайную важность и полезность использования для вашей зоны DNSSEC, с помощью которого вы также можете и подписывать CAA записи вашего домена, защищая их от подделки (см. статью "Внедрение DNSSEC для вашего домена" в качестве практического старта).

И резюмируя вышесказанное. Безусловно, использование механизма Certification Authority Authorization нельзя считать панацеей, но, очевидно, что это ещё один шаг в сторону повышения уровня безопасности работы в сети. Также обратите внимание, что CAA предназначен исключительно для управления процессом выдачи сертификатов, но никак не для удостоверения использующего их программного обеспечения в том, что это именно тот сертификат, который данный узел должен предоставить в качестве подтверждения своих, так сказать, полномочий. Для нужд последнего применяются иные способы, в частности DNS-based Authentication of Named Entities или DANE, которому автор планирует посветить отдельную статью.

3. PROFIT!

Статья была полезной? Тогда прошу не стесняться и поддерживать деньгами через PayPal или Яндекс.Деньги.

DNS  letsencrypt  security  SSL  

Теги