Кратко

  • TLS 1.3 совместно защищает содержимое, ненулевой внутренний тип и завершающие нули padding. Отправитель выбирает добавку, получатель проверяет и удаляет её до передачи данных приложению. Представление не получает прикладного смысла.
  • Захват доказывает длину шифротекста, направление и время. Он не отделяет данные, тип, padding и накладные расходы AEAD. Большая запись сама по себе не доказывает большое прикладное сообщение.
  • Padding укрупняет размерные отпечатки и создаёт фоновый трафик, но не устраняет время, количество записей, ответы, сегментацию и обработку. Нужны значения endpoint, версия политики, согласованные лимиты и отрицательные тесты.

Правильное число получило лишние полномочия

Разница двух исходящих записей составляла 512 байт. Большая запись совпала по времени с чувствительной операцией, поэтому разницу назвали телом запроса и доказательством пользовательского действия.

Endpoint сохранил недостающий факт: callback добавлял нули до следующей границы блока, а в паузах компонент мог создавать Application Data с пустым содержимым. Байты реально занимали канал, но не все принадлежали пользователю.

Ошибка заключалась не в датчике. Сетевому доказательству поручили определить семантику за невидимой ему границей.

Граница TLSInnerPlaintext

TLSInnerPlaintext содержит данные, затем ненулевой ContentType, затем нули. Вся структура шифруется и аутентифицируется. Внешний тип выглядит как Application Data и не раскрывает внутренний.

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

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

У фонового трафика узкая грамматика

Application Data может иметь нулевое содержимое. Отправитель способен создать правдоподобную защищённую запись в период отсутствия прикладных байт. Видимая передача больше не равна действию.

Handshake и Alert не могут быть пустыми и лишь заполненными нулями. Размер не создаёт сообщение протокола; получатель обязан отказать.

Фоновая запись также не гарантирует приватность. Ответ, задержка, серия пакетов или закрытие могут выдать реальную работу. Ослабляется один сигнал, а не вся совокупность.

Нули входят в лимит

Максимум включает данные, внутренний тип и padding. Полученный record_size_limit ограничивает полный TLSInnerPlaintext.

Запрос добавить 1024 байта не гарантирует результат. Данные уже занимают место; реализация может урезать добавку или иначе фрагментировать. OpenSSL ограничивает padding доступным максимумом.

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

Наличие механизма не доказывает активную политику

Текущая спецификация TLS 1.3 определяет кодирование и проверку, но не универсальный блок или частоту фона. Приложение может лучше знать чувствительные границы; за шифрованные Handshake и Alert отвечает TLS.

OpenSSL по умолчанию не добавляет padding. Он предлагает блок или callback перед шифрованием каждой исходящей записи, отдельно для Application Data и Handshake/Alert. Callback может исключить kernel TLS.

GnuTLS позволяет задавать добавку при отправке и проверять поддержку сокрытия длины. API и запись IANA доказывают возможность, но не включение, фактическую длину или эффект.

Постоянное время одной библиотеки не решает задачу

Удаление нулей может зависеть по времени от их числа. GNUTLS_SAFE_PADDING_CHECK уменьшает этот канал ценой производительности.

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

Поэтому TLS не обещает полной защиты от анализа трафика. Более сильная гарантия требует верхних слоёв, дополнительного объёма и задержки. «Padding включён» — состояние функции, не итог приватности.

Композиция выбирает слой

EAP-TLS 1.3 рекомендует padding записей для снижения утечки размера сертификатов. ECH отдельно округляет внутренний ClientHello и указывает на последующие шифрованные Handshake с чувствительными длинами. Сначала определяется защищаемый признак.

HTTP/3 разделяет прикладные, зарезервированные и транспортные способы. QUIC использует сообщения handshake TLS, но не переносит обычные TLS records. TLS callback не доказывает padding пакета QUIC.

Integrity-only suites дают контрпример: нули могут быть защищены от изменения, но без шифрования не скрывают длину plaintext. Сами нули конфиденциальности не создают.

Что вправе утверждать наблюдатель

Пассивный захват доказывает endpoints, направление, время, длину шифротекста, пакетизацию и повтор. Внутренний тип, содержимое, padding и смысл он напрямую не видит.

Корректная фраза: «endpoint отправил N защищённых октетов в T». Лог endpoint добавляет: «получил C, применил policy P версии V, добавил Z, получил внутреннюю длину I и ciphertext N при лимите L».

Без соединения этих записей распределение поддерживает гипотезу, но не действие пользователя, размер объекта или команду.

Доказательный журнал

Сохраняйте соединение, направление, sequence, версию TLS, режим защиты, внутренний тип, данные до padding, запрошенную и применённую добавку, внутреннюю и внешнюю длину, лимит, фрагментацию, версию библиотеки, kernel TLS и версию policy.

Измеряйте полосу, задержку, CPU, классы размеров, корреляцию ответов и долю фона. Разделяйте Application Data и Handshake/Alert.

Проверяйте отказ для plaintext из одних нулей, пустых Handshake/Alert, чрезмерного запроса и превышения лимита. После rollback докажите исчезновение callback и характерного распределения.

Решающее поле сеть не видит: длину содержимого до padding. Без неё видимая длина остаётся сетевым доказательством, а не прикладными полномочиями.

Источники