8 сентября вступило (https://mailarchive.ietf.org/arch/msg/spasm/vHL260X6Zb2C0VSw...) в силу предписание, в соответствии с которым удостоверяющие центры должны обязательно проверять CAA-записи в DNS перед генерацией сертификата. CAA (RFC-6844 (https://tools.ietf.org/html/rfc6844), Certificate Authority Authorization) позволяет владельцу домена явно определить удостоверяющий центр, через который можно генерировать сертификаты для указанного домена. Если удостоверяющий центр не перечислен в записях CAA, то он обязан блокировать выдачу сертификатов для данного домена и информировать владельца домена о попытках компрометации.
Пример настройки CAA можно посмотреть в данной заметке (https://www.opennet.ru/tips/3028_ssl_https_caa_cert_dns.shtml). Автоматически сформировать DNS-записи с CAA можно через специально подготовленный web-интерфейс (https://sslmate.com/caa/).URL: https://letsencrypt.org/docs/caa/
Новость: https://www.opennet.ru/opennews/art.shtml?num=47168
Усложнились условия торговли воздухом.
приятно отметить, что ни одной существующей проблемы это усложнение не затрагивает - сертификат к внезапно-субдомену (на чем были основаны все истерики с баном startssl, да и letsencrypt разок чуть не спалились) выпустить можно, не смотря на эту дурь.
*.example.com. IN CAA 0 issue "letsencrypt.org"
а так?
CAA and Sub-domainsThe 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.
>Усложнились условия торговли воздухом.Любое бесполезное усложнение может быть выгодно только торговцам воздухом. К сожалению.
Это что же получается, чтобы корпоративному админу бампнуть https-соединение придётся ещё и в DNS подменять эту CCA на ответ со своим УЦ?
Нет. CCA-запись проверяется только при _генерации_ сертификата на стороне CA.Например, если атакующий имеет возможность провести активную MITM-атаку на HTTP-сервер, он может выпустить "левый" letsencrypt-сертификат. Или получил доступ к e-mail и может подтвердить выпуск AlphaSSL/Comodo. DNS-запись добавляет еще один уровень защиты.
Но, конечно, толк от этого будет, только если _все_ CA начнут поддерживать эту запись.
зачем нужен централизоанный ICANN-ом DNS когда есть децентрализованный Namecoin-ом?
Децентрализованный DNS, для использования которого надо выкачивать весь блокчейн, не взлетит. Блокчейн Namecoin-а уже больше 5 гигов, и это притом, что им очень мало кто пользуется.Если когда-то и появится жизнеспособная в масштабах всего интернета реализация децентрализованных DNS, она точно не будет основана на блокчейне.
аццтой полный, давно уже пора в днс записях хранить самоподписный, и проверять по нему - выкинув всякие удостоверяющие центры которые с каждым годом всё больше теряют доверие. А сам днс пустить форсированно через днссек или днскрипт как он там.
Для начала бы dnssec внедрить нормально. С ним как-то примерно как с ipv6...
Для начала бы в dnssec добавить поддержку стойких алгоритмов.
С алгоритмами нормально вполне, гибко (rfc6944, rfc6605). Required SHA1 за день не поменяешь, должна же быть совместимость. А рекомендуемые ECDSAP384/SHA384 - вполне себе.
Ну и опять же остается вопрос, кто будет подписывать зону :-)
от корня и по дереву вниз. а кто там отвечает за корневые днс - iana.org ? прикол в том, что митм тут может сделать сама иана. То есть за любое чп в ответе она. И я думаю она более серьёзная организация чем все эти CA вместе взятые.
Корневые - да, а второй уровень? Причём, в отличие от CA, выбора нет.
так нужно убрать цепочку - корень подписывает второй а второй третий, второй спокойно без корня может подписать третий фейковый, суть в том что нуно чтобы тока корень всех подписывал - сужаем ответственность до одного и будем завтра спрашивать с него. Убираем нафиг делегейшен сайнинг.
Другими словами вы предлагаете, чтобы dnssec-подпись для любого по сути домена в мире проходила через iana, а не через регистратора - думаете iana заняться больше нечем?
я даже за запрет делегирования зон, да пусть будет одна организация и пусть хостит всё у себя, я готов платить им за это, скока мы там платим за ев сертификаты в год ? или там днс хостинг ? зато буду знать с кого спрашивать при инцидентах. посредничество - зло, никакого доверия третьей стороне.
Ты забываешь о фундаментальных свойствах бюрократии.Через 3 года в IANA будет работать 8 тыс. человек, A-запись будет стоить $300 в год, вносить её будут две недели. SOA запись будут создавать только по решению технического комитета, заседающего 2 раза в год.
Через 5 лет в IANA будет работать больше 10тыс. человек, внесение изменений в существующую зону будет только по предварительной записи в порядке живой очереди. На приём будут записывать с 9 до 16:00 с перерывом на обед с 12:00 до 14:00. Выходной день - вторник. В праздничные дни США, Индии, Малайзии, Китая, Франции и Израиля - закрыто. Решения технического комитета станут рекомендациями, которые раз в два года должны будут утверждаться на заседании президиума технического комитета.
>>Через 3 года в IANA будет работать 8 тыс. человек, A-запись будет стоить $300 в год, вносить её будут две недели. SOA запись будут создавать только по решению технического комитета, заседающего 2 раза в год.вот тогда и будет чистота и порядок Ынтернета
bnuki.ru
bokil.ru
bolaw.ru
bolyt.ru
bopyn.ru
boriw.ru
cotad.ru
dakil.ru
datom.ru
deril.ruвам говорят эти домены о чём то ? если нет - накупленые и качественно организованные под распространение спама, в частности направленного действия (APT). И как собственно это называть ? - беспредел Ынтернета.
>>утверждаться на заседании президиума технического комитета.
таки да. Лучше уж бюрократия чем беспредел
>>>утверждаться на заседании президиума технического комитета.
> таки да. Лучше уж бюрократия чем беспредел"Те, кто готовы пожертвовать насущной свободой ради малой толики временной безопасности, не достойны ни свободы, ни безопасности"
Дайте сначало определение свободы, а то ваще (точнее не ваше) утверждение звучит не обоснованно.
Если есть 200 килобаксов на свой gTLD, то да, вариант :-)