The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

Использование CAA записей в DNS для защиты от генерации фиктивных HTTPS-сертификатов
Начиная с сентября 2017 года удостоверяющим центрам предписано обязательно
проверять CAA-записи в DNS перед генерацией сертификата. CAA (RFC-6844,
Certificate Authority Authorization) позволяет владельцу домена явно определить
удостоверяющий центр, который имеет полномочия для генерации сертификатов для
указанного домена. При наличии CAA-записи все остальные удостоверяющие центры
обязаны блокировать выдачу сертификатов от своего имени для данного домена и
информировать его владельца о попытках компрометации.

Например, добавление в зону домена example.com записей (для BIND 9.9.6 и более новых выпусков):

   $ORIGIN example.com
   .       CAA 0 issue "letsencrypt.org"
   .       CAA 0 iodef "mailto:security@example.com"
или
   .       CAA 0 iodef "http://iodef.example.com/"


указывает на то, что сертификаты для example.com  генерируются только
удостоверяющим центром  Let's Encrypt (осуществляется проверка владельца
домена "letsencrypt.org"). В поле iodef задаётся метод оповещения о попытке
генерации сертификата. Поддерживается отправка уведомления на email или
информирование через запрос к web-сервису (RFC-6546).

При желании можно уточнить учётную запись под которой разрешено генерировать сертификаты:

   .       CAA 0 issue "letsencrypt.org; account=12345"

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

Допустимо указание нескольких записей issue, при использовании сертификатов от
нескольких удостоверяющих центров:

  example.com.       CAA 0 issue "symantec.com"
  example.com.       CAA 0 issue "pki.goog"
  example.com.       CAA 0 issue "digicert.com"

Проверить корректность создания записей CAA можно командой:

   dig +short +noshort example.com CAA

Также доступен web-интерфейс для автоматической генерации конфигураций.
 
10.09.2017
Ключи: ssl, https, caa, cert, dns / Лицензия: CC-BY
Раздел:    Корень / Безопасность / Шифрование, PGP

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, Ilya Indigo (ok), 17:18, 10/09/2017 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    0 после CAA означает 0-вой TTL?
    Если да, то зачем и чем грозит использование TTL 86400?
     
     
  • 2.2, Elhana (ok), 20:56, 10/09/2017 [^] [ответить]    [к модератору]
  • +1 +/
    в RFC же все написано... это не TTL, это critical flag, точнее flags, который пока всего один.
    "0" - если CA не смогло понять вашу запись, они могут выдать сертификат.
    "128" (не 1!) - если CA не смогло понять вашу запись, они не могут выдавать сертификат.

    В принципе для того, что в rfc уже описано, не важно как вы его выставите.
    Если CA не поддерживает CAA-запись в принципе, то им в любом случае насpать, а если поддерживают, то будет иметь смысл только для каких-то будущих дополнительных фишек записи.

     
     
  • 3.5, Ilya Indigo (ok), 02:21, 11/09/2017 [^] [ответить]    [к модератору]
  • +/
    > в RFC же все написано... это не TTL, это critical flag, точнее
    > flags, который пока всего один.

    Благодарю.
    > "0" - если CA не смогло понять вашу запись, они могут выдать
    > сертификат.
    > "128" (не 1!) - если CA не смогло понять вашу запись, они
    > не могут выдавать сертификат.
    > В принципе для того, что в rfc уже описано, не важно как
    > вы его выставите.

    Но что-то я не понял. Конечно, при условии что CA его поддерживают, логичней выставить 128, чтобы при некорректной записи выдача сертификата не осуществлялась, если я правильно понял.

     
     
  • 4.6, Elhana (ok), 02:35, 11/09/2017 [^] [ответить]    [к модератору]
  • +1 +/
    Опять же, все в rfc. Логика следующая: Если в будущем добавится какой-то тип записи, которого нет в данном rfc, как пример приводится новое поле tbs, которого нет в этом rfc. У CA которое знает только о существовании rfc6844 и не знает что делать с tbs есть два варианта - если critical flag у данного поля выставлен в 0, оно может его проигнорировать и все равно выдать сертификат, если остальные условия соблюдены (issue "ca.example.net; policy=ev") или если critical flag выставлен 128, то не выдавать сертификат.

    $ORIGIN example.com
    .       CAA 0 issue "ca.example.net; policy=ev"
    .       CAA 128 tbs "Unknown"

    Так как issue/issuewild/iodef определены в этом rfc, то особого смысла ставить 128 нет.
    Либо CA должны поддерживать эти записи и соблюдать их, либо они вообще пока на CAA запись не смотрят.

    При некорректной записи, например CAA 0 issue "incorrect record" CA поддерживающий этот rfc не должен выдать сертификат в любом случае.
    Я не уверен как оно должно реагировать на CAA 0 или 128 issue "ca.example.net; unknown=blabla", если не понимает что делать с unknown=blabla, в rfc написано, что все дополнительные параметры могут быть site-specific, т.е. определяться CA и поэтому не оговариваются в данном rfc. Можно предположить, что оно должно тоже отказывать в выдаче и наверно опять же независимо от значения critical flag.

     
     
  • 5.7, Elhana (ok), 02:49, 11/09/2017 [^] [ответить]    [к модератору]
  • +2 +/
    Ну и если под некорректной записью понимается какая-то опечатка вроде CAA 128 iisue "ca.example.net; policy=ev", тогда да, CA должен отказать, а при 0 выдать, не найдя ограничений.
     
     
  • 6.8, Ilya Indigo (ok), 03:34, 11/09/2017 [^] [ответить]    [к модератору]  
  • +1 +/
    > Ну и если под некорректной записью понимается какая-то опечатка вроде CAA 128
    > iisue "ca.example.net; policy=ev", тогда да, CA должен отказать, а при 0
    > выдать, не найдя ограничений.

    Благодарю, именно это меня больше всего и интересовало.
    Вот по этому я вижу смысл везде ставить только 128.

     
  • 1.3, fi (ok), 22:53, 10/09/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    первый же вопрос -  а если выписан самим себе? как выглядит запись?
     
     
  • 2.4, Elhana (ok), 00:15, 11/09/2017 [^] [ответить]    [к модератору]  
  • +/
    Точно так же - указываете свой CA, который может выпускать сертификат. Правда не очень понятно зачем, но можно.. Можно указать пустой список CAA 0 issue ";", что значить что ни один CA, который соблюдает это rfc, не должен выпускать сертификат.
    Эта запись в любом случае не для клиентов, а для CA - браузеры не должны ее проверять.
     
     
  • 3.9, VoDA (ok), 18:06, 11/09/2017 [^] [ответить]    [к модератору]  
  • +1 +/
    > Точно так же - указываете свой CA, который может выпускать сертификат. Правда
    > не очень понятно зачем, но можно.. Можно указать пустой список CAA
    > 0 issue ";", что значить что ни один CA, который соблюдает
    > это rfc, не должен выпускать сертификат.
    > Эта запись в любом случае не для клиентов, а для CA -
    > браузеры не должны ее проверять.

    Браузеры как раз и должны проверять, что полученный сертификат выдан кем то из списка CAA. Если не из списка CAA, то это явное указание на подделку сертификата. К примеру через прокси или MITM.

     
     
  • 4.10, _ (??), 23:23, 11/09/2017 [^] [ответить]    [к модератору]  
  • +/
    > Браузеры как раз и должны проверять,

    В RFC-6844 такого не нашёл. Можно линк на пруф, тебе же не трудно?

     
     
  • 5.11, alex (??), 11:07, 13/09/2017 [^] [ответить]    [к модератору]  
  • +/
    в стандарте конечно только про СА написано
    но выглядит это как ключ к замку, висящий рядом с дверью, и запиской "входить только хозяевам", то есть защита только от честных людей
     
     
  • 6.16, al42and (?), 16:19, 23/09/2017 [^] [ответить]    [к модератору]  
  • +/
    RFC ставит целью не защиты от злых CA, а защиту от злых людей, которые могут обманом получить сертификат на чужой домен от честного CA.


    А если злой человек MITM'ит трафик между клиентом и сервером, то он и из DNS может CAA-запись убрать, так что браузеры особо не защитятся. М.б. DNSSEC спас бы, да кто ж его пользует...

     
     
  • 7.18, Xasd (ok), 10:12, 01/10/2017 [^] [ответить]    [к модератору]  
  • +/
    > А если злой человек MITM'ит трафик между клиентом и сервером, то он и из DNS может CAA-запись убрать, так что браузеры особо не защитятся. М.б. DNSSEC спас бы, да кто ж его пользует...

    а может ли этот злой MITM-человек -- не взирая на DNSSEC просто выполнить повторное процедуру автоматической выдачи сертификата? делая это для того CA который в прописан в CAA? (с 99.9% ожидаем что это letsencrypt)

     
     
  • 8.19, Xasd (ok), 10:13, 01/10/2017 [^] [ответить]    [к модератору]  
  • +/
    >> А если злой человек MITM'ит трафик между клиентом и сервером, то он и из DNS может CAA-запись убрать, так что браузеры особо не защитятся. М.б. DNSSEC спас бы, да кто ж его пользует...
    > а может ли этот злой MITM-человек -- не взирая на DNSSEC просто
    > выполнить повторное процедуру автоматической выдачи сертификата? делая это для того CA
    > который в прописан в CAA? (с 99.9% ожидаем что это letsencrypt)

    сам спросил -- сам отвечаю (цитатой):

    > При желании можно уточнить учётную запись под которой разрешено генерировать сертификаты:
    >
    >   .       CAA 0 issue "letsencrypt.org; account=12345"

     
  • 4.21, Аноним (-), 22:20, 05/10/2017 [^] [ответить]    [к модератору]  
  • +/
    > Браузеры как раз и должны проверять, что полученный сертификат выдан кем то
    > из списка CAA.

    Браузеры — не должны. Должен проверять CA при получении запроса на выдачу сертификата.

     
  • 1.12, Аноним (-), 10:01, 14/09/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Очевидный вопрос: Что будет если я не добавил запись CAA, а мой CA проверяет эту запись?
     
     
  • 2.13, Аноним (-), 17:34, 14/09/2017 [^] [ответить]    [к модератору]  
  • +/
    очевидно ошибку должен выдать - как не прошедший DNS проверку.
     
     
  • 3.14, Elhana (ok), 02:12, 17/09/2017 [^] [ответить]    [к модератору]  
  • +/
    Не очевидно и даже почти наверняка не должен - если нет CAA записи, то нет и запрета. Вот если запись пустая, то да.
     
  • 1.15, Аноним (-), 10:31, 22/09/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Какой рфц описывает тоже самое для браузеров?
     
     
  • 2.20, Аноним (-), 22:19, 05/10/2017 [^] [ответить]    [к модератору]  
  • +/
    Нет такого для браузеров.
     
  • 1.17, Адекват (ok), 07:01, 27/09/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    прост:

    host -t CAA comodo.com
    comodo.com has CAA record 0 iodef "mailto:sslabuse@comodoca.com"
    comodo.com has CAA record 0 issue "comodoca.com"

    host -t CAA sberbank.ru
    sberbank.ru has no CAA record

     
  • 1.22, ACCA (ok), 23:18, 10/10/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Что-то я не пойму - а как это поможет-то?

    Сценарий - у меня сайт cutekitties.org, SSL от ведущих производителей, CAA в DNS, все дела.

    Клиент заходит из сети Ростелеком. Который тупо перехватывает все запросы на 53 порт и отвечает со своего DNS сервера, на лету подгибая адрес отвечателя через SNAT. Ну, и по мелочи шаманя в ответах, типа CAA для cutekitties.org может быть только РУСОНИКС.РФ.

    Вопрос - и как это поможет клиенту?

     
     
  • 2.23, h31 (ok), 11:30, 13/10/2017 [^] [ответить]    [к модератору]  
  • +/
    Это не для браузеров. Читай ветку http://www.opennet.ru/tips/3028_ssl_https_caa_cert_dns.shtml#10
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:



      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor