Окончание поддержки старого протокола TLS в OpenJDK и Axiom JDK

Окончание поддержки старых протоколов TLS в OpenJDK и Axiom JDK


Июль 15, 2021


TLS 1.0 и 1.1 долгое время были стандартом безопасности, но теперь ситуация изменилась. Если вы давно не обновляли протоколы — время пришло. В этой статье мы обсудим риски, преимущества и обоснованность перехода на современную версию TLS.

Депрекация TLS 1.0 и 1.1

Первые шаги к уходу от устаревших протоколов TLS, были сделаны еще в марте 2019 года, когда IETF отказалась от использования старых версий. Все популярные браузеры прекратили поддержку версий 1.0 и 1.1 в 2020 году, и только 1 % популярных веб-сайтов по-прежнему работает с этими уязвимыми протоколами.

Как мы уже обсуждали, цикл выпуска Axiom JDK ведется с обеспечением максимальной безопасности, поэтому в апрельском релизе использование TLS 1.0 и 1.1 стало отключено по умолчанию. Для этого в свойство jdk.tls.disabledAlgorithms конфигурационного файла java.security были добавлены SSLv3, TLSv1, TLSv1.1.

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \

Мы рекомендуем вам регулярно обновлять веб-приложения, чтобы защитить от атак клиентов и бизнес. Нажмите кнопку ниже и заполните форму, что получить консультацию Axiom JDK — наши инженеры позаботятся о вашей безопасности.

Уязвимости TLS

Ниже перечислены лишь некоторые из атак1, которые можно проводить со старыми версиями TLS.

  • POODLE (Padding Oracle On Downgraded Legacy Encryption) — эта атака изначально использовала только уязвимости протокола SSL 3.0, но в декабре 2014 года было объявлено о новом варианте атаки, использующем недостатки режима шифрования CBC в TLS до версии 1.2. Злоумышленник заставляет клиента использовать старый протокол SSL 3.0 для связи с сервером и, по сути, установить устаревший режим шифрования — сцепление блоков шифротекста (CBC). На момент написания статьи в июле 2021 года около 4 % из 150 000 самых популярных сайтов все еще поддерживали SSL версии 3.0 или ниже и были уязвимы для атак2. Можно предположить, что для менее популярных (и, вероятно, менее защищенных) серверов этот процент только увеличится.

POODLE

  • FREAK (Factoring RSA Export Keys) — это еще один тип атаки MITM («человек посередине»), обманывающий клиента и сервер, чтобы заставить их использовать устаревшие наборы шифров, которые можно взломать всего за несколько часов при помощи современных вычислительных мощностей. Злоумышленник изменяет запрос от клиента, чтобы принудительно использовать 40- или 56-битное шифрование, которое в 90-х было безопасным, но сейчас не работает.

FREAK

  • BEAST (Browser Exploit Against SSL/TLS) был обнаружен еще в 2002 году, но подтверждение правильности концепции было продемонстрировано только в 2011 году. Эта атака основана на внедрении Java-апплета в устройство жертвы и последующей отправке подставных данных на целевой веб-сайт по SSL. Затем злоумышленник выискивает в трафике зашифрованные данные, созданные апплетом, таким образом обнаруживая блок незашифрованного текста.

BEAST

  • CRIME (Compression Ratio Info-leak Made Easy) эксплуатирует алгоритм сжатия в TLS, применяемого для увеличения пропускной способности. Поскольку повторяющиеся последовательности байтов заменяются указателями на первый экземпляр последовательности, злоумышленник может вводить различные символы в cookie жертвы и отслеживать размер ответа. Это позволяет восстановить значение файла cookie.

CRIME

  • Heartbleed — это уязвимость, которая использует расширение Heartbeat OpenSSL. В TLS до версии 1.2 Heartbeat — это метод поддержания соединения путем отправки сообщения на сервер с запросом ответа, содержащего данные клиента и их размер. Фокус в том, что злоумышленник может изменить размер запрошенного ответа, и сервер ответит большими порциями случайных данных из своей памяти, включая, например, закрытый ключ сервера.

Heartbleed

Были ли какие-либо действительно успешные атаки?

Конечно, были. В списке организаций, ставших жертвами этих атак, Канадское налоговое агентство3, сайт для родителей в Великобритании4, большая сеть больниц в США5 и даже почта Yahoo6 — и это лишь некоторые случаи, которые были раскрыты. Никто точно не знает, сколько успешных атак остались незамеченными.

Хотя открытых случаев атак с использованием Java™ нет, крупные компании очень серьезно относятся к этим рискам. Например, в 2011 году Mozilla собиралась запретить использование Java™ в Firefox сразу после того, как была продемонстрирована уязвимость BEAST, хотя Oracle решила проблему с помощью оперативно выпущенного патча7. В устаревших системах всегда присутствует риск внезапного появления новых атак.

Что будет с моими Java-приложениями?

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

Но есть и другая вероятность — что вы работаете с людьми, которые за последние десять лет ни разу не обновляли браузер. Либо же вы поддерживаете клиентское ПО в актуальном состоянии, но по-прежнему полагаетесь на старую добрую серверную программу, написанную в 1999 году. Мы часто рассуждаем так: «Не чини, пока работает».

Однако на этот раз древний код может перестать работать.

Что я могу сделать?

Есть несколько способов решить возможные проблемы.

  1. Вы можете выполнить обновление, а затем снова включить поддержку TLS 1.0 и 1.1 в конфигурации среды исполнения, удалив их из свойства jdk.tls.disabledAlgorithms файла конфигурации java.security. Имейте в виду, что при этом вы принимаете на себя риск столкновения с уязвимостями старых протоколов TLS, описанными ранее, поэтому хорошо подумайте, стоит ли это делать. Вы просто отложите проблему, которой все равно придется заняться в будущем.

  2. Если вы совершенно точно не собираетесь выполнять обновление, можно вручную отключить TLS 1.0 и 1.1 на своем сервере. В файлах конфигурации найдите строки, относящиеся к протоколам (например, server.ssl.enabled-protocols=TLSv1.1, TLSv1.2 в Apache Tomcat), и измените их, чтобы сохранить только безопасные версии TLS. Не забудьте протестировать свой сервер с помощью комплекта инструментов OpenSSL. Выполните следующие команды:

    • openssl s_client -connect localhost:443 -tls1 и openssl s_client -connect localhost:443 -tls1_1

    команда должна выполниться с ошибкой;

    • openssl s_client -connect localhost:443 -tls1_2 и openssl s_client -connect localhost:443 -tls1_3

    команда должна выполниться успешно и вывести информацию о сертификате.

  3. Самое безопасное решение — обновить все ваши приложения на сервере и на стороне клиента, чтобы они были совместимы с новым протоколом TLS. В конце концов, мы повышаем безопасность не просто так. Это потребует больше времени и усилий, но в долгосрочной перспективе вы добьетесь комплексного решения проблем.

Прощай, старый TLS

Итак, следует ли вам работать в устаревшем режиме или пора перестроить свои приложения в соответствии с современными стандартами безопасности? Выбор за вами. Апрельское обновление OpenJDK и Axiom JDK — очередной шаг к прекращению поддержки старого протокола безопасности TLS. Кликните на кнопку ниже, чтобы получить новейшую и самую безопасную версию Axiom JDK.

Ссылки

  1. Примеры уязвимостей TLS и атак
  2. SSL Pulse
  3. Ошибка Heartbleed используется для кражи данных налогоплательщиков
  4. Атаки Heartbleed взломали сайты Mumsnet и Налогового агентства Канады
  5. Отчет: серьезная уязвимость Heartbleed была использована при атаке на больницу
  6. Критическая уязвимость раскрыла данные пользователей Yahoo Mail
  7. Атака на коммуникации, защищенные протоколом TLS
Author image

Олег Чирухин

Директор по коммуникациям с разработчиками (DevRel)

Axiom JDK info@axiomjdk.ru Axiom JDK logo Axiom Committed to Freedom 199 Obvodnogo Kanala Emb. 190020 St. Petersburg RU +7 812-336-35-67 Axiom JDK 199 Obvodnogo Kanala Emb. 190020 St. Petersburg RU +7 812-336-35-67