Dns caa что это
CAA is a type of DNS record that allows site owners to specify which Certificate Authorities (CAs) are allowed to issue certificates containing their domain names. It was standardized in 2013 by RFC 6844 to allow a CA “reduce the risk of unintended certificate mis-issue.” By default, every public CA is allowed to issue certificates for any domain name in the public DNS, provided they validate control of that domain name. That means that if there’s a bug in any one of the many public CAs' validation processes, every domain name is potentially affected. CAA provides a way for domain holders to reduce that risk.
If you don’t care about CAA, you generally don’t have to do anything (but see CAA errors below). If you would like to use CAA to restrict which Certificate Authorities are allowed to issue certificates for your domain, you will need to use a DNS provider that supports setting CAA records. Check SSLMate’s CAA page for a list of such providers. If your provider is listed, you can use SSLMate’s CAA Record Generator to generate a set of CAA records listing the CAs that you would like to allow.
Закрытый ключ и сертификат
В TLS вся безопасность начинается с криптографической идентификации сервера; надежный закрытый ключ необходим, чтобы злоумышленники не могли выполнять атаки подмены автора (impersonation attacks). Не менее важно иметь действующий и надежный сертификат, который удостоверяет подлинность закрытого ключа и/или принадлежность закрытого ключа конкретному имени хоста. Без этих двух фундаментальных строительных блоков ничто другое не может быть безопасным.
2. Защита закрытых ключей
Относитесь к своим закрытым ключам как к важному активу, ограничивая доступ для минимально возможной группы сотрудников. Рекомендуемые политики включают следующее:
Сгенерируйте закрытые ключи на доверенном компьютере с достаточной энтропией. Некоторые центры сертификации предлагают сгенерировать для вас закрытые ключи — не используйте такую функциональность.
Защищайте ключи паролем с самого момента генерации, чтобы предотвратить компрометацию ключей при их хранении в системах резервного копирования. Пароль на закрытый ключ слабо защищает в работающих информационных системах, потому что знающий злоумышленник всегда может получить ключи из памяти процесса. Существуют аппаратные устройства (называемые аппаратными модулями безопасности или HSM), которые могут защитить закрытые ключи даже в случае компрометации сервера, но они дороги и поэтому оправданы только для организаций со строгими требованиями безопасности.
После взлома отзовите старые сертификаты и сгенерируйте новые ключи.
Обновляйте сертификаты ежегодно или чаще, если вы можете автоматизировать этот процесс. Большинство сайтов должны исходить из того, что скомпрометированный сертификат невозможно надежно отозвать; поэтому сертификаты с более коротким сроком действия на практике более безопасны.
Если сохранение одних и тех же ключей не важно для закрепления открытого ключа, вам также следует генерировать новые закрытые ключи всякий раз, когда вы получаете новый сертификат.
3. Обеспечьте в сертификате достаточное покрытие имен хостов
Убедитесь, что ваши сертификаты охватывают все имена, которые вы хотите использовать на сайте. Ваша цель — избежать предупреждений о недействительном сертификате, которые сбивают с толку пользователей и подрывают их доверие.
Подстановочные сертификаты имеют свое применение, но избегайте их использования, если это означает раскрытие базовых ключей гораздо большей группе людей, особенно если это выходит за рамки команды или отдела. Другими словами, чем меньше людей имеют доступ к закрытым ключам, тем лучше. Также имейте в виду, что совместное использование сертификатов создает связь, которой можно злоупотреблять для передачи уязвимостей с одного веб-сайта или сервера на все другие сайты и серверы, использующие один и тот же сертификат (даже если лежащие в основе закрытые ключи отличаются).
Убедитесь, что вы добавили все необходимые доменные имена в альтернативное имя субъекта (SAN), так как все последние версии браузеров не проверяют общее имя для проверки.
4. Получение сертификатов от надежного ЦС
Выберите центр сертификации (ЦС), который является надежным и серьезно относится к своему бизнесу сертификатов и безопасности. При выборе центра сертификации учитывайте следующие критерии:
Уровень безопасности. Все центры сертификации проходят регулярные проверки, но некоторые из них более серьезно относятся к безопасности, чем другие. Выяснить, какие из них лучше в этом отношении, непросто, но один из вариантов — изучить их историю безопасности и, что более важно, как они реагировали на компрометацию и извлекли ли они уроки из своих ошибок.
Фокус на бизнес. Центры сертификации, ориентированные на бизнес, чья деятельность составляет значительную часть их бизнеса, могут потерять все, если что-то пойдет не так, и они, вероятно, не будут пренебрегать своим разделением сертификатов, преследуя потенциально более прибыльные возможности в другом месте.
Предлагаемые услуги. Как минимум, выбранный вами ЦС должен обеспечивать поддержку как работу как со списком отзыва сертификатов (CRL), так и протокол состояния сетевого сертификата (OCSP) с надежной сетевой доступностью и производительностью. Многие сайты довольны сертификатами с проверкой домена, но вам также следует подумать, потребуются ли вам когда-либо сертификаты с расширенной проверкой (EV). В любом случае у вас должен быть выбор алгоритма открытого ключа. Сегодня большинство веб-сайтов используют RSA, но ECDSA может стать важным в будущем из-за его преимуществ в производительности.
Варианты управления сертификатами. Если вам нужно большое количество сертификатов, и вы работаете в сложной среде, выберите ЦС, который предоставит вам хорошие инструменты для управления ими.
Поддержка. Выберите ЦС, который предоставит вам хорошую поддержку, когда она вам понадобится.
Для наилучших результатов приобретайте сертификаты заблаговременно и как минимум за неделю до их развертывания в рабочей среде. Эта практика помогает избежать предупреждений о сертификатах для некоторых пользователей, имеющих неверное время на своих компьютерах, и помогает избежать неудачных проверок отзыва с центрами сертификации, которым требуется дополнительное время чтобы распространить новые сертификаты как действительные для своих ответчиков OCSP.
Со временем постарайтесь продлить этот период «разогрева» до 1-3 месяцев. Точно так же не ждите, пока истечет срок действия ваших сертификатов, чтобы заменить их. Оставление дополнительных нескольких месяцев таким же образом помогло бы людям, чьи часы неверны в другом направлении.
5. Используйте надежные алгоритмы подписи сертификата
Безопасность сертификата зависит от надежности закрытого ключа, который использовался для подписи сертификата, и от надежности хэш-функции, используемой в подписи. До недавнего времени большинство сертификатов основывались на хеш-функции SHA1, которая сейчас считается небезопасной. В результате мы в настоящее время переходим на SHA256. С 2016 года вы не сможете получить сертификат SHA1 от общедоступного центра сертификации. Конечные и промежуточные сертификаты, имеющие хэш-подпись SHA1, теперь считаются небезопасными для браузера.
6. Используйте DNS-запись CAA
DNS CAA — это стандарт, который позволяет владельцам доменных имен ограничивать, какие ЦС могут выдавать сертификаты для своих доменов. В сентябре 2017 года CA/Browser Forum обязал центры сертификации поддерживать его в рамках своих стандартных базовых требований к выдаче сертификатов. Благодаря внедрению CAA снижается поверхность атаки для мошеннических сертификатов, что делает сайты более безопасными. Если центры сертификации имеют автоматизированный процесс выдачи сертификатов, то он должен проверять запись DNS CAA, поскольку это уменьшит неправомерную выдачу сертификатов. Рекомендуется внести центр сертификации в белый список, добавив запись CAA для вашего сертификата. Добавьте ЦС, которым вы доверяете для выдачи вам сертификата.
Где разместить запись
CAA RFC определяет дополнительное поведение, называемое “tree-climbing”, которое требует, чтобы Центры сертификации также проверяли родительские домены для результата разрешения CNAME. Это дополнительное поведение было позже удалено в исправлении, поэтому Let’s Encrypt и другие Центры сертификации не реализовали его.
С тех пор как Let’s Encrypt стал проверять записи CAA, прежде чем выпустить любой сертификат, иногда появляются ошибки даже для доменов, не имеющих никаких записей CAA. При появлении ошибки невозможно определить, разрешен ли выпуск для затронутого домена, поскольку могут существовать записи CAA, запрещающие выпуск, которые не видны из-за ошибки.
Если вы получаете ошибки, связанные с CAA, сделайте еще несколько попыток, используя наше тестовое окружение, чтобы определить, является ли ошибка временной или постоянной. Если она постоянна, вам нужно обратиться с запросом в службу поддержки вашего DNS-провайдера или сменить провайдера. Если вы не знаете, кто ваш DNS-провайдер, выясните это у провайдера вашего хостинга.
Наконец, ошибки SERVFAIL могут быть вызваны перебоями в работе ваших полномочных серверов имен. Проверьте записи NS для ваших серверов имен и убедитесь, что каждый сервер доступен.
Иногда запросы CAA заканчиваются таймаутом. То есть полномочный сервер имен не отвечает даже после множества попыток. Чаще всего это происходит, если перед вашим сервером имен неправильно настроен файервол, который отвергает запросы DNS с неизвестным типом. Подайте заявку в службу поддержки вашего DNS-провайдера и спросите об их настройках файервола.
Let's Encrypt - это бесплатный, автоматизированный и открытый Центр Сертификации, созданный для вас некоммерческой организацией Internet Security Research Group (ISRG).
548 Market St, PMB 77519 , San Francisco , CA 94104-5401 , USA
Все письма и запросы направляйте по адресу:
Конфигурация
При правильной настройке сервера TLS вы гарантируете, что ваши учетные данные должным образом представлены посетителям сайта, что используются только безопасные криптографические примитивы и что все известные уязвимости устранены.
1. Используйте полные цепочки сертификатов
В большинстве развертываний одного сертификата сервера недостаточно; два или более сертификата необходимы для построения полной цепочки доверия. Распространенная проблема с конфигурацией возникает при развертывании сервера с действующим сертификатом, но без всех необходимых промежуточных сертификатов. Чтобы избежать этой ситуации, просто используйте все сертификаты, предоставленные вам вашим центром сертификации, в той же последовательности.
Недопустимая цепочка сертификатов делает сертификат сервера недействительным и приводит к появлению предупреждений браузера. На практике эту проблему иногда трудно диагностировать, потому что некоторые браузеры могут реконструировать неполные цепочки, а некоторые нет. Все браузеры склонны кэшировать и повторно использовать промежуточные сертификаты.
2. Используйте безопасные протоколы
В семействе SSL/TLS шесть протоколов: SSL v2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2 и TLS v1.3:
SSL v2 небезопасен и не должен использоваться. Эта версия протокола настолько плоха, что ее можно использовать для атаки на ключи RSA и сайты с одинаковым именем, даже если они находятся на совершенно разных серверах (атака DROWN).
TLS v1.0 и TLS v1.1 — это устаревшие протоколы, которые не следует использовать, но на практике они обычно необходимы. Его основная слабость (BEAST) устранена в современных браузерах, но другие проблемы остались. TLS v1.0 объявлен устаревшим в соответствии с PCI DSS. Точно так же TLS v1.0 и TLS v1.1 устарели в январе 2020 года в современных браузерах.
TLS v1.2 и v1.3 не имеют известных проблем с безопасностью.
TLS v1.2 или TLS v1.3 должен быть вашим основным протоколом, потому что эта версия предлагает современное аутентифицированное шифрование (также известное как AEAD). Если вы не поддерживаете TLS v1.2 или TLS v1.3 сегодня, ваша безопасность недостаточна.
Для поддержки старых клиентов вам может потребоваться пока продолжать поддерживать TLS v1.0 и TLS v1.1. Однако вы должны запланировать отказ от TLS v1.0 и TLS v1.1 в ближайшем будущем. Например, стандарт PCI DSS требует, чтобы все сайты, принимающие платежи по кредитным картам, прекратили поддержку TLS v1.0 к июню 2018 года. Точно так же современные браузеры прекратят поддержку TLS v1.0 и TLS v1.1 к январю 2020 года.
Преимущества использования TLS v1.3:
Улучшенная производительность (уменьшены задержки)
Удалены устаревшие / небезопасные функции, такие как наборы шифров, сжатие и т. Д.
3. Используйте наборы безопасных шифров
Чтобы безопасно общаться, вы должны сначала убедиться, что вы общаетесь напрямую с желаемой стороной (а не через кого-то еще, кто подслушивает) и безопасно обмениваетесь данными. В SSL и TLS наборы шифров определяют, как происходит безопасная связь. Они состоят из различных строительных блоков с идеей достижения безопасности за счет разнообразия. Если один из строительных блоков окажется слабым или ненадежным, вы сможете переключиться на другой.
Вы должны полагаться главным образом на наборы AEAD, которые обеспечивают строгую аутентификацию и обмен ключами, прямую секретность и шифрование не менее 128 бит. Некоторые другие, более слабые наборы могут по-прежнему поддерживаться при условии, что они согласованы только со старыми клиентами, которые не поддерживают ничего лучшего.
Есть несколько устаревших криптографических примитивов, которых следует избегать:
Анонимные наборы Диффи-Хеллмана (Anonymous Diffie-Hellman, ADH) не обеспечивают аутентификацию.
Наборы шифров NULL (NULL cipher) не обеспечивают шифрования.
Наборы экспортированных шифров небезопасны при согласовании в соединении
Пакеты со слабыми шифрами (112 бит или меньше) используют шифрование, которое легко взломать, небезопасны.
64-битный блочный шифр (3DES/DES/RC2/IDEA) слаб.
Наборы шифров с обменом ключами RSA (TLS_RSA) являются слабыми
Есть несколько наборов шифров, которым следует отдать предпочтение:
Наборы шифров AEAD (Authenticated Encryption with Associated Data) — CHACHA20_POLY1305, GCM и CCM
Шифры PFS (Perfect Forward Secrecy) — ECDHE_RSA, ECDHE_ECDSA, DHE_RSA, DHE_DSS, CECPQ1 и все шифры TLS 1.3
В качестве отправной точки используйте следующую конфигурацию набора, предназначенную для ключей RSA и ECDSA:
Рекомендуется всегда сначала тестировать конфигурацию TLS в тестовой среде, перенося изменения в производственную среду только тогда, когда вы уверены, что все работает должным образом. Обратите внимание, что приведенный выше список является общим и что не все системы (особенно старые) поддерживают все наборы. Вот почему важно сначала протестировать настройку.
В приведенном выше примере конфигурации используются стандартные имена наборов TLS. Некоторые платформы используют нестандартные имена; пожалуйста, обратитесь к документации для вашей платформы для получения более подробной информации. Например, с OpenSSL будут использоваться следующие имена наборов:
4. Выберите лучшие наборы шифров
В версиях протокола SSL v3 и более поздних версиях клиенты представляют список наборов шифров, которые они поддерживают, а серверы выбирают один набор из списка для использования в соединении. Однако не все серверы справляются с этим хорошо; некоторые выберут первый поддерживаемый набор из списка клиента. Наличие серверов, активно выбирающих наилучший доступный набор шифров, имеет решающее значение для достижения наилучшей безопасности.
5. Используйте прямую секретность
Секретность пересылки (иногда также называемая идеальной секретностью пересылки) — это функция протокола, которая обеспечивает безопасные сеансы связи, не зависящие от закрытого ключа сервера. С наборами шифров, которые не обеспечивают прямой секретности, кто-то, кто может восстановить закрытый ключ сервера, может расшифровать все ранее записанные зашифрованные разговоры. Вам необходимо поддерживать и предпочитать наборы ECDHE, чтобы обеспечить прямую секретность в современных веб-браузерах.
Для поддержки более широкого круга клиентов вам также следует использовать наборы DHE в качестве запасного варианта после ECDHE. Избегайте обмена ключами RSA без крайней необходимости. Предложенная конфигурация по умолчанию в Разделе 2.3 содержит комплекты, которые обеспечивают только прямую секретность.
6. Используйте надежный обмен ключами
Для обмена ключами общедоступные сайты обычно могут выбирать между классическим методом обмена ключами Диффи-Хеллмана (DHE) и его вариантом эллиптической кривой ECDHE. Существуют и другие алгоритмы обмена ключами, но они, как правило, так или иначе небезопасны. Обмен ключами RSA по-прежнему очень популярен, но он не обеспечивает прямой секретности.
В 2015 году группа исследователей опубликовала новые атаки на DHE - их работа известна как атака Logjam. Исследователи обнаружили, что обмен ключами DH с меньшей надежностью (например, 768 бит) может быть легко взломан и что некоторые известные 1024-битные группы DH могут быть взломаны государственными органами. Чтобы быть в безопасности, при развертывании DHE настройте его как минимум на 2048 битов безопасности.
Некоторые старые клиенты (например, Java 6) могут не поддерживать этот уровень надежности. Из соображений производительности большинству серверов следует предпочесть ECDHE, который и сильнее, и быстрее. В этом случае хорошим выбором будет именованная кривая secp256r1 (также известная как P-256).
7. Устранение известных проблем
В последние годы было совершено несколько серьезных атак на SSL и TLS, но, как правило, они не должны вас беспокоить, если вы используете новейшее программное обеспечение и следуете советам, приведенным в этом руководстве. Однако ничто не является абсолютно безопасным, поэтому рекомендуется следить за тем, что происходит в области безопасности. Оперативно применяйте исправления поставщиков, если и когда они становятся доступными; в противном случае полагайтесь на обходные пути для смягчения последствий.
CAA – тип записи DNS, с помощью которого владелец сайта может определить Центры сертификации (CAs) для выпуска сертификатов, содержащих конкретные доменные имена. Она была стандартизирована в 2013 году в RFC 6844, чтобы позволить Центру сертификации “уменьшить риск непреднамеренного ошибочного выпуска сертификата”. По умолчанию каждый публичный Центр сертификации имеет право выпускать сертификаты для любого доменного имени в общедоступном DNS при условии, что контроль над этим доменным именем подтвержден. Это означает, что возможный баг в одном из множества проверочных процессов Центров сертификации потенциально может затронуть каждое доменное имя. CAA позволяет владельцам доменов уменьшить этот риск.
Если вам не нужна CAA, можно ничего не делать (но см. ошибки CAA ниже). Если же вы хотели бы использовать CAA, чтобы ограничить число Центров сертификации, имеющих право выпуска сертификатов для вашего домена, нужно использовать провайдера DNS, который поддерживает настройку записей CAA. Список таких провайдеров можно найти на странице SSLMate’s CAA. Если ваш провайдер нашелся в списке, можно использовать генератор записей SSLMate’s CAA для создания набора записей CAA, перечисляющих центры сертификации, которые вы хотели бы разрешить.
Where to put the record
The CAA RFC specifies an additional behavior called “tree-climbing” that requires CAs to also check the parent domains of the result of CNAME resolution. This additional behavior was later removed by an erratum, so Let’s Encrypt and other CAs do not implement it.
Since Let’s Encrypt checks CAA records before every certificate we issue, sometimes we get errors even for domains that haven’t set any CAA records. When we get an error, there’s no way to tell whether we are allowed to issue for the affected domain, since there could be CAA records present that forbid issuance, but are not visible because of the error.
If you receive CAA-related errors, try a few more times against our staging environment to see if they are temporary or permanent. If they are permanent, you will need to file a support issue with your DNS provider, or switch providers. If you’re not sure who your DNS provider is, ask your hosting provider.
Some DNS providers that are unfamiliar with CAA initially reply to problem reports with “We do not support CAA records.” Your DNS provider does not need to specifically support CAA records; it only needs to reply with a NOERROR response for unknown query types (including CAA). Returning other opcodes, including NOTIMP, for unrecognized qtypes is a violation of RFC 1035, and needs to be fixed.
If you don’t have DNSSEC enabled and get a SERVFAIL, the second most likely reason is that your authoritative nameserver returned NOTIMP, which as described above is an RFC 1035 violation; it should instead return NOERROR with an empty response. If this is the case, file a bug or a support ticket with your DNS provider.
Lastly, SERVFAILs may be caused by outages at your authoritative nameservers. Check the NS records for your nameservers and ensure that each server is available.
Sometimes CAA queries time out. That is, the authoritative name server never replies with an answer at all, even after multiple retries. Most commonly this happens when your nameserver has a misconfigured firewall in front of it that drops DNS queries with unknown qtypes. File a support ticket with your DNS provider and ask them if they have such a firewall configured.
Let's Encrypt is a free, automated, and open certificate authority brought to you by the nonprofit Internet Security Research Group (ISRG).
548 Market St, PMB 77519 , San Francisco , CA 94104-5401 , USA
Send all mail or inquiries to:
Linux Foundation is a registered trademark of The Linux Foundation. Linux is a registered trademark of Linus Torvalds.
CAA (Certification Authority Authorization) — это новый тип DNS-записи, предназначенный для определения центров сертификации, которым разрешен выпуск SSL/TLS-сертификатов для определенного доменного имени или субдомена.
Крупнейшие и наиболее популярные центры сертификации договорились, что начиная с 8 сентября 2017 года в обязательном порядке строго следовать инструкциям, указанным в CAA-записях доменного имени или субдомена для которого запрашивается выпуск сертификата.
Использование CAA-записи позволит повысить уровень безопасности в сети Интернет и сократить случаи неавторизованного получения сертификатов для сторонних доменных имен.
Я подготовил подробную инструкцию, которая разъясняет возможности CAA-записи и формат ее использования.
Значение CAA-записи состоит из трех частей, разделенных пробелом:
- 0 — Если значение tag не поддерживается или не распознается центром сертификации, то центру сертификации разрешено по своему усмотрению выпустить сертификат для доменного имени или субдомена.
- 128 — Если значение tag не поддерживается или не распознается центром сертификации, то центр сертификации не должен выпускать сертификат для доменного имени или субдомена.
Значение tag может принимать одно из следующих значений:
- issue — Определяет центр сертификации, которому разрешена выдача сертификата, для используемого в названии записи доменного имени или субдомена.
- issuewild — Определяет центр сертификации, которому разрешена выдача wildcard-сертификата, для используемого в названии записи доменного имени или субдомена. Сертификат распространяется на доменное имя или субдомен непосредственно и на все его субдомены.
- iodef — Определяет адрес электронной почты или URL (соответствующий стандарту RFC 5070), который центр сертификации должен использовать для уведомлений, в случае получения запроса на выпуск сертификата в нарушении определенных CAA-записью правил для доменного имени.
Значение value зависит от значения tag и должно быть заключено в двойные кавычки ("").
Некоторые центры сертификации позволяют использовать дополнительные параметры для значения value. В этом случае, параметры должны быть разделены точкой с запятой (;).
-
В случае, если tag = issue — Доменное имя центра сертификации, которому разрешен выпуск сертификата для указанного в названии записи доменного имени или субдомена. Для запрета выпуска сертификата для всех центров сертификации для указанного в названии записи доменного имени или субдомена необходимо использовать точку с запятой (;) вместо доменного имени центра сертификации.
- Значение записи для доменного имени или субдомена наследуется на все его субдомены, если явно не задано другое.
- Для определения двух и более центров сертификации для одного доменного имени или субдомена нужно использовать несколько CAA-записей.
- Отсутствие CAA-записи будет интерпретироваться любым центром сертификации как разрешение на выпуск сертификата.
- Полная спецификация CAA-записи доступна в документе RFC 6844.
Кто поддерживает?
CAA-запись поддерживают не все DNS-провайдеры. Актуальный список по состоянию на 30 августа 2017 года в алфавитном порядке:
Онлайн генераторы?
Вы можете воспользоваться этим или этим онлайн-генератором для правильного и быстрого создания необходимых CAA-записей.
Об актуальной теме утвержденных недавно как обязательные дополнительных средств усиления валидности сертификатов безопасности (SSL/TSL) рассказывают специалисты Qualis, облачного провайдера, оказывающего широкий спектр услуг в области интернет-безопасности.
CAA (Certification Authority Authorization – авторизация центров сертификации), определенная в RFC 6844 в 2013 г., была предложена, чтобы усилить экосистему PKI (Public Key Infrastructure) при помощи нового средства контроля за тем, какой именно центр сертификации может выдавать сертификат данному конкретному домену.
Несмотря на то, что САА введена уже более 4 лет назад, она все еще мало известна сегодня, и на данный момент только 100 или, может быть, около 200 сайтов ее используют. Однако предстоят значительные перемены, потому что форум центров сертификации и разработчиков браузеров (форум CA/Browser) утвердил CAA в качестве обязательной – в рамках стандартного набора базовых условий для выпуска сертификата безопасности. Новая норма начнет действовать с сентября 2017 года.
Возможность выпуска сертификата безопасности любым сертификационным центром (СА) для любого домена неоднократно указывалась как наиболее слабое место экосистемы PKI. Несмотря на то, что центры сертификации должны действовать не нарушая неких общих правил, до сих пор нет средств технического контроля за тем, что они делают. Отсюда возникает некое слабое звено в системе, а при наличии сотен CA – таких звеньев, соответственно, сотни.
САА создает механизм, позволяющий владельцам доменов создавать на уровне DNS-записей белые списки центров, которым они разрешают выдавать сертификаты для своего домена. Для этого вводится новая ресурсная DNS-запись, САА (тип 257). Владелец домена ограничивает выдачу сертификатов, указывая явно адрес центра сертификации в этой записи.
Например, вот таким образом:
И это всё. Перед тем как выпустить сертификат для какого-нибудь домена, СА проверяет его ресурсную DNS-запись CAA, и выпускает сертификат только в том случае, если находит там свой адрес. В дополнение к директиве «issue» из вышеприведенного примера, есть еще директива «issuewild», ограничивающая выпуск расширенных wildcard-сертификатов, и директива «iodef», которая содержит URL, по которому СА может обратиться, если что-то происходит неправильно – в смысле политики сертификации или технических проблем. (128 – это контрольный байт с установленным старшим битом, указывающий на то, что данная директива критически важна и должна исполняться безусловно).
Во-вторых, HPKP – для браузеров, а CAA – для центров сертификации. HPKP, дающая список ключей, средство технического контроля, в то время как САА осуществляет, скорее, административный контроль. Да, ожидается, что при несоответствии САА-записи центр сертификации прекращает выдачу сертификата, но ведь центр сертификации может переключиться в ручной режим и принять решение о выпуске, если запрос будет признан все-таки подлинным. И да, это опять сложность – центров сертификации много, и самая главная проблема для них – противостоять неким «социальным» факторам давления и все же выполнять некие формальные правила в случае несоответствия САА-записей.
Но говорить, что САА бесполезна или пересекается с HPKP – не стоит. Тут есть определенные преимущества, в частности, по сравнению с HPKP у САА меньше возможностей для злоупотребления и нарушения прав собственности в онлайн-пространстве.
HPKP при неверном функционировании может полностью разрушить ваш веб-бизнес, а САА будет только слегка раздражать, если что-то пойдет не так.
И кроме того, «прикрепление публичных ключей для подтверждения владения веб-ресурсом» пугает потенциальных пользователей HPKP своей сложностью и громоздкостью, по сравнению с простотой DNS-записи CAA.
Проверить наличие САА-записи можно при помощи любого онлайн-сервиса, анализирующего состав записей DNS для публичных доменов.
SSL/TLS — обманчиво простая технология. Его легко развернуть и он просто работает, за исключением случаев, когда это не так. Основная проблема заключается в том, что правильно развернуть шифрование непросто. Чтобы гарантировать работоспособность TLS и обеспечение необходимой безопасности, системным администраторам и разработчикам необходимо прикладывать дополнительные усилия для правильной настройки серверов и разработки приложений.
Этот документ является шагом к решению проблемы нехватки документации в области использования SSL/TLS. Основная задача — предоставить четкие и краткие инструкции, которые помогут администраторам и программистам сэкономить время на развертывание защищенного сайта или веб-приложения. Для сохранения ясности в стороне останутся некоторые сложные схемы и излишние реализации. Основное внимание уделяется практическим советам, которым легко следовать.
Читайте также: