От переводчика: Это перевод статьи от EFF
A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation.
Автор оригинальной статьи: Joona Hoikkala.
Дата оригинальной публикации: 23 февраля 2018
Ранее в этом месяце, Let's Encrypt (бесплатный, автоматизированный, открытый центр сертификации, который EFF помог запустить два года назад) преодолел важный рубеж: выдачу более 50 миллионов активных сертификатов. И это число будет продолжать расти, потому что через несколько недель Let's Encrypt также начнет выдавать wildcard-сертификаты, о которых просили многие системные администраторы.
Чтобы проверить сертификат HTTPS, браузер пользователя проверяет, действительно ли доменное имя веб-сайта указано в сертификате. Например, сертификат от www.eff.org должен фактически включать в себя www.eff.org как действительный домен для этого сертификата. Сертификаты также могут содержать несколько доменов (например, www.eff.org, ssd.eff.org, sec.eff.org и т.д.), если владелец просто хочет использовать один сертификат для всех своих доменов.
Wildcard-сертификат — это сертификат, который гласит: «Я действителен для всех поддоменов в этом домене», а не явно перечисляя их все. (В сертификате это указывается с помощью символа подстановки, обозначенного звездочкой. Поэтому, если Вы сейчас проверите сертификат для eff.org, он скажет, что он действителен для *.eff.org.) Таким образом, системный администратор может получить сертификат для всего своего домена и использовать его в новых поддоменах, о которых он даже не думал, когда получал сертификат.
Для выдачи wildcard-сертификатов Let's Encrypt будет требовать от пользователей подтверждения своего контроля над доменом, используя проверку(challenge) на основе DNS, системы доменных имен, которая переводит доменные имена, такие как www.eff.org, в IP-адреса, такие как 69.50.232.54. С точки зрения центра сертификации, такого как Let's Encrypt, нет лучшего способа доказать, что Вы управляете доменом, чем путем изменения его записей DNS, поскольку управление доменом является одной из основ DNS.
Однако, одна из ключевых идей Let's Encrypt заключается в том, что получение сертификата должно быть автоматическим процессом. Но, чтобы автоматизировать его, программное обеспечение, запрашивающее сертификат, также должно будет иметь возможность изменять записи DNS для этого домена. В целях реализации этой возможности программное обеспечение также должно иметь доступ к учетным данным для службы DNS (например, логин и пароль или криптографический токен), а эти учетные данные должны храниться там, где происходит автоматизированное получение сертификата.
Во многих случаях это означает, что если машина обрабатывающая процесс получения компрометируется, то же происходит и с учетными данными DNS, в этом то и заключается реальная опасность. В оставшейся части этого поста мы совершим глубокое погружение в компоненты, участвующие в этом процессе, и в то какие варианты делают его более безопасным.
На высоком уровне проверка владения доменом работает, как и все остальные автоматические проверки, которые являются частью протокола ACME, — протокола, который может использовать центр сертификации (CA), например Let's Encrypt, и клиентское программное обеспечение, например Certbot, для обмена информацией о том, какой сертификат запрашивает сервер, и как сервер должен подтвердить право собственности на соответствующее доменное имя.
Во время проверки владения доменом пользователь запрашивает сертификат из CA с помощью клиентского программного обеспечения ACME, такого как Certbot, который поддерживает данный тип проверки. Когда клиент запрашивает сертификат, CA запрашивает у клиента подтверждение права собственности на домен, путем добавления конкретной TXT-записи в свою зону DNS. Более подробно: CA отправляет уникальный случайный токен ACME-клиенту, и тот, кто имеет контроль над доменом, должен поместить этот токен как TXT-запись в свою зону DNS, в предопределенный поддомен с именем "_acme-challenge" того домена, контроль над которым пытается доказать пользователь.
Например, если Вы пытаетесь проверить домен для *.eff.org, поддомен проверки будет "_acme-challenge.eff.org". Когда значение токена добавляется в зону DNS, клиент сообщает CA продолжить проверку владения, после чего CA будет выполнять DNS-запрос к авторитетным серверам для домена. Если авторитетные DNS-серверы ответят DNS-записью, содержащей правильный токен проверки владения, право собственности на домен будет доказано, и процесс выдачи сертификата может быть продолжен.
Угрозы, связанные с DNS-зоной делает столь опасными, то, что DNS — это то, на что полагаются браузеры пользователей, чтобы знать, с каким IP-адресом они должны связаться, пытаясь достичь вашего домена. Это относится ко всем службам, использующим разрешаемое имя под вашим доменом, от электронной почты до веб-служб.
Когда DNS скомпрометирован, злоумышленник может легко перехватить все подключения, направленные к вашей электронной почте или другой защищенной службе, прекратить шифрование TLS (поскольку теперь они могут подтвердить право собственности на домен и получить для них свои действительные сертификаты), дешифровать данные и прочесть их, а затем повторно зашифровать данные и передать их на ваш сервер. Для большинства людей это было бы очень трудно обнаружить.
Строго говоря, для того, чтобы ACME-клиент делал обновления в автоматическом режиме, этот клиент должен иметь доступ только к учетным данным, которые могут обновлять TXT-записи для поддоменов "_acme-challenge". К сожалению, большинство программных продуктов DNS и поставщиков услуг DNS не предлагают подробные средства контроля доступа, которые позволяют ограничить эти привилегии, или просто не предоставляют API для автоматизации этого за пределами основных обновлений или транзакций DNS-зоны. Это оставляет возможные методы автоматизации непригодными или небезопасными.
Есть простой способ, который может помочь маневрировать мимо таких ограничений: использовать CNAME-запись. CNAME-записи по существу действуют как ссылки на другую запись DNS. Let's Encrypt проследует по цепочке CNAME-записей и разрешит токен проверки владения для последней записи в цепочке.
Даже используя CNAME-записи, основная проблема заключается в том, что ACME-клиенту по-прежнему будет нужен доступ к учетным данным, которые позволят ему изменить некоторую DNS-запись. Существуют различные способы смягчения этой основной проблемы с различными уровнями сложности и последствиями для безопасности в случае компрометации.
В следующих разделах этот пост представляет некоторые из этих методов, пытаясь объяснить возможные последствия того, что учетные данные будут скомпрометированы. За одним исключением, все они используют CNAME-записи.
Первый способ — создать набор учетных данных с привилегиями, которые позволяют обновлять TXT-записи.
В случае компрометации этот метод ограничивает последствия для злоумышленника способностью выдавать сертификаты для всех доменов в зоне DNS (поскольку они могут использовать учетные данные DNS для получения собственных сертификатов), а также прерывание доставки почты. Воздействие на доставку почты происходит из TXT-записей, специфичных для почты, а именно SPF, DKIM и его расширения ADSP и DMARC. Их компрометация также облегчит доставку фишинговых писем, выдающих себя за отправителя из скомпрометированного домена.
Второй способ — вручную создать CNAME-записи для поддомена "_acme-challenge" и указать ими на домен проверки, который будет находиться в зоне, контролируемой другим набором учетных данных.
Например, если Вы хотите получить сертификат для покрытия «yourdomain.tld» и «www.yourdomain.tld», вам придется создать две CNAME-записи — "_ acme-challenge.yourdomain.tld" и "_acme-challenge.www.yourdomain.tld" — а также указать ими на внешний домен для проверки. Домен, используемый для проверки владения, должен быть во внешней зоне DNS или в поддиапазонной зоне DNS, которая имеет свой собственный набор учетных данных для управления. (DNS-зона субделегата определяется с помощью NS-записей и фактически делегирует полный контроль над частью зоны внешнему источнику.)
Эффект компрометации для этого метода довольно ограничен. Поскольку фактические сохраненные учетные данные предназначены для внешней зоны DNS, злоумышленник, получивший учетные данные, получит только возможность выдавать сертификаты для всех доменов, указывающих на записи в этой зоне. Однако, выяснение того, какие домены на самом деле указывают туда, тривиально: злоумышленнику просто нужно будет прочитать журналы прозрачности сертификатов и проверить, имеют ли домены в этих сертификатах магический поддомен, указывающий на уязвимую зону DNS.
Если ваше программное обеспечение или поставщик DNS позволяет создавать разрешения, привязанные к поддомену (гранулированные привилегии), это может помочь вам смягчить всю проблему.
К сожалению, на момент публикации был найден единственный поставщик, который дает данные привилегии — это Microsoft Azure DNS. У Dyn предположительно также есть гранулированные привилегии, но мы не смогли найти более низкий уровень привилегий в их сервисе помимо «Обновление записей», которые все еще оставляют зону полностью уязвимой.
Route53 и, возможно, другие позволяют своим пользователям создавать зону субделегата, новые учетные данные пользователя, указывать NS-записи в новую зону и указывать поддомены проверки _acme-challenge для них с использованием CNAME-записей. Нужно много работы для того, чтобы корректно сделать распределение привелегий, используя этот метод, так как нужно пройти все эти шаги для каждого домена, для которого необходимо использовать проверку владения.
Дисклеймер: программное обеспечение, описанное ниже, написано автором (оригинальной статьи — прим. переводчика), и оно используется в качестве примера функций, необходимых для эффективного управления учетными данными, нужными для автоматизации проверки владения доменом через DNS безопасным образом.
Последний метод — это часть программного обеспечения под названием ACME-DNS, написанная для борьбы именно с обсуждаемой проблемой, и она может полностью устранить её. Единственный недостаток заключается в том, что этот метод добавляет еще один компонент в вашу инфраструктуру, который надо поддерживать, а также требует открыть DNS-порт (53) для общего доступа в интернет.
ACME-DNS действует как простой DNS-сервер с ограниченным HTTP API. Сам API позволяет только обновлять TXT-записи автоматически генерируемых случайных поддоменов. В нём нет методов для запроса утерянных учетных данных, обновления или добавления других записей. Он предоставляет две конечные точки:
Чтобы использовать ACME-DNS, вам сначала нужно создать для него A/AAAA-записи, а затем указать к нему NS-записи для создания узла делегирования. После этого Вы просто создаете новый набор учетных данных через конечную точку /register и указываете CNAME-запись из поддомена подтверждения проверки "_acme-challenge" в исходной зоне к вновь созданному поддомену.
Единственные учетные данные, сохраненные локально, будут для ACME-DNS, и они хороши только для обновления точных TXT-записей для поддоменов проверки для доменов в поле. Это эффективно ограничивает влияние возможной компрометации для злоумышленника до способности выдавать сертификаты для этих доменов.
Дополнительные сведения об ACME-DNS см. на странице:
github.com/joohoi/acme-dns
Чтобы устранить проблемы с проверкой владения доменом через ACME DNS, обсуждались такие предложения, как assisted-DNS в рабочей группе ACME IETF, но в настоящее время эти проблемы все еще остаются без разрешения. Поскольку единственный способ ограничить воздействие компрометации — это ограничить права доступа учетных записей DNS-зоны до изменения определенных TXT-записей, текущие возможности для надежной реализации автоматизации проверки владения доменом незначетельны.
Единственным устойчивым вариантом было бы заставить программное обеспечение DNS и поставщиков услуг либо внедрять методы для создания более мелкомасштабных учетных данных зоны, либо предоставлять совершенно новый тип учетных данных для этого специфического варианта использования.
A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation.
Автор оригинальной статьи: Joona Hoikkala.
Дата оригинальной публикации: 23 февраля 2018
Ранее в этом месяце, Let's Encrypt (бесплатный, автоматизированный, открытый центр сертификации, который EFF помог запустить два года назад) преодолел важный рубеж: выдачу более 50 миллионов активных сертификатов. И это число будет продолжать расти, потому что через несколько недель Let's Encrypt также начнет выдавать wildcard-сертификаты, о которых просили многие системные администраторы.
Что такое wildcard-сертификат?
Чтобы проверить сертификат HTTPS, браузер пользователя проверяет, действительно ли доменное имя веб-сайта указано в сертификате. Например, сертификат от www.eff.org должен фактически включать в себя www.eff.org как действительный домен для этого сертификата. Сертификаты также могут содержать несколько доменов (например, www.eff.org, ssd.eff.org, sec.eff.org и т.д.), если владелец просто хочет использовать один сертификат для всех своих доменов.
Wildcard-сертификат — это сертификат, который гласит: «Я действителен для всех поддоменов в этом домене», а не явно перечисляя их все. (В сертификате это указывается с помощью символа подстановки, обозначенного звездочкой. Поэтому, если Вы сейчас проверите сертификат для eff.org, он скажет, что он действителен для *.eff.org.) Таким образом, системный администратор может получить сертификат для всего своего домена и использовать его в новых поддоменах, о которых он даже не думал, когда получал сертификат.
Для выдачи wildcard-сертификатов Let's Encrypt будет требовать от пользователей подтверждения своего контроля над доменом, используя проверку(challenge) на основе DNS, системы доменных имен, которая переводит доменные имена, такие как www.eff.org, в IP-адреса, такие как 69.50.232.54. С точки зрения центра сертификации, такого как Let's Encrypt, нет лучшего способа доказать, что Вы управляете доменом, чем путем изменения его записей DNS, поскольку управление доменом является одной из основ DNS.
Однако, одна из ключевых идей Let's Encrypt заключается в том, что получение сертификата должно быть автоматическим процессом. Но, чтобы автоматизировать его, программное обеспечение, запрашивающее сертификат, также должно будет иметь возможность изменять записи DNS для этого домена. В целях реализации этой возможности программное обеспечение также должно иметь доступ к учетным данным для службы DNS (например, логин и пароль или криптографический токен), а эти учетные данные должны храниться там, где происходит автоматизированное получение сертификата.
Во многих случаях это означает, что если машина обрабатывающая процесс получения компрометируется, то же происходит и с учетными данными DNS, в этом то и заключается реальная опасность. В оставшейся части этого поста мы совершим глубокое погружение в компоненты, участвующие в этом процессе, и в то какие варианты делают его более безопасным.
Как работает проверка владения доменом?
На высоком уровне проверка владения доменом работает, как и все остальные автоматические проверки, которые являются частью протокола ACME, — протокола, который может использовать центр сертификации (CA), например Let's Encrypt, и клиентское программное обеспечение, например Certbot, для обмена информацией о том, какой сертификат запрашивает сервер, и как сервер должен подтвердить право собственности на соответствующее доменное имя.
Во время проверки владения доменом пользователь запрашивает сертификат из CA с помощью клиентского программного обеспечения ACME, такого как Certbot, который поддерживает данный тип проверки. Когда клиент запрашивает сертификат, CA запрашивает у клиента подтверждение права собственности на домен, путем добавления конкретной TXT-записи в свою зону DNS. Более подробно: CA отправляет уникальный случайный токен ACME-клиенту, и тот, кто имеет контроль над доменом, должен поместить этот токен как TXT-запись в свою зону DNS, в предопределенный поддомен с именем "_acme-challenge" того домена, контроль над которым пытается доказать пользователь.
Например, если Вы пытаетесь проверить домен для *.eff.org, поддомен проверки будет "_acme-challenge.eff.org". Когда значение токена добавляется в зону DNS, клиент сообщает CA продолжить проверку владения, после чего CA будет выполнять DNS-запрос к авторитетным серверам для домена. Если авторитетные DNS-серверы ответят DNS-записью, содержащей правильный токен проверки владения, право собственности на домен будет доказано, и процесс выдачи сертификата может быть продолжен.
DNS служба контролирует цифровую идентичность
Угрозы, связанные с DNS-зоной делает столь опасными, то, что DNS — это то, на что полагаются браузеры пользователей, чтобы знать, с каким IP-адресом они должны связаться, пытаясь достичь вашего домена. Это относится ко всем службам, использующим разрешаемое имя под вашим доменом, от электронной почты до веб-служб.
Когда DNS скомпрометирован, злоумышленник может легко перехватить все подключения, направленные к вашей электронной почте или другой защищенной службе, прекратить шифрование TLS (поскольку теперь они могут подтвердить право собственности на домен и получить для них свои действительные сертификаты), дешифровать данные и прочесть их, а затем повторно зашифровать данные и передать их на ваш сервер. Для большинства людей это было бы очень трудно обнаружить.
Отдельные и ограниченные привилегии
Строго говоря, для того, чтобы ACME-клиент делал обновления в автоматическом режиме, этот клиент должен иметь доступ только к учетным данным, которые могут обновлять TXT-записи для поддоменов "_acme-challenge". К сожалению, большинство программных продуктов DNS и поставщиков услуг DNS не предлагают подробные средства контроля доступа, которые позволяют ограничить эти привилегии, или просто не предоставляют API для автоматизации этого за пределами основных обновлений или транзакций DNS-зоны. Это оставляет возможные методы автоматизации непригодными или небезопасными.
Есть простой способ, который может помочь маневрировать мимо таких ограничений: использовать CNAME-запись. CNAME-записи по существу действуют как ссылки на другую запись DNS. Let's Encrypt проследует по цепочке CNAME-записей и разрешит токен проверки владения для последней записи в цепочке.
Способы смягчения проблемы
Даже используя CNAME-записи, основная проблема заключается в том, что ACME-клиенту по-прежнему будет нужен доступ к учетным данным, которые позволят ему изменить некоторую DNS-запись. Существуют различные способы смягчения этой основной проблемы с различными уровнями сложности и последствиями для безопасности в случае компрометации.
В следующих разделах этот пост представляет некоторые из этих методов, пытаясь объяснить возможные последствия того, что учетные данные будут скомпрометированы. За одним исключением, все они используют CNAME-записи.
Разрешить обновления только для TXT-записей
Первый способ — создать набор учетных данных с привилегиями, которые позволяют обновлять TXT-записи.
В случае компрометации этот метод ограничивает последствия для злоумышленника способностью выдавать сертификаты для всех доменов в зоне DNS (поскольку они могут использовать учетные данные DNS для получения собственных сертификатов), а также прерывание доставки почты. Воздействие на доставку почты происходит из TXT-записей, специфичных для почты, а именно SPF, DKIM и его расширения ADSP и DMARC. Их компрометация также облегчит доставку фишинговых писем, выдающих себя за отправителя из скомпрометированного домена.
Использовать «throwaway» домен подтверждения
Второй способ — вручную создать CNAME-записи для поддомена "_acme-challenge" и указать ими на домен проверки, который будет находиться в зоне, контролируемой другим набором учетных данных.
Например, если Вы хотите получить сертификат для покрытия «yourdomain.tld» и «www.yourdomain.tld», вам придется создать две CNAME-записи — "_ acme-challenge.yourdomain.tld" и "_acme-challenge.www.yourdomain.tld" — а также указать ими на внешний домен для проверки. Домен, используемый для проверки владения, должен быть во внешней зоне DNS или в поддиапазонной зоне DNS, которая имеет свой собственный набор учетных данных для управления. (DNS-зона субделегата определяется с помощью NS-записей и фактически делегирует полный контроль над частью зоны внешнему источнику.)
Эффект компрометации для этого метода довольно ограничен. Поскольку фактические сохраненные учетные данные предназначены для внешней зоны DNS, злоумышленник, получивший учетные данные, получит только возможность выдавать сертификаты для всех доменов, указывающих на записи в этой зоне. Однако, выяснение того, какие домены на самом деле указывают туда, тривиально: злоумышленнику просто нужно будет прочитать журналы прозрачности сертификатов и проверить, имеют ли домены в этих сертификатах магический поддомен, указывающий на уязвимую зону DNS.
Ограниченный доступ к зоне DNS
Если ваше программное обеспечение или поставщик DNS позволяет создавать разрешения, привязанные к поддомену (гранулированные привилегии), это может помочь вам смягчить всю проблему.
К сожалению, на момент публикации был найден единственный поставщик, который дает данные привилегии — это Microsoft Azure DNS. У Dyn предположительно также есть гранулированные привилегии, но мы не смогли найти более низкий уровень привилегий в их сервисе помимо «Обновление записей», которые все еще оставляют зону полностью уязвимой.
Route53 и, возможно, другие позволяют своим пользователям создавать зону субделегата, новые учетные данные пользователя, указывать NS-записи в новую зону и указывать поддомены проверки _acme-challenge для них с использованием CNAME-записей. Нужно много работы для того, чтобы корректно сделать распределение привелегий, используя этот метод, так как нужно пройти все эти шаги для каждого домена, для которого необходимо использовать проверку владения.
Использовать ACME-DNS
Дисклеймер: программное обеспечение, описанное ниже, написано автором (оригинальной статьи — прим. переводчика), и оно используется в качестве примера функций, необходимых для эффективного управления учетными данными, нужными для автоматизации проверки владения доменом через DNS безопасным образом.
Последний метод — это часть программного обеспечения под названием ACME-DNS, написанная для борьбы именно с обсуждаемой проблемой, и она может полностью устранить её. Единственный недостаток заключается в том, что этот метод добавляет еще один компонент в вашу инфраструктуру, который надо поддерживать, а также требует открыть DNS-порт (53) для общего доступа в интернет.
ACME-DNS действует как простой DNS-сервер с ограниченным HTTP API. Сам API позволяет только обновлять TXT-записи автоматически генерируемых случайных поддоменов. В нём нет методов для запроса утерянных учетных данных, обновления или добавления других записей. Он предоставляет две конечные точки:
- /register — эта конечная точка создает новый поддомен для использования, сопровождаемый именем пользователя и паролем. В качестве необязательного параметра конечная точка регистра принимает список диапазонов CIDR для «белых» обновлений.
- /update — эта конечная точка используется для обновления текущего токена проверки владения доменом на сервере.
Чтобы использовать ACME-DNS, вам сначала нужно создать для него A/AAAA-записи, а затем указать к нему NS-записи для создания узла делегирования. После этого Вы просто создаете новый набор учетных данных через конечную точку /register и указываете CNAME-запись из поддомена подтверждения проверки "_acme-challenge" в исходной зоне к вновь созданному поддомену.
Единственные учетные данные, сохраненные локально, будут для ACME-DNS, и они хороши только для обновления точных TXT-записей для поддоменов проверки для доменов в поле. Это эффективно ограничивает влияние возможной компрометации для злоумышленника до способности выдавать сертификаты для этих доменов.
Дополнительные сведения об ACME-DNS см. на странице:
github.com/joohoi/acme-dns
Вывод
Чтобы устранить проблемы с проверкой владения доменом через ACME DNS, обсуждались такие предложения, как assisted-DNS в рабочей группе ACME IETF, но в настоящее время эти проблемы все еще остаются без разрешения. Поскольку единственный способ ограничить воздействие компрометации — это ограничить права доступа учетных записей DNS-зоны до изменения определенных TXT-записей, текущие возможности для надежной реализации автоматизации проверки владения доменом незначетельны.
Единственным устойчивым вариантом было бы заставить программное обеспечение DNS и поставщиков услуг либо внедрять методы для создания более мелкомасштабных учетных данных зоны, либо предоставлять совершенно новый тип учетных данных для этого специфического варианта использования.
