Вопрос или проблема
Раздел 5.4 спецификации TLS 1.3 описывает заполнение записей.
Один из способов снижения риска BREACH — это добавление случайного заполнения.
Поэтому мне интересно:
- Требует ли TLS 1.3 случайное заполнение записей? Я также не совсем понимаю, является ли это заполнение обязательным или необязательным, и всегда ли оно случайное.
- Если заполнение записей TLS 1.3 осуществляется случайным образом, прав ли я, думая, что это уменьшает риски BREACH?
Если на оба этих вопроса ответить положительно, я полагаю, что это означает, что любой сайт, использующий TLS 1.3 (и не поддерживающий более ранние версии SSL/TLS), не будет уязвим для BREACH.
Эта статья, в разделе BREACH, довольно хорошо подводит итоги.
BREACH нацеливается на
HTTPсжатие, а не наTLSсжатие.
С учетом сказанного, случайное заполнение записей можно сделать на более высоком уровне инкапсуляции, а не на самом TLS записи. Вы не хотите скрывать длину записи, а скрывать весь ответ.
Вот предупреждающие меры, упомянутые в вышеупомянутом посте,
- Отключите
HTTPсжатие - Разделите секреты от пользовательского ввода (эти секреты могут быть использованы как CSRF токен)
- Случайных секретов по запросу
- Замаскируйте секреты (эффективно рандомизируя путем
XORс случайным секретом на каждом запросе) - Защитите страницы от CSRF
- Скрывайте длину (добавляя случайные числа байтов к ответам)
- Ограничьте скорость запросов
Требует ли TLS 1.3 случайное заполнение записей?
RFC 8446 – Протокол безопасности транспортного уровня (TLS) версии 1.3 говорит, что это не требуется:
реализации могут выбрать заполнение.
На практике заполнение, похоже, не используется часто. Я проверил размер сообщения с помощью Wireshark, отправляя форму на сайт с TLS 1.3 через Chrome, и размер зашифрованного сообщения соответствует размеру открытого сообщения.
Таким образом, заполнение фактически не используется и, следовательно, не снижает риски BREACH.
Если случайное заполнение записей TLS 1.3 осуществляется, прав ли я, думая, что это снижает риски BREACH?
Это не делает его невозможным теоретически, но, возможно, невозможным на практике. В общем, возможно усреднить заполнение, выполняя достаточно много запросов. Если заполнение находится в пределах от 0 до 10 байтов, но в среднем составляет 5 байтов, атакующий может выполнить много запросов и вычесть 5, чтобы получить правильный исходный размер.
Если случайное заполнение записей TLS 1.3 осуществляется, прав ли я, думая, что это снижает риски BREACH?
Статья Heal-the-Breach утверждает, что рандомизация размера ответа с добавлением всего лишь 10 байтов достаточно, чтобы значительно усложнить использование BREACH. Это предполагает, что атакующий ищет разницу в размере ответа всего в один байт. Однако с помощью атаки усиления возможно увеличить разницу в размере. Изменяя полезную нагрузку, можно сделать размер ответа различным, например, на 11 байтов между правильным и неправильным предположением, и тогда заполнение в 10 байтов не поможет. Случайное заполнение может быть увеличено, но так же может быть увеличена атака усиления. Таким образом, не очевидно, в какой степени случайное заполнение снижает атаку BREACH.
Ответ или решение
Вопрос: Устраняет ли TLS 1.3 уязвимость BREACH?
Введение
Уязвимость BREACH (Byte Ranging Exploit Against Compression Herz) нацелена на атаки через сжатие HTTP-трафика, а не на сжатие TLS. Эта уязвимость может быть использована злоумышленниками для извлечения конфиденциальных данных, таких как токены сеансов и другие секреты, посылаемые на сервер. Поскольку TLS 1.3 включает механизмы, связанные с дополнением данных (паддинг), важно понять его роль в предотвращении этой уязвимости.
1. Обязателен ли произвольный паддинг в TLS 1.3?
Согласно RFC 8446, некоторые реализации TLS 1.3 могут использовать паддинг. Однако этот механизм не является обязательным. Раздел 5.4 стандарта отмечает, что:
"Implementations MAY choose to pad."
Это означает, что внедрение произвольного паддинга полностью зависит от реализации конкретного клиента или сервера TLS 1.3 и не гарантируется. Поэтому на практике многие реализации могут не использовать произвольный паддинг, что ставит под сомнение его влияние на безопасность.
2. Устраняет ли произвольный паддинг уязвимость BREACH?
Даже если произвольный паддинг будет внедрен, это не гарантирует полной защиты от BREACH. Произвольный паддинг может помочь усложнить атаку, но не сделать её невозможной. Исследование, проведенное в Heal-the-Breach, показывает, что добавление хотя бы 10 дополнительных байт может сделать атаку намного более сложной. Однако существует вероятность, что злоумышленник, выполняя множество попыток атаки, может усреднить длину ответа и выявить конфиденциальные данные.
К тому же, атаки с усилением (amplification attacks) могут позволить злоумышленникам изменять нагрузки так, что разница в размерах ответов может увеличиваться дисторсионным образом. Например, если ответ различается на 11 байт между правильным и неправильным вводом, простой паддинг в 10 байт не будет достаточен для защиты.
Заключение
В резюме, можно сделать вывод, что TLS 1.3 сам по себе не является полноценной защитой от уязвимости BREACH. Хотя он предоставляет возможность использовать произвольный паддинг, его реализация зависит от разработчиков и не является обязывающей. Если же произвольный паддинг применяется, это может затруднить эксплуатацию уязвимости, но не исключает её. Поэтому, для защиты от BREACH следует применять дополнительные меры безопасности, такие как отключение сжатия HTTP и использование других методик, а не полагаться исключительно на параметры TLS 1.3.