Кратко

  • UNAUTHENTICATE возвращает соединение IMAP в неаутентифицированное состояние, позволяя административному клиенту использовать его для другого пользователя. TLS продолжает работать, но состояние приложения, связанное с прежним пользователем, должно завершиться.
  • Это не полное стирание: команда не удаляет сообщения посредством expunge, не отзывает сертификат TLS, а её взаимодействие с IMAP ID зависит от реализации.
  • Прокси, проверяющий лишь первую аутентификацию и затем пропускающий трафик без соответствующей обработки, может не применить свои ограничения при следующем входе. Успех второго входа сам по себе не доказывает сохранение контроля.

У закрытия соединения была ещё одна работа

В схеме «одно соединение — один пользователь» окончание соединения задаёт понятную границу. Следующий пользователь начинает с нового входа. За этой простотой стоит повторяющаяся работа: создать канал, установить защиту, снова пройти начальные процедуры. Для административной системы, обслуживающей многих пользователей, такое повторение может выглядеть неоправданным.

RFC 8437 описывает способ сохранить канал и завершить привязку на уровне приложения. UNAUTHENTICATE позволяет вернуться в неаутентифицированное состояние, не прекращая TLS. Назначение конкретно: административный клиент может работать от имени нескольких пользователей. Из этого не возникает общего права произвольного клиента выбирать произвольную учётную запись.

Экономия здесь касается жизненного цикла соединения. Требования к полномочиям следующего пользователя никуда не исчезают. Напротив, когда срок жизни канала становится длиннее срока действия одной пользовательской сессии, нужно явно показать, какие прежние допущения перестают действовать внутри продолжающегося обмена.

Поэтому демонстрация успешного второго входа отвечает только на часть вопроса. Она показывает, что новый путь аутентификации сработал. Она не показывает автоматически, что исчезли старые сведения о группах, прекратились поисковые контексты или прокси повторно применил нужные ограничения. Один положительный результат нельзя без проверки распространить на все эти утверждения.

В этой статье анализируются правила спецификаций и их эксплуатационный смысл. Переключение почтовых учётных записей, обход ограничений прокси, измерение задержек и вмешательство в работающие системы не проводились. Описанный в документе условный риск не равен установленной уязвимости конкретного поставщика.

Возврат состояния вместо разрыва транспорта

UNAUTHENTICATE добавляет переход из аутентифицированного состояния и состояния с выбранным почтовым ящиком в неаутентифицированное. Выбранный ящик перестаёт быть выбранным, но команда не выполняет expunge сообщений. Состояние TLS сохраняется. Называть это аналогом LOGOUT, очисткой содержимого ящика или отзывом сертификата было бы неверно.

У команды нет аргументов. Успешное выполнение обозначается OK. BAD предусмотрен для таких случаев, как недопустимое состояние, ошибочный синтаксис или отсутствие объявления соответствующей возможности. Ответ NO запрещён. Если сервер не способен сбросить состояние, он вправе отправить нетегированный BYE и закрыть соединение.

Это важное ограничение обещания эффективности. Сохранить соединение требуется не любой ценой. Когда переход нельзя выполнить корректно, документ допускает потерю канала. Правило не оправдывает неопределённое продолжение, при котором клиент считает старую идентичность завершённой, а сервер продолжает действовать под её прежними полномочиями вопреки этому ожиданию.

После возврата можно использовать AUTHENTICATE или LOGIN в соответствии с доступными возможностями. Само обнаружение поддержки тоже имеет нюанс: сервер может объявлять UNAUTHENTICATE только после аутентификации. Административному клиенту может понадобиться повторный CAPABILITY. Отсутствие возможности в раннем ответе и отсутствие поддержки вообще — не обязательно одно и то же.

У сокращения числа обменов есть условия. Последующий AUTHENTICATE можно отправить без ожидания в описанном RFC случае, когда активного уровня безопасности SASL нет. Вместе с SASL-IR повторная административная аутентификация при подходящих условиях может уложиться в один обмен туда и обратно. Это не универсальное обещание задержки для любой конфигурации.

Оценивать экономию в конкретной инфраструктуре можно лишь после определения используемых механизмов и измерения их работы. Текст стандарта задаёт возможность. Он не предоставляет готового показателя производительности, который можно без поправок перенести в расчёт затрат.

Прежний пользователь остаётся не только в имени

У приложения может быть одно поле с текущим именем пользователя и множество состояний, возникших из решений для этого пользователя. Сюда относятся кэши полномочий, сохранённый поиск, активированные функции и уведомления. Замена имени не доказывает, что все эти зависимости завершились.

RFC требует сбрасывать состояние расширений при объявленном и используемом UNAUTHENTICATE, отдельно оговаривая STARTTLS и ID. Требование относится не только к уже известным расширениям. Будущая функция, которая хранит состояние, тоже должна вписываться в переход между пользователями.

Для ACL документ указывает на очистку кэшей идентичности и принадлежности к группам. Это не удаление постоянных правил доступа к почтовому ящику. Убирается память о предпосылках решения, относящихся к прежнему субъекту. Если смешать кэш с постоянной политикой, обязательное разделение пользователей начнёт выглядеть как разрушение данных, которого спецификация не требует.

CONDSTORE должен снова считаться неактивированным. Все функции, включённые через ENABLE, отключаются. Сохранённый результат SEARCHRES становится пустым. LANGUAGE возвращается к i-default. Для всех поисковых контекстов на сервере действует неявный CANCELUPDATE, а NOTIFY возвращается к соответствующему базовому поведению.

Конкретность списка нужна не ради перечня названий. Она не позволяет признать всё состояние очищенным по одному косвенному признаку. Новый пользователь может успешно открыть свой ящик, но это не будет доказательством прекращения прежнего поискового контекста. Очистка кэша доступа не удостоверяет сброс уведомлений.

Не каждый возможный пропуск обязательно вызывает утечку. Последствие зависит от расширения, реализации и последующих действий. Но проверка должна относиться именно к тому состоянию, о завершении которого делается вывод. Иначе отрицательная обязанность — не сохранить чужие условия работы — подменяется положительным результатом одной новой операции.

Для сопровождения это означает, что однажды выданное разрешение не должно становиться бессрочным по умолчанию. Позднее добавленное расширение может создать новую память на пользователя, не меняя аутентификатор. Объём необходимой очистки уже изменился. У команды новой функции должна появиться обязанность объяснить, как эта память заканчивает свой срок жизни.

Защита сохраняется не одинаково на всех уровнях

Фраза «шифрование остаётся» недостаточно точна. TLS действительно продолжается. Однако для уровня безопасности SASL UNAUTHENTICATE задаёт отдельные точки завершения в двух направлениях.

На стороне отправки клиента SASL заканчивается сразу после CRLF, завершающего команду. На стороне отправки сервера — после CRLF ответа OK. У COMPRESS есть соответствующие границы завершения; когда это применимо, сжатие прекращается раньше SASL.

Эти точки определяют, как интерпретировать следующие байты. Они не являются необязательной подробностью сообщения об успехе. Открытый канал и состоявшийся второй вход сами по себе не показывают, что обе стороны одинаково прошли границы слоёв.

RFC 4422 описывает общую модель SASL, но общие правила другого сценария повторной аутентификации нельзя механически переносить на UNAUTHENTICATE. Здесь нужно следовать конкретным условиям RFC 8437. Сохранение TLS и завершение прежнего слоя SASL совместимы, потому что это разные механизмы с разными сроками действия.

Полноценная приёмка должна разделять доказательства по этим уровням. В данном исследовании не записывался трафик и не исполнялись соответствующие переходы. Поэтому оно определяет, что требуется проверить, но не удостоверяет корректность какой-либо реализации.

Сохранившиеся учётные данные не выдают новые права автоматически

Административный клиент может аутентифицироваться как один субъект и просить действовать от имени другого. RFC 4422 различает аутентифицированную идентичность и запрашиваемую идентичность авторизации. Сервер обязан проверить и учётные данные, и право действовать с указанной идентичностью.

EXTERNAL использует учётные данные, установленные вне SASL, и может передавать идентичность авторизации. Собственного уровня безопасности этот механизм не предоставляет. Без предварительного соглашения клиент не может также предполагать, какой внешний источник данных будет использован, в том числе считать, что им обязательно служит TLS. Необходима достаточная внешняя защита.

RFC 8437 описывает сохранение клиентских учётных данных TLS с прекращением их привязки на уровне приложения. Административный сертификат может позволять работу для нескольких пользователей через EXTERNAL, если это разрешено правилами авторизации. Из наличия сертификата не следует право выбрать любую почтовую учётную запись.

