Comments 18
Странно это всё. Вроде бы очевидным решением было бы отказаться от режима CBC. Если так важна скорость — можно использовать CTR.
UFO just landed and posted this here
В оригинале статьи (в блоге CloudFlare) упомянуто, что CBC используется при 26% клиентских соединений, так что отключать на серверах его поддержку, мягко говоря, ещё рано.
Собственно, о том и статья, что на протяжении двух десятков лет правильно реализовать CBC не удавалось вообще никому, и удалось ли в итоге — ещё непонятно.
не используйте CBC без реальной необходимости, он подвержен oracle padding attack при неправильной реализации.
Собственно, о том и статья, что на протяжении двух десятков лет правильно реализовать CBC не удавалось вообще никому, и удалось ли в итоге — ещё непонятно.
Вот только что эта статья делает в хабе «Oracle»?
Мне кажется что «padding» в данном случае корректнее было бы перевести как «дополнение» а не «набивка».
А слово «дополнение» действительно используется в этом значении в русскоязычной литературе? Google Books, например, ничего подобного не находит.
Подозреваю, что авторы википедии его точно так же выдумали на ровном месте, как я — «набивку».
Лично мне слово «дополнение» не нравится тем, что у него в компьютерных науках устоялось другое значние.
Подозреваю, что авторы википедии его точно так же выдумали на ровном месте, как я — «набивку».
Лично мне слово «дополнение» не нравится тем, что у него в компьютерных науках устоялось другое значние.
Да, дополнение или выравнивание.
Плохо искали. Кстати в той статье на хабре, на которую вы ссылаетесь в первом же абзаце, также используется «дополнение». «Набивка» здесь плохо подходит по смыслу.
Не всё понял из текста… Ну во-первых, непонятно, почему исторически допускалась ситуация, когда сообщение + MAC точно укладываются в целое число блоков, но набивка всё равно зачем-то требовалась. В чём смысл, этого действия, чтобы точно знать, что это конец MAC, а не покорёженная набивка в результате искажения данных при передаче?
И по последней атаке тоже объяснено как-то криво. Во-первых, каким образом в принципе злоумышленник встанет посередине, если браузер проверяет сертификат сервера? Он будет просто транслировать всю передачу данных без изменений в обе стороны, а свои запросы просто отправлять на реальный сервер параллельно с этим?
Окей, но в чём суть «угадывания байтов в POST запросе», ведь злоумышленник сам целиком формирует этот запрос? Или речь про угадывание неких данных, отправленных прямо перед этим запросом, но зашифрованных в рамках того же блока? Тогда у меня вопрос, начинается ли шифрование заново в терминах блоков SSL в момент отправки браузером нового GET/POST запроса.
И по последней атаке тоже объяснено как-то криво. Во-первых, каким образом в принципе злоумышленник встанет посередине, если браузер проверяет сертификат сервера? Он будет просто транслировать всю передачу данных без изменений в обе стороны, а свои запросы просто отправлять на реальный сервер параллельно с этим?
Окей, но в чём суть «угадывания байтов в POST запросе», ведь злоумышленник сам целиком формирует этот запрос? Или речь про угадывание неких данных, отправленных прямо перед этим запросом, но зашифрованных в рамках того же блока? Тогда у меня вопрос, начинается ли шифрование заново в терминах блоков SSL в момент отправки браузером нового GET/POST запроса.
Не всё понял из текста… Ну во-первых, непонятно, почему исторически допускалась ситуация, когда сообщение + MAC точно укладываются в целое число блоков, но набивка всё равно зачем-то требовалась. В чём смысл, этого действия, чтобы точно знать, что это конец MAC, а не покорёженная набивка в результате искажения данных при передаче?
Чтобы точно знать, сколько байтов нужно отрезать с конца после расшифровки и перед проверкой MAC.
И по последней атаке тоже объяснено как-то криво. Во-первых, каким образом в принципе злоумышленник встанет посередине, если браузер проверяет сертификат сервера? Он будет просто транслировать всю передачу данных без изменений в обе стороны, а свои запросы просто отправлять на реальный сервер параллельно с этим?
MitM подменяет только пакеты от клиента к серверу, от сервера к клиенту — оставляет без изменения.
Окей, но в чём суть «угадывания байтов в POST запросе», ведь злоумышленник сам целиком формирует этот запрос?
Злоумышленник формирует путь и тело запроса, но куки в запрос вставляет браузер жертвы.
Ничего не понял, давайте по порядку)
Чтобы точно знать, сколько байтов нужно отрезать с конца после расшифровки и перед проверкой MAC.Зачем? Набивка ведь и так имеет совершенно особый формат. Неужели не очевидна ситуация, когда у неё нулевая длина? Хотя бы исходя из общей длины данных об этом можно «догадаться».
MitM подменяет только пакеты от клиента к серверу, от сервера к клиенту — оставляет без изменения.Тогда логически ответы сервера не сойдутся с ожидаемыми ответами уже на уровне приложения, и обязательно возникнет какой-нибудь сбой, что нарушит сессию в целом и для пользователя сделает очевидным то, что его «прослушивают».
Злоумышленник формирует путь и тело запроса, но куки в запрос вставляет браузер жертвы.Вообще-то, технически, куки может ставить либо браузер напрямую через JS, либо сервер через заголовок Set-Cookie (этот заголовок может подсунуть и злоумышленник). Так кто и на каком этапе ставит куки в данном сценарии? Если я правильно понял, куки ставит сервер в момент успешной авторизации, но потом они отправляются в HTTP заголовке браузером при каждом запросе, и это просто некая постоянная строка, которую мы хотим расшифровать, а изменяя путь, мы просто её «двигаем»?
1) каким бы ни был формат набивки — невозможно N-байтными блоками однозначно представить все строки длиной до N байт включительно, просто потому, что число возможных строк строго больше, чем число возможных блоков.
2) именно сбой HTTPS-сессии и является тем каналом, через который извлекается информация о зашифрованном содержимом запроса.
3) не имеет никакого значения, пришли куки через Set-Cookie или установлены скриптом на стороне клиента, за минуту или за неделю до атаки; воруются (из тела запроса) они одинаково.
2) именно сбой HTTPS-сессии и является тем каналом, через который извлекается информация о зашифрованном содержимом запроса.
3) не имеет никакого значения, пришли куки через Set-Cookie или установлены скриптом на стороне клиента, за минуту или за неделю до атаки; воруются (из тела запроса) они одинаково.
Вообще ничего не понял. Можно ещё раз, по порядку и помедленнее?)
невозможно N-байтными блоками однозначно представить все строки длиной до N байт включительноВ смысле?
именно сбой HTTPS-сессии и является тем каналом, через который извлекается информация о зашифрованном содержимом запроса.Там будет сбой не HTTPS сессии, а именно логический. Ну вот представьте: клиентский код «думает», что отправил один запрос, а сервер отвечает на другой (после модификации). Где гарантия, что не получится фейл из-за несоответствия реального результата ожидаемому?
1) Представьте, что блок заканчивается на нулевой байт. Как определить, это единственный байт набивки, или же последний байт данных?
2) Какого рода «фейл» вы имеете в виду, если не сбой сессии?
2) Какого рода «фейл» вы имеете в виду, если не сбой сессии?
1) Для таких случаев обычно вводят поле длины полезной нагрузки, чтобы однозначно понять, где кончаются данные. В целом я понял свою ошибку, положившись на паттерн набивки, мы автоматически запретим заканчивать сообщение таким же паттерном - обычно это никому не нужно, но так делать не есть хорошо.
2) Будет сбой авторизации, только не на уровне SSL, а на уровне протокола приложения - сервер вернёт ошибку 403 при получении неверного токена из клиентской куки.
Sign up to leave a comment.
Padding Oracle Attack: криптография по-прежнему пугает