Кратко

  • IMAP COMPRESS включал DEFLATE лишь после тегированного OK: сервер сжимал данные сразу после CRLF, завершавшего ответ, а клиент — начиная со следующей команды.
  • История, сокращавшая команды, заголовки и текст, привязывала будущие байты к скрытому состоянию. Поздние рекомендации объяснили риск наблюдаемой длины, но не доказали отдельную атаку на IMAP COMPRESS.

Один CRLF разделил два способа читать поток

IMAP уже строил разговор из тегированных команд, нетегированных данных и итогового результата, повторяющего тег клиента. RFC 4978 не добавил новый вид ответа. Сервер объявлял COMPRESS=DEFLATE, клиент посылал COMPRESS DEFLATE, а знакомые OK, NO или BAD сообщали решение.

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

Так одна позиция байта получила полномочие менять правила. Поспешивший клиент подал бы открытый текст декомпрессору. Запоздавший на один ответ сервер заставил бы клиента принять сжатые биты за синтаксис IMAP. TCP мог доставить все без потерь и по порядку, но сеанс все равно распался бы из-за разных значений одних байтов.

Capability давала разрешение, а не результат

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

Правила отказа сохраняли узкий смысл. Если тот же механизм уже работал в другом слое, сервер мог ответить NO с COMPRESSIONACTIVE. Повторно включать расширение было нельзя. Две поверхности переговоров не давали права складывать два одинаковых состояния.

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

Порядок слоев не повторял порядок команд

Сеанс мог получить защитный слой SASL или TLS. Для отправки действовала фиксированная последовательность: сначала COMPRESS, затем подпись или шифрование SASL при их наличии, наконец TLS. Получатель выполнял действия в обратном порядке.

Стек оставался тем же, даже если клиент запрашивал возможности в иной хронологии. История переговоров и порядок преобразований были разными фактами. COMPRESS участвовал в машине состояний IMAP, а не изображал прозрачную трубу под протоколом.

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

Повторение делало историю ценной

IMAP предоставлял удобный материал. Клиент повторял небольшой набор глаголов. Сервер повторял формы ответов и названия заголовков. Сообщения одной ветки цитировали прежний текст. Нарастающая история заменяла повторные последовательности короткими ссылками.

Вложения нарушали рисунок. Уже сжатый архив или JPEG мог почти не уменьшиться, вытеснить полезные шаблоны IMAP из словаря и потратить процессор на данные, которые не повторятся. Спецификация обсуждала полный сброс вокруг крупных литералов и снижение усилия для предположительно несжимаемых форматов. Это были локальные решения, не команды протокола.

Близость к приложению создавала преимущество. Оно знало, что последует: синтаксис, заголовки, текст или литерал. Знание улучшало экономию и одновременно возлагало на приложение ответственность за сохраненный контекст.

Шифрование не уничтожало длину

В 2007 году раздел безопасности RFC 4978 одной фразой отсылал к тогдашним соображениям о сжатии TLS. Изученные позже атаки изменили оценку. CRIME и связанные работы показали, что содержимое может быть зашифровано, а длина оставаться наблюдаемой. Если секрет и управляемый атакующим текст попадают в одну историю, повторные варианты могут показать, когда догадка похожа на секрет.

Случаи, сведенные IETF, относятся к TLS и Вебу. Они не доказывают атаку на IMAP COMPRESS или уязвимость любого сеанса IMAP. Но они показывают, почему фраза «сжать, затем зашифровать» не завершает анализ конфиденциальности.

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

Скрытому состоянию требовался владелец

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

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

Источники и пределы

Формат DEFLATE задает RFC 1951. Capability IMAP, граница, порядок слоев и настройка описаны в RFC 4978. Класс атак суммирует RFC 7457, современное ядро IMAP определяет RFC 9051, текущие советы TLS дает RFC 9325, а capability остается в реестре IMAP IANA. Эти источники не измеряют нынешнее использование и не сообщают о конкретном взломе IMAP COMPRESS.