The OpenNET Project / Index page

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

Вступили в силу требования к удостоверяющим центрам по проверке CAA-записей в DNS

10.09.2017 10:02

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

Пример настройки CAA можно посмотреть в данной заметке. Автоматически сформировать DNS-записи с CAA можно через специально подготовленный web-интерфейс.

  1. Главная ссылка к новости (https://letsencrypt.org/docs/c...)
  2. OpenNews: Поставлена под сомнение валидность 30 тысяч HTTPS-сертификатов удостоверяющего центра Symantec
  3. OpenNews: Уязвимость в удостоверяющем центре Comodo позволила получить сертификат для чужого домена
  4. OpenNews: Mozilla обсуждает прекращение доверия к удостоверяющему центру WoSign
  5. OpenNews: Уязвимость удостоверяющего центра StartSSL позволяла получить сертификат для чужого домена
  6. OpenNews: Сертификат удостоверяющего центра был использован для перехвата трафика произвольных доменов
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/47168-cert
Ключевые слова: cert, ca, ssl, https
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:22, 10/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Усложнились условия торговли воздухом.
     
     
  • 2.4, пох (?), 11:29, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    приятно отметить, что ни одной существующей проблемы это усложнение не затрагивает - сертификат к внезапно-субдомену (на чем были основаны все истерики с баном startssl, да и letsencrypt разок чуть не спалились) выпустить можно, не смотря на эту дурь.
     
     
  • 3.18, Аноним (-), 09:50, 11/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    *.example.com. IN CAA 0 issue "letsencrypt.org"
    а так?
     
  • 3.19, Аноним (-), 10:18, 11/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    CAA and Sub-domains

    The CAA record set for a domain also applies to all sub-domains. If a sub-domain has its own CAA record set, it takes precedence.

     
  • 2.10, EHLO (?), 16:52, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Усложнились условия торговли воздухом.

    Любое бесполезное усложнение может быть выгодно только торговцам воздухом. К сожалению.

     

  • 1.2, YetAnotherOnanym (ok), 10:43, 10/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Это что же получается, чтобы корпоративному админу бампнуть https-соединение придётся ещё и в DNS подменять эту CCA на ответ со своим УЦ?
     
     
  • 2.5, KonstantinB (ok), 11:30, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. CCA-запись проверяется только при _генерации_ сертификата на стороне CA.

    Например, если атакующий имеет возможность провести активную MITM-атаку на HTTP-сервер, он может выпустить "левый" letsencrypt-сертификат. Или получил доступ к e-mail и может подтвердить выпуск AlphaSSL/Comodo. DNS-запись добавляет еще один уровень защиты.

    Но, конечно, толк от этого будет, только если _все_ CA начнут поддерживать эту запись.

     

  • 1.3, Аноним (-), 11:11, 10/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    зачем нужен централизоанный ICANN-ом DNS когда есть децентрализованный Namecoin-ом?
     
     
  • 2.6, KonstantinB (ok), 11:40, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Децентрализованный DNS, для использования которого надо выкачивать весь блокчейн, не взлетит. Блокчейн Namecoin-а уже больше 5 гигов, и это притом, что им очень мало кто пользуется.

    Если когда-то и появится жизнеспособная в масштабах всего интернета реализация децентрализованных DNS, она точно не будет основана на блокчейне.

     

  • 1.7, Sw00p aka Jerom (?), 14:25, 10/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    аццтой полный, давно уже пора в днс записях хранить самоподписный, и проверять по нему - выкинув всякие удостоверяющие центры которые с каждым годом всё больше теряют доверие. А сам днс пустить форсированно через днссек или днскрипт как он там.
     
     
  • 2.8, KonstantinB (ok), 15:35, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Для начала бы dnssec внедрить нормально. С ним как-то примерно как с ipv6...
     
     
  • 3.11, Аноним (-), 17:31, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Для начала бы в dnssec добавить поддержку стойких алгоритмов.
     
     
  • 4.12, KonstantinB (ok), 19:41, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    С алгоритмами нормально вполне, гибко (rfc6944, rfc6605). Required SHA1 за день не поменяешь, должна же быть совместимость. А рекомендуемые ECDSAP384/SHA384 - вполне себе.
     
  • 2.9, KonstantinB (ok), 15:41, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну и опять же остается вопрос, кто будет подписывать зону :-)
     
     
  • 3.13, Sw00p aka Jerom (?), 21:16, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    от корня и по дереву вниз. а кто там отвечает за корневые днс - iana.org ? прикол в том, что митм тут может сделать сама иана. То есть за любое чп в ответе она. И я думаю она более серьёзная организация чем все эти CA вместе взятые.
     
     
  • 4.14, Crazy Alex (ok), 21:26, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Корневые - да, а второй уровень? Причём,  в отличие от CA, выбора нет.
     
     
  • 5.16, Sw00p aka Jerom (?), 01:18, 11/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    так нужно убрать цепочку - корень подписывает второй а второй третий, второй спокойно без корня может подписать третий фейковый, суть в том что нуно чтобы тока корень всех подписывал - сужаем ответственность до одного и будем завтра спрашивать с него. Убираем нафиг делегейшен сайнинг.
     
     
  • 6.17, Elhana (ok), 03:01, 11/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Другими словами вы предлагаете, чтобы dnssec-подпись для любого по сути домена в мире проходила через iana, а не через регистратора - думаете iana заняться больше нечем?
     
     
  • 7.20, Sw00p aka Jerom (?), 23:31, 11/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я даже за запрет делегирования зон, да пусть будет одна организация и пусть хостит всё у себя, я готов платить им за это, скока мы там платим за ев сертификаты в год ? или там днс хостинг ? зато буду знать с кого спрашивать при инцидентах. посредничество - зло, никакого доверия третьей стороне.
     
     
  • 8.21, ACCA (ok), 17:19, 12/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ты забываешь о фундаментальных свойствах бюрократии Через 3 года в IANA будет р... текст свёрнут, показать
     
     
  • 9.22, Sw00p aka Jerom (?), 19:31, 12/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вот тогда и будет чистота и порядок Ынтернета bnuki ru bokil ru bolaw ru bolyt r... текст свёрнут, показать
     
     
  • 10.23, ACCA (ok), 08:56, 13/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Те, кто готовы пожертвовать насущной свободой ради малой толики временной безоп... текст свёрнут, показать
     
     
  • 11.24, Sw00p aka Jerom (?), 16:31, 13/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дайте сначало определение свободы, а то ваще точнее не ваше утверждение звучит... текст свёрнут, показать
     
  • 4.15, KonstantinB (ok), 00:51, 11/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Если есть 200 килобаксов на свой gTLD, то да, вариант :-)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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