Документ рассматривает и условный случай, когда соединение imaps получает PREAUTH с идентичностью по умолчанию. Чтобы разорвать такую привязку и затем провести аутентификацию от имени другого пользователя через EXTERNAL, возможность UNAUTHENTICATE должна быть объявлена. Это описание определённого начального состояния, а не утверждение о всех защищённых соединениях.

Проверяющему нужны разные ответы: какие внешние учётные данные сохранились, завершилась ли старая привязка приложения и кто разрешил новую идентичность. Первый ответ не заменяет два остальных. Требовать исчезновения сертификата означало бы проверять не тот переход; разрешать любые полномочия потому, что сертификат остался, означало бы отменить авторизацию.

Исключение должно быть видно в обещании

IMAP ID относится не к удостоверению личности пользователя ящика. RFC 2971 описывает сведения о реализации, например о программном обеспечении. Взаимодействие ID с UNAUTHENTICATE оставлено RFC 8437 на усмотрение реализации.

Поэтому утверждение, что исчезает вообще вся прежняя информация, слишком широко. Нужно выяснять, какие сведения ID сохраняются и как используются. При этом RFC 2971 запрещает на их основании менять работу, выполнять оптимизации или отказывать в доступе. Сообщить меньше сведений или NIL допустимо, передавать ложные сведения — нет.

Документ также обращает внимание на последствия уникальных идентификаторов и журналирования для приватности. Корректный сброс почтового состояния не доказывает минимизацию информации, позволяющей наблюдать или отслеживать работу. Функциональное разделение и снижение объёма данных связаны, но не подтверждаются одним результатом.

RFC 8437 упоминает возможную пользу повторного использования соединений между центрами обработки данных против некоторых видов анализа трафика. Это условная возможность, а не гарантия анонимности и не измеренный здесь эффект. Если часть структуры соединений становится менее заметной, остальные источники информации не исчезают автоматически.

Прокси мог закончить проверку слишком рано

Представим прокси, который проверил первую аутентификацию, выбрал сервер назначения и затем только передаёт данные. Первая идентичность прошла его ограничения. Если внутри того же соединения она завершится и появится следующая, повторная аутентификация может попасть непосредственно на сервер назначения.

RFC 8437 предупреждает: в такой архитектуре возможен обход ограничений, присутствующих у прокси и отсутствующих на сервере. Важен не сам факт наличия посредника, а распределение правил и прекращение его проверочной роли после первого входа.

Реализации обязаны предоставлять механизм отключения UNAUTHENTICATE. Спецификация поясняет, что обработка команды прокси устраняет именно эту указанную проблему, и рассматривает ограничение функции административными идентичностями как другой вариант. Название «административная» не делает объём допустимого представительства безграничным.

Есть ещё одна явно названная несовместимость: сервер сопоставляет аутентифицированную идентичность с идентичностью операционной системы и после входа отказывается от всех административных привилегий. Такой отказ может быть сознательно выбранной границей безопасности. Его несовместимость с повторным использованием не доказывает недостаток архитектуры и не даёт оснований судить обо всех серверах какой-либо операционной системы.

Обсуждаемое в RFC соотношение эффективности и пригодности для сред с повышенными требованиями к безопасности — вопрос конструкции, а не опубликованное здесь сравнение измерений. Обоснование отдельной команды возврата также принадлежит документу: сохранить более простой вход в обработку аутентификации и облегчить отключение функции. Из этого не требуется выдумывать мотивы разработчиков.

Что действительно установлено источниками

На момент исследования страницы исправлений RFC 8437, RFC 4422 и RFC 2971 не вернули подходящих записей. Это характеристика просмотренных источников, а не свидетельство отсутствия дефектов в современных продуктах.

Рассуждение Lu Heng о разделении власти принимать решения и обязанности нести последствия помогает поставить эксплуатационный вопрос. Отвечает ли тот, кто разрешает экономить на соединениях, за сохранение разделения пользователей и работу посредников при следующем входе? Для этого вопроса не нужно подозревать злой умысел у сторонников эффективности.

Требование считать реальность, а не продвижение позиции, продуктом редакции задаёт обратное ограничение. Источники подтверждают правила и условные предупреждения. Они не подтверждают распространённость функции, реальную экономию или безопасность непроверенной платформы.

Обоснованный вывод поэтому уже, чем рекомендация всем включить либо всем запретить повторное использование. Канал можно сохранить, если доказано завершение прежних полномочий приложения, необходимого состояния и независимое разрешение следующей идентичности. Срок жизни транспорта не должен становиться сроком действия чужого разрешения.