Сжатие + шифрование динамического контента

Всем известно, что дыры работают в этих ваших комплюхтерах.
Даже интернет-банки, даже ЛОР, лол. Всем настолько пофиг?

https://blog.qualys.com/ssllabs/2013/08/07/defending-against-the-breach-attack можно мешать с случайными данными и атака не получится.

Ещё gzip можно использовать выборочно и где передаются токены и пользовательские данные там не использовать его.

BREACH - это же не только CSRF-токены. Всю страницу со случайными данными не смешаешь.

Можно рандомизировать длину ответа, добавляя случайные данные, но кто-то так делает?

А ещё по ссылке «эксперты по безопасности» предлагают бороться с BREAH, запрещая указывать в запросе произвольный referer. Подобное вообще забавляет. Примерно как поставить запертые ворота посреди пустыни и гордиться, что никто через них не пройдёт. Другие «эксперты», например, утверждали, что для борьбы с BREACH достаточно использовать same-site cookies. Ибо BREACH, помимо всего прочего, облегчает CSRF. А same-site cookies, как известно, решают проблему CSRF. Поэтому они решают проблему BREACH. Логека.

Например, на ЛОРе в каждой HTTP-странице передаются пользовательские данные. Этот пост - тоже пользовательские данные.

BEAST - 2011 год
CRIME - 2012 год

Эти давно не актуальны, разве что где-то из принципа с 2012 года никаких обновлений не накатывали.

А ещё по ссылке «эксперты по безопасности» предлагают бороться с BREAH, запрещая указывать в запросе произвольный referer.

Как это? По ссылке не ходил, но вроде бороться должно помогать отключение сжатия вообще везде при отсутствии реферера, или реферере со стороны. Как с реализацией не знаю, но кажется на это забили.

Дыры в SSL/TLS из-за использования сжатия перед шифрованием:

Это не дыры, а дырищи, значит. Сжатие не должно влиять не стойкость шифрования. Если влияет, то грош цена такому шифрованию.

PoC или гтфо.

Ну так заголовки не сжимаются и так

Не вопрос. 0.1 BTC на 3N8a715KhjjQXnCo5j4NBaLDt2A9Pg32QL.