ssl данные приложения нулевые байты миф

Question

Недавно я проанализировал несколько пакетов приложений SSL/TLS, и я обнаружил, что довольно интересно, что некоторые пакеты начинаются с фиксированных 7 нулевых байтов в самом начале пакета данных приложения SSL/TLS.

TLS 1.2 application data example 1

TLS 1.2 application data example 2

Я не знаю, почему это происходит? Интуитивно зашифрованное сообщение должно быть случайным байтом.

Answer 1

7 ведущих 0 в каждом пакете SSL означают, что вряд ли это будут зашифрованные данные SSL. Должно быть некоторое запутывание, или это только скрытый канал данных в потоках/кусках SSL.

Answer 2

Я думаю, что это особенность, характерная для режима счетчика Галуа. Что Wireshark называет «Зашифрованные Application Data» в этом случае GenericAEADCipher, который определен в RFC 5246, section 6.2.3.3 и начинается с:

opaque nonce_explicit[SecurityParameters.record_iv_length]; 

RFC 5288, section 3 описывает это поле для GCM:

Каждое значение nonce_explicit ДОЛЖЕН быть разным для каждого отдельного вызова функции шифрования GCM для любого фиксированного ключа. Отказ соответствует этому требованию уникальности может значительно ухудшить безопасность. Необязательный номер не может быть 64-разрядным порядковым номером.

Носитель не обязательно должен быть случайным или непредсказуемым - но он абсолютно должен быть уникальным (см. Также this answer). Использование номера последовательности записей TLS (а не порядкового номера TCP!) Является хорошим способом обеспечения уникальности в одном соединении, и поэтому NSS, например, следует этой рекомендации (см. lib/ssl/ssl3con.c, строки 2148-2167 и 2994-3016 в NSS 3.27 0,1).

Итак, в начале нового TLS-соединения этот nonce будет просто связкой нулей. Обратите внимание, что на втором скриншоте последний байт уже 01 - предположительно, это вторая запись в соединении.