forum.opennet.ru - "Раздел полезных советов: Использование CAA записей в DNS для..." (23)

форумы

правила/FAQ

поиск

регистрация

вход/выход

слежка

"Раздел полезных советов: Использование CAA записей в DNS для..."

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Использование CAA записей в DNS для..."	+/–
Сообщение от auto_tips (ok) on 10-Сен-17, 17:18
Начиная с сентября 2017 года удостоверяющим центрам предписано обязательно проверять CAA-записи в DNS перед генерацией сертификата. CAA ([[https://tools.ietf.org/html/rfc6844 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 ([[https://letsencrypt.org/docs/caa/ осуществляется]] проверка владельца домена "letsencrypt.org"). В поле iodef задаётся метод оповещения о попытке генерации сертификата. Поддерживается отправка уведомления на email или информирование через запрос к web-сервису ([[https://tools.ietf.org/html/rfc6546 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 Также доступен [[https://sslmate.com/caa/ web-интерфейс]] для автоматической генерации конфигураций. URL: Обсуждается: http://www.opennet.me/tips/info/3028.shtml
Ответить \| Правка \| Cообщить модератору

Оглавление

Использование CAA записей в DNS для защиты от генерации фикт..., Ilya Indigo, 17:18 , 10-Сен-17, (1)

Использование CAA записей в DNS для защиты от генерации фикт..., Elhana, 20:56 , 10-Сен-17, (2) +1

Использование CAA записей в DNS для защиты от генерации фикт..., Ilya Indigo, 02:21 , 11-Сен-17, (5)

Использование CAA записей в DNS для защиты от генерации фикт..., Elhana, 02:35 , 11-Сен-17, (6) +1

Использование CAA записей в DNS для защиты от генерации фикт..., Elhana, 02:49 , 11-Сен-17, (7) +2

Использование CAA записей в DNS для защиты от генерации фикт..., Ilya Indigo, 03:34 , 11-Сен-17, (8) +1

Использование CAA записей в DNS для защиты от генерации фикт..., fi, 22:53 , 10-Сен-17, (3)

Использование CAA записей в DNS для защиты от генерации фикт..., Elhana, 00:15 , 11-Сен-17, (4)

Использование CAA записей в DNS для защиты от генерации фикт..., VoDA, 18:06 , 11-Сен-17, (9) +1

Использование CAA записей в DNS для защиты от генерации фикт..., _, 23:23 , 11-Сен-17, (10)

Использование CAA записей в DNS для защиты от генерации фикт..., alex, 11:07 , 13-Сен-17, (11)

Использование CAA записей в DNS для защиты от генерации фикт..., al42and, 16:19 , 23-Сен-17, (16)

Использование CAA записей в DNS для защиты от генерации фикт..., Xasd, 10:12 , 01-Окт-17, (18)

Использование CAA записей в DNS для защиты от генерации фикт..., Xasd, 10:13 , 01-Окт-17, (19)

Использование CAA записей в DNS для защиты от генерации фикт..., Аноним, 22:20 , 05-Окт-17, (21)

Использование CAA записей в DNS для защиты от генерации фикт..., Аноним, 10:01 , 14-Сен-17, (12)

Использование CAA записей в DNS для защиты от генерации фикт..., Аноним, 17:34 , 14-Сен-17, (13)

Использование CAA записей в DNS для защиты от генерации фикт..., Elhana, 02:12 , 17-Сен-17, (14)

Использование CAA записей в DNS для защиты от генерации фикт..., Аноним, 10:31 , 22-Сен-17, (15)

Использование CAA записей в DNS для защиты от генерации фикт..., Аноним, 22:19 , 05-Окт-17, (20)

Раздел полезных советов: Использование CAA записей в DNS для..., Адекват, 07:01 , 27-Сен-17, (17)
Использование CAA записей в DNS для защиты от генерации фикт..., ACCA, 23:18 , 10-Окт-17, (22)

Использование CAA записей в DNS для защиты от генерации фикт..., h31, 11:30 , 13-Окт-17, (23)

Сообщения по теме [Сортировка по ответам | RSS]

1. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Ilya Indigo (ok) on 10-Сен-17, 17:18

0 после CAA означает 0-вой TTL?
Если да, то зачем и чем грозит использование TTL 86400?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Использование CAA записей в DNS для защиты от генерации фикт..." +1 +/–

Сообщение от Elhana (ok) on 10-Сен-17, 20:56

в RFC же все написано... это не TTL, это critical flag, точнее flags, который пока всего один.
"0" - если CA не смогло понять вашу запись, они могут выдать сертификат.
"128" (не 1!) - если CA не смогло понять вашу запись, они не могут выдавать сертификат.
В принципе для того, что в rfc уже описано, не важно как вы его выставите.
Если CA не поддерживает CAA-запись в принципе, то им в любом случае насpать, а если поддерживают, то будет иметь смысл только для каких-то будущих дополнительных фишек записи.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от fi (ok) on 10-Сен-17, 22:53

первый же вопрос -  а если выписан самим себе? как выглядит запись?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Elhana (ok) on 11-Сен-17, 00:15

Точно так же - указываете свой CA, который может выпускать сертификат. Правда не очень понятно зачем, но можно.. Можно указать пустой список CAA 0 issue ";", что значить что ни один CA, который соблюдает это rfc, не должен выпускать сертификат.
Эта запись в любом случае не для клиентов, а для CA - браузеры не должны ее проверять.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Ilya Indigo (ok) on 11-Сен-17, 02:21

> в RFC же все написано... это не TTL, это critical flag, точнее
> flags, который пока всего один.
Благодарю.
> "0" - если CA не смогло понять вашу запись, они могут выдать
> сертификат.
> "128" (не 1!) - если CA не смогло понять вашу запись, они
> не могут выдавать сертификат.
> В принципе для того, что в rfc уже описано, не важно как
> вы его выставите.
Но что-то я не понял. Конечно, при условии что CA его поддерживают, логичней выставить 128, чтобы при некорректной записи выдача сертификата не осуществлялась, если я правильно понял.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Использование CAA записей в DNS для защиты от генерации фикт..." +1 +/–

Сообщение от Elhana (ok) on 11-Сен-17, 02:35

Опять же, все в 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 | Наверх | Cообщить модератору

7. "Использование CAA записей в DNS для защиты от генерации фикт..." +2 +/–

Сообщение от Elhana (ok) on 11-Сен-17, 02:49

Ну и если под некорректной записью понимается какая-то опечатка вроде CAA 128 iisue "ca.example.net; policy=ev", тогда да, CA должен отказать, а при 0 выдать, не найдя ограничений.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Использование CAA записей в DNS для защиты от генерации фикт..." +1 +/–

Сообщение от Ilya Indigo (ok) on 11-Сен-17, 03:34

> Ну и если под некорректной записью понимается какая-то опечатка вроде CAA 128
> iisue "ca.example.net; policy=ev", тогда да, CA должен отказать, а при 0
> выдать, не найдя ограничений.
Благодарю, именно это меня больше всего и интересовало.
Вот по этому я вижу смысл везде ставить только 128.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Использование CAA записей в DNS для защиты от генерации фикт..." +1 +/–

Сообщение от VoDA (ok) on 11-Сен-17, 18:06

> Точно так же - указываете свой CA, который может выпускать сертификат. Правда
> не очень понятно зачем, но можно.. Можно указать пустой список CAA
> 0 issue ";", что значить что ни один CA, который соблюдает
> это rfc, не должен выпускать сертификат.
> Эта запись в любом случае не для клиентов, а для CA -
> браузеры не должны ее проверять.
Браузеры как раз и должны проверять, что полученный сертификат выдан кем то из списка CAA. Если не из списка CAA, то это явное указание на подделку сертификата. К примеру через прокси или MITM.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

10. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от _ (??) on 11-Сен-17, 23:23

> Браузеры как раз и должны проверять,
В RFC-6844 такого не нашёл. Можно линк на пруф, тебе же не трудно?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от alex (??) on 13-Сен-17, 11:07

в стандарте конечно только про СА написано
но выглядит это как ключ к замку, висящий рядом с дверью, и запиской "входить только хозяевам", то есть защита только от честных людей

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Аноним (??) on 14-Сен-17, 10:01

Очевидный вопрос: Что будет если я не добавил запись CAA, а мой CA проверяет эту запись?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Аноним (??) on 14-Сен-17, 17:34

очевидно ошибку должен выдать - как не прошедший DNS проверку.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Elhana (ok) on 17-Сен-17, 02:12

Не очевидно и даже почти наверняка не должен - если нет CAA записи, то нет и запрета. Вот если запись пустая, то да.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Аноним (??) on 22-Сен-17, 10:31

Какой рфц описывает тоже самое для браузеров?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от al42and on 23-Сен-17, 16:19

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

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

17. "Раздел полезных советов: Использование CAA записей в DNS для..." +/–

Сообщение от Адекват (ok) on 27-Сен-17, 07:01

прост:
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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Xasd (ok) on 01-Окт-17, 10:12

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

19. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Xasd (ok) on 01-Окт-17, 10:13

>> А если злой человек MITM'ит трафик между клиентом и сервером, то он и из DNS может CAA-запись убрать, так что браузеры особо не защитятся. М.б. DNSSEC спас бы, да кто ж его пользует...
> а может ли этот злой MITM-человек -- не взирая на DNSSEC просто
> выполнить повторное процедуру автоматической выдачи сертификата? делая это для того CA
> который в прописан в CAA? (с 99.9% ожидаем что это letsencrypt)
сам спросил -- сам отвечаю (цитатой):
> При желании можно уточнить учётную запись под которой разрешено генерировать сертификаты:
>
>   .       CAA 0 issue "letsencrypt.org; account=12345"

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Аноним (??) on 05-Окт-17, 22:19

Нет такого для браузеров.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

21. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от Аноним (??) on 05-Окт-17, 22:20

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

22. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от ACCA (ok) on 10-Окт-17, 23:18

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Использование CAA записей в DNS для защиты от генерации фикт..." +/–

Сообщение от h31 (ok) on 13-Окт-17, 11:30

Это не для браузеров. Читай ветку http://www.opennet.me/tips/3028_ssl_https_caa_cert_dns.shtml#10

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	1. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Ilya Indigo (ok) on 10-Сен-17, 17:18
	0 после CAA означает 0-вой TTL? Если да, то зачем и чем грозит использование TTL 86400?
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Использование CAA записей в DNS для защиты от генерации фикт..."	+1 +/–
	Сообщение от Elhana (ok) on 10-Сен-17, 20:56
	в RFC же все написано... это не TTL, это critical flag, точнее flags, который пока всего один. "0" - если CA не смогло понять вашу запись, они могут выдать сертификат. "128" (не 1!) - если CA не смогло понять вашу запись, они не могут выдавать сертификат. В принципе для того, что в rfc уже описано, не важно как вы его выставите. Если CA не поддерживает CAA-запись в принципе, то им в любом случае насpать, а если поддерживают, то будет иметь смысл только для каких-то будущих дополнительных фишек записи.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от fi (ok) on 10-Сен-17, 22:53
	первый же вопрос - а если выписан самим себе? как выглядит запись?
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	4. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Elhana (ok) on 11-Сен-17, 00:15
	Точно так же - указываете свой CA, который может выпускать сертификат. Правда не очень понятно зачем, но можно.. Можно указать пустой список CAA 0 issue ";", что значить что ни один CA, который соблюдает это rfc, не должен выпускать сертификат. Эта запись в любом случае не для клиентов, а для CA - браузеры не должны ее проверять.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Ilya Indigo (ok) on 11-Сен-17, 02:21
	> в RFC же все написано... это не TTL, это critical flag, точнее > flags, который пока всего один. Благодарю. > "0" - если CA не смогло понять вашу запись, они могут выдать > сертификат. > "128" (не 1!) - если CA не смогло понять вашу запись, они > не могут выдавать сертификат. > В принципе для того, что в rfc уже описано, не важно как > вы его выставите. Но что-то я не понял. Конечно, при условии что CA его поддерживают, логичней выставить 128, чтобы при некорректной записи выдача сертификата не осуществлялась, если я правильно понял.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	6. "Использование CAA записей в DNS для защиты от генерации фикт..."	+1 +/–
	Сообщение от Elhana (ok) on 11-Сен-17, 02:35
	Опять же, все в 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 \| Наверх \| Cообщить модератору


	7. "Использование CAA записей в DNS для защиты от генерации фикт..."	+2 +/–
	Сообщение от Elhana (ok) on 11-Сен-17, 02:49
	Ну и если под некорректной записью понимается какая-то опечатка вроде CAA 128 iisue "ca.example.net; policy=ev", тогда да, CA должен отказать, а при 0 выдать, не найдя ограничений.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "Использование CAA записей в DNS для защиты от генерации фикт..."	+1 +/–
	Сообщение от Ilya Indigo (ok) on 11-Сен-17, 03:34
	> Ну и если под некорректной записью понимается какая-то опечатка вроде CAA 128 > iisue "ca.example.net; policy=ev", тогда да, CA должен отказать, а при 0 > выдать, не найдя ограничений. Благодарю, именно это меня больше всего и интересовало. Вот по этому я вижу смысл везде ставить только 128.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "Использование CAA записей в DNS для защиты от генерации фикт..."	+1 +/–
	Сообщение от VoDA (ok) on 11-Сен-17, 18:06
	> Точно так же - указываете свой CA, который может выпускать сертификат. Правда > не очень понятно зачем, но можно.. Можно указать пустой список CAA > 0 issue ";", что значить что ни один CA, который соблюдает > это rfc, не должен выпускать сертификат. > Эта запись в любом случае не для клиентов, а для CA - > браузеры не должны ее проверять. Браузеры как раз и должны проверять, что полученный сертификат выдан кем то из списка CAA. Если не из списка CAA, то это явное указание на подделку сертификата. К примеру через прокси или MITM.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	10. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от _ (??) on 11-Сен-17, 23:23
	> Браузеры как раз и должны проверять, В RFC-6844 такого не нашёл. Можно линк на пруф, тебе же не трудно?
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от alex (??) on 13-Сен-17, 11:07
	в стандарте конечно только про СА написано но выглядит это как ключ к замку, висящий рядом с дверью, и запиской "входить только хозяевам", то есть защита только от честных людей
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	12. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Аноним (??) on 14-Сен-17, 10:01
	Очевидный вопрос: Что будет если я не добавил запись CAA, а мой CA проверяет эту запись?
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	13. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Аноним (??) on 14-Сен-17, 17:34
	очевидно ошибку должен выдать - как не прошедший DNS проверку.
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	14. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Elhana (ok) on 17-Сен-17, 02:12
	Не очевидно и даже почти наверняка не должен - если нет CAA записи, то нет и запрета. Вот если запись пустая, то да.
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	15. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Аноним (??) on 22-Сен-17, 10:31
	Какой рфц описывает тоже самое для браузеров?
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	16. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от al42and on 23-Сен-17, 16:19
	RFC ставит целью не защиты от злых CA, а защиту от злых людей, которые могут обманом получить сертификат на чужой домен от честного CA. А если злой человек MITM'ит трафик между клиентом и сервером, то он и из DNS может CAA-запись убрать, так что браузеры особо не защитятся. М.б. DNSSEC спас бы, да кто ж его пользует...
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	17. "Раздел полезных советов: Использование CAA записей в DNS для..."	+/–
	Сообщение от Адекват (ok) on 27-Сен-17, 07:01
	прост: 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
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	18. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Xasd (ok) on 01-Окт-17, 10:12
	> А если злой человек MITM'ит трафик между клиентом и сервером, то он и из DNS может CAA-запись убрать, так что браузеры особо не защитятся. М.б. DNSSEC спас бы, да кто ж его пользует... а может ли этот злой MITM-человек -- не взирая на DNSSEC просто выполнить повторное процедуру автоматической выдачи сертификата? делая это для того CA который в прописан в CAA? (с 99.9% ожидаем что это letsencrypt)
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	19. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Xasd (ok) on 01-Окт-17, 10:13
	>> А если злой человек MITM'ит трафик между клиентом и сервером, то он и из DNS может CAA-запись убрать, так что браузеры особо не защитятся. М.б. DNSSEC спас бы, да кто ж его пользует... > а может ли этот злой MITM-человек -- не взирая на DNSSEC просто > выполнить повторное процедуру автоматической выдачи сертификата? делая это для того CA > который в прописан в CAA? (с 99.9% ожидаем что это letsencrypt) сам спросил -- сам отвечаю (цитатой): > При желании можно уточнить учётную запись под которой разрешено генерировать сертификаты: > > . CAA 0 issue "letsencrypt.org; account=12345"
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	20. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Аноним (??) on 05-Окт-17, 22:19
	Нет такого для браузеров.
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	21. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от Аноним (??) on 05-Окт-17, 22:20
	> Браузеры как раз и должны проверять, что полученный сертификат выдан кем то > из списка CAA. Браузеры — не должны. Должен проверять CA при получении запроса на выдачу сертификата.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	22. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от ACCA (ok) on 10-Окт-17, 23:18
	Что-то я не пойму - а как это поможет-то? Сценарий - у меня сайт cutekitties.org, SSL от ведущих производителей, CAA в DNS, все дела. Клиент заходит из сети Ростелеком. Который тупо перехватывает все запросы на 53 порт и отвечает со своего DNS сервера, на лету подгибая адрес отвечателя через SNAT. Ну, и по мелочи шаманя в ответах, типа CAA для cutekitties.org может быть только РУСОНИКС.РФ. Вопрос - и как это поможет клиенту?
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	23. "Использование CAA записей в DNS для защиты от генерации фикт..."	+/–
	Сообщение от h31 (ok) on 13-Окт-17, 11:30
	Это не для браузеров. Читай ветку http://www.opennet.me/tips/3028_ssl_https_caa_cert_dns.shtml#10
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору