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

Бывают контринтуитивные решения, бывают контринтуитивные в квадрате, но многое тут зависит от того, как преподносят модель “интуиции”. Пример из области, близкой dxdt.ru: вычисление общего секрета по протоколу Диффи-Хеллмана. Первый уровень контринтуитивности тут традиционно описывается так: нужно получить общий секретный ключ через открытый канал, но это “невозможно”, поскольку – как же передать секретный ключ по открытому каналу, чтобы никто не увидел? “Интуитивные” хитрости тут скрыты в понятиях “получить” и “передать”.

Оказывается, протокол Диффи-Хеллмана – он не столько про передачу секрета, сколько про вычисление общего значения таким способом, который для третьей стороны вычислительно сложно обратить. То есть, никакого волшебного способа передачи секрета по открытому каналу так, чтобы никто не увидел, протокол не предлагает. Протокол реализуется в другой модели: здесь секрет передаётся в такой форме, которую сложно обратить, но всё равно третья сторона видит процесс передачи и получает информацию, достаточную для восстановления секрета (но предполагается, что восстановить его вычислительно сложно). Никакого “ключи есть только на клиенте” тут не наблюдается и не предусматривается. Понимание этого и есть вторая степень контринтуитивности: что бы там ни говорили, но ключи-то передаются в трафике – они могут быть записаны.

И вот вся эта логика превращения контринтуитивности сейчас хорошо проявляется в том, как воспринимают очередные достижения генерирования текстов силами систем ИИ.

Из недавней записки цитата про ИИ:

Естественно, такая система может использоваться при принятии решений, в качестве источника подсказок. Известно, что экономикой многих предприятий управляет MS Excel, как и целым рядом научных направлений. Что же говорить про такой удобный инструмент, как генератор текстов – он тут оказывается гораздо мощнее, чем Excel. Вот и может так выйти, что куча административных процессов в мире попадёт в зависимость от некоторого центрального сервиса, который, через модификацию выдачи “нейросети”, станет управлять ими, двигать, так сказать, в нужном направлении. Это лучше профилирования человеческой деятельности путём “обучения нейросетки” на непонятно какой выборке, и приближается по эффективности к дорисовыванию картинок высокого разрешения на основании значений нескольких пикселей.

Технологии 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 […] лишь предоставляет инструмент для наблюдения за деятельностью УЦ, но никак не ограничивает эту деятельность на техническом уровне.