dxdt.blog: занимательный интернет-журнал

Технологии DKIM и DMARC предназначены для управления политиками доставки электронной почты, но подходят к этой задаче с разных сторон. DKIM (DomainKeys Identified Mail) – позволяет сопроводить сообщение электронной почты некоторым доказательством, что отправляющий сервер имеет отношение к домену, который указан в качестве источника сообщения, что этот сервер знает некоторый секретный ключ. Для предоставления доказательств используется цифровая подпись и публикация в DNS соответствующих открытых ключей для проверки подписи. Нужно учитывать, что это “техническая” подпись: она может, косвенно, подтверждать подлинность сервера-источника сообщения, целостность каких-то технических элементов сообщения (в том числе, целостность полезного содержания), однако используется в контексте серверов, то есть, это не подтверждение для конкретного адреса отправителя или пользователя почтовой системы.

DKIM предложили в целях борьбы с нежелательной рассылкой сообщений, когда почтовый адрес отправителя подделывается (в e-mail не предусмотрено защиты от этого). Сейчас почтовый сервер без DKIM для отправляемых сообщений держать не принято – могут быть проблемы с доставкой, некоторые серверы на стороне получателя автоматически классифицируют входящие сообщения без DKIM как спам.

Логика работы DKIM такая: отправляющий сервер, используя секретный ключ, вычисляет подпись для некоторых технических элементов, составляющих сообщение электронной почты, встраивает значение подписи и вспомогательные сведения в состав сообщения (в так называемый “технический конверт”, который не виден для обычных пользователей), отправляет получившееся сообщение. Принимающий (или промежуточный) почтовый сервер, получив письмо, может использовать данные, переданные в DKIM-параметрах, для извлечения из DNS открытого ключа и, собственно, проверки подписи на сообщении. Если сообщение было отправлено сервером, который не имел доступа к нужному ключу, то этот сервер не может вычислить корректную подпись DKIM. В общем-то – всё. Именная принадлежность ключей и других параметров определяется на основании домена-источника. В самом простом случае – это домен почтового адреса, указанного в качестве отправителя письма. Тут, впрочем, есть технические тонкости, опять же, невидимые для типичного пользователя, но их сейчас можно пропустить: будем считать, что если в письме нужным способом указан адрес отправителя user@test.ru, то домен-источник – test.ru, для него и публикуются ключи в DNS (они публикуются в TXT-записях для специального имени-селектора).

Заметьте, что наличие или отсутствие DKIM не вводит каких-то технических обязательств на принимающей стороне: технически, DKIM – это дополнительные поля (заголовки) в не менее техническом конверте, сообщение всё равно приходит на принимающий сервер обычным способом, а этот принимающий сервер прекрасно может игнорировать заголовки DKIM. То есть, включение DKIM вовсе не влияет на базовые механизмы доставки почты, это протокол уровня политик, в его работе всё зависит от настроек, используемых сторонами.

Для того, чтобы администратор почтового домена мог типовым машиночитаемым способом опубликовать рекомендации по обработке поступающих сообщений другими серверами – придумана спецификация DMARC (Domain-based Message Authentication, Reporting, and Conformance). Опять же, это спецификация, описывающая способы публикации политик обработки почты, формат записи и принципы интерпретации. DMARC – это текстовая строка определённого формата, опубликованная в TXT-записи. DMARC предназначается для использования вместе с DKIM и SPF (Sender Policy Framework – здесь не рассматривается). Но, каким бы странным это ни показалось: публикация DMARC никак не зависит от DKIM, и наоборот. Внедрение DKIM на сервере-отправителе, отправка сообщений с DKIM – возможны без публикации DMARC, а публикация DMARC и эффективное использование – возможны без соответствующего по именам внедрения DKIM (пример – см. ниже). Естественно, DMARC и DKIM рекомендуется применять вместе: если вы настроили DKIM, то очень неплохо будет опубликовать и сведения политики в DMARC, поскольку эти сведения могут подсказать принимающему серверу, что ему делать с полученными из вашего домена письмами. Тем не менее, проверка DKIM не требует извлечения сведений DMARC. А DMARC может применяться без фактической поддержки DKIM.

Пример, хорошо иллюстрирующий ситуацию: администратор домена не планирует использовать этот домен в качестве почтового, поэтому требуется устроить так, чтобы принимающие серверы, поддерживающие DMARC (важная оговорка!), отбрасывали все сообщения с адресами из данного домена. В таком случае, администратор просто публикует строгую политику обработки DMARC (“reject”), но вовсе не размещает в DNS ключи DKIM и даже не настраивает почтовый сервер. То есть, администратор домена не предполагает отправки сообщений с адресами в этом домене, а такая конфигурация DMARC означает, что если какой-то другой сервер отправит такое сообщение, то оно может быть отброшено на принимающей стороне.

Ключевым моментом эффективности DMARC является не состав политики, а то, поддерживается ли DMARC принимающим сервером, а если поддерживается, то как именно. Сама по себе публикация сведений DMARC не обязывает принимающий сервер не только следовать опубликованным политикам, но даже и запрашивать их из DNS: для приёма и обработки сообщений это не требуется (как не требуется и возможность обработки DKIM). Конечно, грамотно настроенный сервер должен обрабатывать и DKIM, и DMARC, однако такая настройка вовсе не обязательно означает, что письмо без DKIM будет молчаливо отброшено, если принимающий сервер обнаружит политику reject в DMARC. Другими словами: DMARC носит более чем рекомендательный характер, поэтому целиком полагаться на указание политики обработки нельзя.

Вообще, эта история с встраиваемой в посторонние сайты браузером Firefox рекламы Mozilla VPN тоже имеет отношение к стремительно наступающему Новому Средневековью. Скорее всего, в этом конкретном случае, у пользователя всё ещё имеются возможности не подключать “промо” или “отписаться” (как минимум, сообщают, что можно выключить флаг в настройках браузера – что, конечно, само по себе показательно: флаг для отключения встроенной в браузер рекламы). Важно совсем другое. Ещё некоторое время назад разработчикам браузера могло бы показаться, что задача браузера состоит в отрисовывании веб-страницы максимально близко к некоторым спецификациям (“веб-стандартам” и пр.). Идея воспользоваться статусом браузера и модифицировать визуальное оформление страницы так, чтобы закрыть его собственной рекламой, должна была бы быть отброшена. Это не отменяет богатой истории подобных подмен, начиная с массового перенаправления “несуществующих доменных имён” с использованием положения провайдера авторитативных серверов DNS и вплоть до вмешательства в HTTP-трафик на стороне провайдера доступа или даже на транзите. Наоборот, такой исторический опыт и должен бы приводить к тому, что в приличном браузере подобные практики не могут рассматриваться. Но, конечно, не в условиях Нового Средневековья.

Так, в случае браузера, типичный пользователь может подумать, что реклама встроена в сам сайт. Возможно, расчёт делался на это. Сейчас обычна ситуация, когда для того, чтобы добраться до полезного (возможно – полезного) содержания веб-страницы на новостном, например, сайте, нужно сперва закрыть три или четыре всплывающих окна под общим названием “Мы используем куки!”, а потом ещё сдвинуть/перетащить разнообразные плашки, в половину экрана, объясняющие, что этот сайт нужно поддержать, что ему нужно разрешить уведомления и отключить “блокировщик рекламы”, подписавшись на рассылку. На рубеже веков это являлось предметом шуток, сейчас – уже без шуток, поэтому обычный пользователь Firefox, предположим, привык и просто не заметит ничего необычного, как и разработчики браузера (но задача по откручиванию рекламы собственного сервиса, который нуждается в новых регистрациях, – выполнена).

Пока что с Firefox это не сработало: пользователи всё поняли правильно и даже возмутились. Не факт, что это будет иметь долгий эффект: интернеты становятся “корпоративными”, в том числе, на стороне клиента. Нужно ли ожидать рекламных пауз в ядре Linux? Риторический вопрос.

Не самым хорошим образом развивается браузер Firefox, хоть и предсказуемо, к сожалению: теперь этот браузер принялся показывать блокирующую всплывающую рекламу Mozilla VPN на произвольных веб-страницах. Надо сказать, что если сравнивать с подобным внедрением рекламы, то остаётся не так уж и много вариантов поведения браузера, которые хуже. В VPN-сервис, можно предположить, там ещё больше встроено всякой подобной нагрузки. (Дополнение. Предположим ещё, что блокирующая реклама Mozilla VPN не показывалась тем пользователям, которые уже купили Mozilla VPN. Тогда получается простая и известная схема: чтобы убрать рекламу – нужно заплатить, а иначе – будете просматривать рекламный видеоролик перед тем, как страница сайта отобразится. Забавно.)

Google пишет, что с декабря 2023 года начнут удалять google-аккаунты, в которых не было “активности” в течение двух лет. Тут главное, чтобы не оказалось так, что после удаления кто-то ещё может зарегистрировать аккаунт с таким же именем, получив, предположим, авторизацию привязанных к имени внешних (относительно Google) ресурсов, “подхватив” какие-нибудь сервисы и регистрационную информацию (да, там уже есть в описании процесса оговорки о “совершённых покупках”, что будут исключения и пр., но это ничего ещё не гарантирует). Вариант, впрочем, известный, поэтому есть шанс, что в Google об этом всё же подумали (но не факт).

Пишут (правда, в несколько странной форме), что в Apple запрещают сотрудникам использовать ChatGPT и прочие “внешние ИИ” для рабочих задач. Якобы, из-за опасений, что возможна “утечка конфиденциальных данных”. Вообще, опасаться следовало бы не только и не столько утечек, сколько того, что подобный внешний инструмент, контролируемый другой компанией, начнёт целевым образом управлять деятельностью сотрудников, через подсказки этого самого ИИ. Как показывает практика целевого фишинга, ввести работника компании “Имярек” в заблуждение, или просто-напросто обмануть, – не так уж и сложно. Тем более, если вы управляете выдачей раскрученного в нужном направлении профильными СМИ инструмента, который называется “мощный современный ИИ”.

Оказывается, некоторое время назад в Google добавили занятную функцию в приложение для (так называемой) “двухфакторной аутентификации” (2FA), а именно – возможность восстановления “из облака” в случае потери устройства. Заметьте, что весь смысл “двухфакторной аутентификации” состоит в том, что подключающийся пользователь может доказать, что у него есть доступ к дополнительному секрету, кроме пароля, который могли и украсть. Естественно, этот дополнительный секрет может проявляться как “одноразовые пароли” или какие-нибудь PIN-коды, которые, например, генерируются в зависимости от текущего времени (и от значения секрета, конечно).

Понятно, что если секрет не оформлен в виде специального аппаратного токена, то ничто не мешает делать резервную копию. Именно поэтому не нужно преувеличивать степень защищённости, обеспечиваемую применением 2FA: многие решения позволяют использовать второй секрет в автоматическом режиме, разместив его в скрипте, дабы минимизировать количество препятствий, которые приходится преодолевать при подключении к той или иной нужной информационной системе. Возможность написания скрипта и хранения секрета рядом с паролем – требует достаточно высокой квалификации и понимания того, как работает данный протокол. Так что, всё же, традиционный подход тут состоит в том, что пользователю предлагается установить приложение на смартфон (тот самый Google Authenticator, предположим), после чего использовать смартфон в роли “аппаратного токена”. И тут возникает та самая проблема: если аппарат потерян, то у пользователя больше нет возможности пройти аутентификацию привычным способом; пользователю теперь придётся предпринять дополнительные шаги, чтобы переустановить 2FA-доступ, нередко – в офлайн-режиме. И вот, корпорация Google предлагает странным способом решить проблему, а именно – просто сохранить секретные “аутентификаторы” на стороне Google, в “облаке”:

С этим обновлением мы вводим решение проблемы – делая одноразовые коды более надёжными путём безопасного хранения их в Google-аккаунте пользователя.
(With this update we’re rolling out a solution to this problem, making one time codes more durable by storing them safely in users’ Google Account.)

То есть, наличие потенциальной привязки к аппаратному устройству делало 2FA полезным инструментом, однако Google предлагает передать дополнительный пароль на внешние серверы, в результате чего вторым фактором оказывается Google-аккаунт. Теперь, если пользователям некоторой корпоративной системы предложено использовать Google Authenticator в качестве хранилища второго секрета (распространённый случай), то это означает, что доступ к системе завязан уже даже не на неконтролируемое приложение от третьей стороны, а прямо на аккаунт Google.

На картинках ниже – замок Fichet 787 с “рычажным” механизмом (источник фото: Toool Blackbag).

Замок в разрезе и ключ (фото: CC-BY-4.0 Jan-Willem, Toool Blackbag).

Фрагмент основной части механизма (фото: CC-BY-4.0 Jan-Willem, Toool Blackbag).

“Кодирующая” часть ключа содержит пазы, которые сдвигают внутренние рычажки (1), поворачивающие через зубчатое зацепление диски (зубчатые колёсики – 2), блокирующие вращение механизма: если углы, выставленные на ключе, соответствуют коду замка, то колёсики поворачиваются так, что прорези в них совпадают, образуется общая длинная прорезь, что и освобождает траверсу, делая возможным поворот. Занятно, что устройство, вообще-то, аналогично дисковому, например, замку, но здесь пакет дисков повёрнут относительно ключа, поэтому вместо “угловых бородок” получаются пазы, а для преобразования углов вращения служат рычажки (последние, кстати, можно считать “транслированным” вариантом цилиндров-штифтов в обычных “английских” замках – просто, прямолинейный подъём штифта здесь преобразуется в поворот).

Кстати, в продолжение Certificate Transparency. Регулярно приходится сталкиваться с вопросами или предположениями относительно того или иного TLS-сертификата, которые сопровождаются недостаточным количеством “иллюстративных” данных. (Эта записка – рекомендации для обычных пользователей.)

Предположим, что вы где-то встретили или обнаружили “подозрительный TLS-сертификат” и хотите получить комментарии специалиста про этот сертификат. Как поступить?

Прежде всего: необходимо сохранить сам файл сертификата непосредственно и полностью. Скриншот окна Windows с информацией “об издателе” и со сроками действия – никак не позволяет что-то содержательное сказать о сертификате: по этим данным даже нельзя судить о том, разные сертификаты вы просматриваете или один и тот же. Сохранить сертификат можно при помощи функции экспорта. К сожалению, реализации этой функции существенно различаются от приложения к приложению. Например, в браузере нужно кликнуть на “замочек в адресной строке” или на вкладку панели веб-разработчика, соответствующую настройкам безопасности сайта, или ещё куда-то, но логика данного действия общая – нужно найти, где сертификат сервера (веб-сайта) экспортируется в файл. Файл может иметь разные форматы (Base64, “двоичный”) и разные расширения в имени (.pem, .cer, .der, .bin, .cert и др.), но это, обычно, не важно – для специалиста это редко является проблемой. Главное – получить сам сертификат полностью в файле. Если функция экспорта позволяет сохранить “цепочку сертификатов” – тем лучше, сохраните цепочку. Основная причина, по которой нужен именно файл, в том, что сертификат содержит значение подписи, а это значение является доказательством того, что сертификат действительно был выпущен и подписан с использованием того или иного ключа. Кроме того – можно удобным способом просматривать все поля сертификата (серийный номер, расширения, ключ и пр.).

Если вам по каким-то причинам удаётся просмотреть только значения конкретных полей сертификата, то, во-первых, нужно сразу отметить, что ценной информации будет очень мало, и, во-вторых, попытаться сохранить серийный номер, отпечаток сертификата (значение хеш-функции для сертификата), имена, – то есть, название УЦ и имя, для которого сертификат выпущен (Issuer, Subject, Subject Alternative Name), – значение ключа (или отпечаток ключа; в сертификате публикуется открытый ключ) и тип криптосистемы, значение подписи с указанием на тип криптосистемы, сроки действия и сведения о цепочке сертификатов (серийные номера, имена, отпечатки), использованной для валидации.

Но, опять же, файла сертификата эта информация не заменит. Сохраняйте и показывайте сертификат в файле (необходимая оговорка: в теории, конкретный сертификат, который встречен “где-то на сайте”, может содержать сведения о вашем подключении к этому сайту, однако, это редкая ситуация).

На сайте ТЦИ (Технический Центр Интернет) опубликована моя статья о технологии Certificate Transparency (CT) и её роли в современном Интернете. Статья рассказывает не столько о базовых принципах построения CT (они достаточно широко известны), сколько об особенностях реального применения данной технологии – о проблемах, связанных с неверной интерпретацией значения меток в сертификатах, о полноте CT-логов.

Certificate Transparency […] лишь предоставляет инструмент для наблюдения за деятельностью УЦ, но никак не ограничивает эту деятельность на техническом уровне.

Ещё о пресертификатах в Certificate Transparency (CT) и странных “свойствах”, которые возникают вокруг. TLS-сертификаты превращаются в пресертификаты после того, как добавлено специальное расширение Poison. Может показаться, что с этим расширением тоже связана проблема “курицы и яйца”, поскольку нарушать процесс валидации poison-расширение должно потому, что оно помечено как Critical (критическое), но имеет тип, неизвестный валидатору – неизвестные критические типы, согласно рекомендациям, должны приводить к тому, что сертификат считается невалидным (а вот расширения неизвестного типа, которые не помечены как критические, можно игнорировать). Если же валидатор знает тип poison-расширения, то флаг Critical уже не должен препятствовать валидации. Это так, однако проблемы тут нет: в том случае, когда валидатор распознал poison-расширение, он не должен принимать сертификат на правах валидного, так как, грубо говоря, видит, что это пресертификат (ну или можно интерпретировать иначе: наличие poison-расширения означает, что сертификат не должен использоваться так же, как и сертификат без Poison). В общем, всё же появляется неплохой шанс выстроить однозначный процесс валидации.

С пресертификатами связано множество весьма неочевидных аспектов. Так, единственный смысл в пресертификатах – это создание “костыля” для получения метки времени от сервиса CT-лога, чтобы включить эту метку в сертификат. Метка (она называется SCT) связана с конкретным пресертификатом и подписывается лог-сервисом. Но включается метка уже в сертификат, который от пресертификата отличается в некоторых деталях. Напрмер, сертификат не должен содержать poison-расширение. При валидации сертификата проверяется и SCT-метка (ну, если валидирующая сторона, – скажем, браузер, – хочет проверить метку). Понятно, что если подпись вычислена для другого набора данных (пресертификат), то она не сойдётся. Как же устроены процессы подписывания и проверки подписи SCT-метки? Они устроены непросто.

При вычислении подписи для пресертификата сервис CT-лога использует в качестве входных данных не весь сертификат, а только его “содержательную часть” (некоторое зафиксированное в структуре подмножество полей), из которой, к тому же, удаляется poison-расширение. Это, что называется, первый “сюрприз”: poison-расширение должно присутствовать в составе поступающего пресертификата не только потому, что оно и делает сертификат пресертификатом, но и потому, что иначе не сойдётся подпись УЦ на пресертификате, а подпись должен проверить сервис лога. Дописать какие-то данные в сертификат не выйдет. Однако поскольку в сертификате Poison удаляется, то и подпись в SCT нужна на данных без poison-расширения. Второй “сюрприз”: при проверке подписи SCT в сертификате – нужно восстановить содержательную часть пресертификата в точно таком виде, какой передавался в сервис CT-лога, но с учётом удаления Poison – то есть, нужно удалить “лишние” расширения (SCT-метки), а те расширения, которые останутся, должны совпасть с конфигурацией пресертифката. А поскольку такое преобразование снова удаляет из состава сертификата значение подписи, к данным сертификата, перед проверкой, вместе с другими служебными параметрами SCT, нужно присоединить отпечаток открытого ключа УЦ. Понятно, что то же самое делается и на стороне CT-лога, при формировании SCT. Так что общий алгоритм местами “макаронный”, но, тем не менее, используется. Не удивительно, что в новой версии CT пресертификатов нет.

Можно ли в вебе на стороне сервера определить, какой именно версии браузер устанавливает TLS-соединение, в самом начале этого соединения? Например, для того, чтобы выбрать сертификат от подходящего УЦ (см. ниже). Хитрость в том, что привычный способ, когда браузер определяется по HTTP-заголовку User-Agent, тут не подходит: на начальном этапе установления соединения никаких HTTP-заголовков ещё нет, а вот серверный сертификат передавать нужно. И речь не про выбор сертификата на основе перечня поддерживаемых криптосистем, как это делается при настройке параллельной работы ГОСТ-алгоритмов и “обычных” алгоритмов в TLS/HTTPS – эта задача как раз решается весьма просто. Вообще, проблема находится на другом уровне: строго говоря, узнавать нужно даже не столько браузер, сколько конкретную библиотеку, реализующую TLS (так, для Firefox это будет NSS), и конкретный профиль данной библиотеки. Вообще, сделать выбор иногда можно на основе анализа состава TLS-сообщений, но так как набор этих сообщений не велик, а сам перечень может изменяться, то и точность не велика. Тем не менее, конкретная разновидность браузеров могла бы сигналить серверу, что именно такой браузер подключается. Это реализуется через дополнение TLS-сообщений, но внедрение потребует доработки TLS-стека как на стороне сервера, так и на стороне браузера.

А вот что касается именно списка поддерживаемых УЦ, то в TLS уже есть встроенный механизм, в версии 1.3 он так и называется – “certificate_authorities”. Это расширение, которое клиент может включить в состав сообщения ClienHello (начальное сообщение TLS-соединения), а сервер может обработать и – выбрать нужный сертификат, в том числе, для одной и той же криптосистемы. Вот только распространённые браузеры данное расширение не поддерживают, а если бы и поддерживали, то туда пришлось бы вписывать слишком много имён УЦ, так как в типичный дистрибутив браузера их входят многие десятки. Так что доработка, как минимум, браузера – всё равно потребуется.