This article is an automated machine-translation of an article in English. We know the translation isn't perfect, but we hope it's useful for people who don't read English.

HTTPS "трещины" Boffins шифрования в Лаки Тринадцать атаке

Filed Under: Featured, Privacy, Web Browsers

Безопасность онлайн-транзакций снова в центре внимания как пара криптографов Великобритании нацелиться на TLS.

TLS, или Transport Layer Security, является преемником SSL, или Secure Sockets Layer.

Это система, которая ставит S в HTTPS (это замка вы видите на безопасных веб-сайтов), а также обеспечивает безопасность для многих других протоколов, тоже.

Как и 2011 печально известной атаки BEAST , у нее есть имя Groovy: Лаки тринадцать .

Название происходит от того, что зашифрованные пакеты TLS есть тринадцать байт заголовка, которые потребляются в одном из криптографических вычислений, на которых основывается TLS.

→ название документа является немного нахальный - авторы криво отмечают, что "в некотором смысле, тринадцать повезло, но двенадцать были бы удачливее", так как 12-байт заголовка бы их атаки еще более эффективной.

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

Авторы работы заметили, что зашифрованные пакеты в большинстве сессий TLS:

  • Зашифрованные с помощью безопасной блочный шифр, как правило, AES в режиме CBC, чтобы сохранить содержимое тайны.
  • Включите сильной криптографической контрольной суммы, как правило, HMAC-SHA1, чтобы не допустить ошибок и подделок.

Можно предположить, что использование не одного, а двух сильных криптографических примитивов неизбежно повысить безопасность, но криптографов не думаю, что путь.

Nadhem Alfardan и Кеннет Паттерсон из Royal Holloway, известный центр информационных исследований в области безопасности, который является частью Лондонского университета, понял, что они могли бы использовать эти две функции безопасности друг против друга, потому что, как они объединяются в TLS.

Значительно упрощен, атака опирается на следующую информацию:

  • Шифром AES шифрование блока 16 байт за один раз. Пакеты данных, которые не являются кратными 16 байт должны быть дополнены, пока они находятся.
  • Контрольные суммы TLS пакета хранятся внутри шифрования слой, после исходных данных, но до любого необходимого дополнения.

Когда сервер TLS получает пакет, который HMAC-SHA1 контрольная сумма и AES-зашифрованную CBS, он должен проверить его, как это:

  • Расшифровка полученных данных, которая должна быть кратной 16 байт в длину.
  • Выявление любых обивка в конце расшифрованные буфера, и лишить его.
  • Удалить последние 20 байта (длина HMAC-SHA1 контрольная сумма) и хранить ее для справки.
  • Вычислить HMAC-SHA1, что осталось в буфере (менее заполнения и ведения контрольной суммы).

Если вычисленное HMAC-SHA1 контрольная сумма не совпадает контрольная сумма ссылки, то была ошибка или подлог. Сервер посылает обратно сообщение об ошибке и завершить соединение.

Теперь представьте, что вы MiTM, или человек-в-середине. Вы не можете расшифровки и повторного шифрования пакетов, как они пролетают мимо, но можно перехватить их, сократить их, изменять их тонко, и передать измененные версии.

Каждый раз, когда вы сделаете это, вы будете нарушать сессии TLS вы атакуете, но вы можете сделать это таким образом, что может просто утечка информации о том, что было внутри теперь сломанный сессии.

Это не будет сразу же дать вам драгоценности короны, но если вы можете извлечь что-либо из зашифрованного потока данных, вы нарушили неприкосновенность криптографических TLS, что должно обеспечить.

Хитрость заключается в том, что когда вы обрезать зашифрованный пакет, есть шанс, что текст в конце отрубленными поток данных будет выглядеть как своего рода обивка байт, которые TLS добавил бы, если исходные данные были короче, чтобы начать с .

В этом случае сервер TLS будет сдирать, что он считает обивка, извлечь то, что он считает контрольную сумму пакета, а затем убедитесь, что контрольная сумма соответствует.

Контрольная сумма не совпадает, конечно, но вы не заботитесь об этом.

То, что вы заботитесь о том, как долго сервер TLS требует, чтобы ответить с сообщением об ошибке, когда он понимает, пакет является недопустимым.

Из-за способа, что HMAC-SHA1 работы, она занимает четыре единицы процессорного времени контрольная сумма первых 55 байт данных, а также дополнительные единицу времени за каждый дополнительный кусок байт 64 (или его части в конце).

Авторы поняли, что, сделав два байта настроить на часть зашифрованного пакета и усечения, они были шансы примерно один из 65000, что сервер будет в конечном итоге ошибочно думать, что сообщение было дополнено, лишая обивка и контрольной суммы, что было осталось.

Если код TLS сервер был тщательно разработан, чтобы потреблять то же количество времени, независимо от содержания расшифрованных пакетов, это займет четыре пятых время обработки untweaked пакет.

Это произойдет потому, что оптимальной пакет обманул сервер в контрольной суммы 55 байт или меньше данных, а не 56 или больше.

Если бы исследователи могли надежно измерять ускорение по этому времени, как быстро ошибке ответа сервера вернулся, то на основе настройки, они могут теперь вычислить два байта исходного пакета.

По систематически пытается все возможное двухбайтовой хитрости (2 16, или 65536 из них), и при условии идеального измерения времени, они могут гарантировать, чтобы извлечь два зашифрованных байт.

После того как эти первые два байта трещинами, еще 14 байт может быть взломана, один байт в то время, пытаясь все 256 возможных настроек каждого байта, в общей сложности "настроить стоимость" 2 16 + 14x2 8.

И это Лаки Тринадцать атаки, в гротескно краткие оперативные, если не теоретический, условиях.

Это не страшно практические атаки, не в последнюю очередь потому, что идеальное измерение времени невозможно:

  • Каждая попытка настроить приводит к сессии TLS прекратить, которые могут быть как заметное и отнимает много времени.
  • Каждый оптимальной сессии должен иметь тот же текст в том же месте пакет для настройки, чтобы сделать исчерпывающе.
  • Авторы необходимы 2 7 повторений исчерпывающий набор настроек 2 16 (это восемь миллионов безнадежный сессии TLS!) Производить достаточно статистически значимой временные данные для надежного результата.

Да, и это было в идеальных условиях сети, с клиентами TLS, сервер и MiTM компьютера в той же выделенной локальной сети.

Тем не менее, это важный результат, поскольку, как уже упоминалось выше, прокалывает некоторых криптографических святости, что TLS должно обеспечивать.

Решения и смягчение, которое дизайнеры будущих протоколов может иметь в виду, включают в себя:

  • Разработать и написать свой код таким образом, это не заметно быстрее или медленнее, когда происходят ошибки, даже если это означает выполнение избыточных вычислений.
  • Используйте потоковый шифр, а не блочный шифр, чтобы избежать необходимости для заполнения текстом.
  • Контрольная сумма данных после шифрования, а не шифрования контрольной суммы. Это гарантирует, что количество данных, контрольная сумма не зависит от текста.
  • Использование проверки подлинности алгоритм шифрования, как AES-GCM , который сочетает в себе контрольные суммы и шифрование.

Интересно, что последний перечисленных выше смягчения (использование проверки подлинности шифрования) уже поддерживается в TLS версии 1.2, которая вышла почти пять лет назад .

К сожалению, как отмечают авторы Лаки Тринадцать из точки, TLS 1.2 все еще "пока широко не используется в реализациях".

В соответствии с SSL-Pulse проекта, меньше, чем 12% веб-сайты, опрошенных в январе 2013 года поддерживают TLS 1.2, и большинство браузеров (IE на Windows 7 и 8 является заметным исключением) не включайте его, либо.

Наверное, пора двигаться вперед!

You might like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog