Окончание поддержки старых протоколов 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

Ниже перечислены лишь некоторые из атак¹, которые можно проводить со старыми версиями 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 или ниже и были уязвимы для атак². Можно предположить, что для менее популярных (и, вероятно, менее защищенных) серверов этот процент только увеличится.

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

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

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

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

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

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

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

Что будет с моими 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