Почему POODLE Attack влияет только после перехода на SSL 3.0?

Question

Мне интересно, какие изменения с SSL 3.0 на TLS 1.0 точно исправили атаку POODLE. Основой для этой атаки является блок сообщений M1||MAC||PAD, поэтому для MAC и заполнения используется целый блок.

У меня есть идея, что это больше не работает (без понижения), потому что в TLS 1.0, если последний блок заполнен, это 0x101010... (с размером блока 16), а не 0xXX...XX10 (XX= случайный), так что гораздо тяжелее угадать 16 байтов напрямую, а не только последний байт.

Но есть ли другие параметры безопасности, которые исправили эту проблему, или я упомянул это правильно? Как конец сообщений больше не || MAC || PAD? Или ПАП может быть подписан или что-то в этом роде?

С уважением Джулиан

Answer 1

SSL 3.0 и TLS 1.0 отличаются тем, как они обрабатывают заполнение.

См. https://www.openssl.org/~bodo/ssl-poodle.pdf и этот раздел:

Наиболее серьезная проблема шифрования CBC в SSL 3.0 заключается в том, что его заполнение блочного шифра не является детерминированным и не охватывается MAC (код аутентификации сообщения): таким образом, целостность заполнения не может быть полностью проверена при расшифровке. Заполнение байтами от 1 до L (где L - размер блока в байтах) используется для получения целого числа блоков перед выполнением блочного шифрования CBC (цепочка шифрблока). Слабость легче всего использовать, если существует целый блок заполнения, который (до шифрования) состоит из произвольных байтов L-1, за которыми следует один байт значения L-1.

Сообщения в TLS1.0 по-прежнему структурированы, см. Эту структуру из RFC 2246:

   block-ciphered struct {
       opaque content[TLSCompressed.length];
       opaque MAC[CipherSpec.hash_size];
       uint8 padding[GenericBlockCipher.padding_length];
       uint8 padding_length;
   } GenericBlockCipher;

Заполнение определяется так:

Каждый uint8 в векторе данных заполнения должен быть заполнен значением длины заполнения.

Это принципиальное различие между SSL 3.0 и TLS 1.0 в этом отношении, которое позволяет получателю проверять правильность заполнения и фактически не быть остатком действительных блоков данных приложения.

(сравните https://tools.ietf.org/html/rfc6101 для SSL 3.0 с https://tools.ietf.org/html/rfc2246.html для TLS 1.0)

Это также объясняется на https://www.imperialviolet.org/2014/10/14/poodle.html следующим образом:

Рассмотрим следующий незашифрованный HTTP-запрос, который я разбил на 8-байтовые блоки (как в 3DES), но та же идея работает и для 16-байтовых блоков (как в AES):

[GET / HT] [TP/1.1\r\n] [Cookie:] [abcdefgh] [\r\n\r\nxxxx] [MAC DATA] [•••••••7]

Последний блок содержит семь байтов заполнения (представленных как •), а последний байт - это длина заполнения.

[..]

Злоумышленник не может видеть содержимое открытого текста, как мы можем видеть на диаграмме выше. Они видят только зашифрованные CBC блоки зашифрованного текста. Но что произойдет, если злоумышленник дублирует блок, содержащий данные cookie, и перезапишет последний блок с ним? Когда получатель расшифровывает последний блок, он XOR в содержимом предыдущего зашифрованного текста (который знает злоумышленник) и проверяет подлинность данных. Важно отметить, что поскольку SSLv3 не определяет содержимое байтов заполнения (•), получатель не может их проверить. Таким образом, запись будет принята, если и только если последний байт заканчивается как семёрка.

И позже:

Критическая часть этой атаки заключается в том, что SSLv3 не определяет содержимое байтов заполнения (s). TLS делает, и поэтому эта атака не работает, потому что у атакующего есть только 2^-64 или 2^-128 шансов, что дублированный блок будет допустимым блоком заполнения.