Криптография глазами злоумышленника: как перехватывают ваш HTTPS

📋 Кратко

HTTPS не гарантирует абсолютную защиту. Злоумышленники используют MITM-атаки, компрометацию центров сертификации, уязвимости TLS (например, CVE-2024-26582) и социальную инженерию. Разбираем, как работают эти методы и какие меры защиты действительно эффективны: HSTS, Certificate Pinning, TLS 1.3 и правильная проверка сертификатов.

⏱ 5 минут чтения│сложность
Иллюзия безопасности: злоумышленник проникает сквозь HTTPS-шифрование.
Иллюзия безопасности: злоумышленник проникает сквозь HTTPS-шифрование.

🔍 Как работает HTTPS и где его слабые места

HTTPS — это не просто «замочек» в адресной строке. Это комбинация протоколов HTTP и TLS (ранее SSL), которая шифрует данные между браузером и сервером. Однако шифрование не делает канал неуязвимым. Оно лишь гарантирует, что перехваченные данные нельзя прочитать без ключа. Но сам процесс установления защищённого соединения — рукопожатие TLS — содержит несколько этапов, которые атакующий может атаковать.

Человек посередине: перехват данных между клиентом и сервером.
Человек посередине: перехват данных между клиентом и сервером.

Главная уязвимость HTTPS — это доверие к центрам сертификации (CA). Любой CA может выпустить сертификат на любой домен. Если злоумышленник получает контроль над CA или использует скомпрометированный корневой сертификат (например, через вредоносное ПО), он может создать поддельный сертификат для любого сайта. Браузер пользователя не заметит подмены, если в системе установлен корневой сертификат атакующего. Именно так работают корпоративные MITM-прокси и некоторые виды фишинга.

Ключевой момент: HTTPS защищает данные в пути, но не защищает от атак на сам процесс установления соединения. Доверие к CA — самое слабое звено.

🛠️ MITM-атаки: перехват на уровне сети

Атака «человек посередине» (MITM) — классический способ перехвата HTTPS. Злоумышленник внедряется между клиентом и сервером, например, через подмену ARP-таблиц в локальной сети, поддельные точки доступа Wi-Fi или перехват DNS-запросов. После этого он может выдать себя за сервер, используя поддельный сертификат.

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

Для успешной MITM-атаки требуется, чтобы клиент принял поддельный сертификат. Это возможно, если:

  • В системе установлен корневой сертификат злоумышленника (например, через вредоносное ПО или административную политику).
  • Браузер не проверяет сертификат должным образом (устаревшие версии или отключённые проверки).
  • Пользователь игнорирует предупреждение о недействительном сертификате.

В корпоративных сетях MITM-прокси (например, для фильтрации трафика) часто устанавливают собственный корневой сертификат на все устройства. Это легальный сценарий, но он создаёт точку компрометации: если злоумышленник получает доступ к такому прокси, он может перехватывать весь трафик.

⚠️ Компрометация центра сертификации (CA)

История знает несколько громких случаев взлома CA. Один из самых известных — DigiNotar в 2011 году, когда злоумышленники выпустили поддельные сертификаты для Google, Yahoo и других доменов. В результате трафик пользователей в Иране был перехвачен. Хотя это событие произошло давно, урок остаётся актуальным: любой CA может быть скомпрометирован.

Устаревшие протоколы TLS рассыпаются под натиском известных уязвимостей.
Устаревшие протоколы TLS рассыпаются под натиском известных уязвимостей.

Сегодня механизмы проверки сертификатов стали жёстче. Браузеры используют Certificate Transparency (CT) — публичные логи всех выпущенных сертификатов. Если сертификат не зарегистрирован в CT-логе, браузер может отклонить его. Однако атаки на CA по-прежнему возможны, особенно через социальную инженерию или уязвимости в инфраструктуре CA.

Реальная угроза: В 2023 году исследователи обнаружили, что некоторые CA неправильно проверяют права на домен при выпуске сертификатов, что позволяет злоумышленникам получить сертификаты на чужие домены (CVE-2023-28045 — пример плохой практики в Dell CloudIQ).

📉 Уязвимости TLS: от POODLE до race conditions в ядре

Сам протокол TLS не идеален. За годы были найдены десятки уязвимостей: POODLE (CVE-2014-3566), BEAST, Heartbleed (CVE-2014-0160). Большинство из них уже исправлены, но старые версии TLS (1.0, 1.1) всё ещё используются на некоторых серверах. Кроме того, ошибки реализации TLS в операционных системах и библиотеках открывают новые векторы.

HSTS и certificate pinning отражают атаки перехвата сертификатов.
HSTS и certificate pinning отражают атаки перехвата сертификатов.

Одна из свежих — CVE-2024-26582, CVE-2024-26583, CVE-2024-26584, CVE-2024-26585 — серия уязвимостей use-after-free и race conditions в реализации TLS в ядре Linux. Они позволяют локальному атакующему повысить привилегии или вызвать отказ в обслуживании. Хотя эти уязвимости требуют локального доступа, они показывают, что даже на уровне ядра могут быть ошибки, нарушающие безопасность TLS.

Другой пример — CVE-2021-46911, также use-after-free в TLS ядра. Такие баги могут быть использованы в цепочке атак для перехвата трафика, если злоумышленник уже имеет некоторый доступ к системе.

Важно: Уязвимости TLS не всегда позволяют расшифровать трафик напрямую, но они могут дать атакующему контроль над процессом шифрования или ключами.

🎯 Атаки на TLS-рукопожатие и понижение версии

Злоумышленник может попытаться понизить версию TLS между клиентом и сервером до более старой и уязвимой. Например, если сервер поддерживает TLS 1.0, атакующий может заблокировать предложение клиента использовать TLS 1.3 и заставить установить соединение по TLS 1.0, который подвержен атакам BEAST и POODLE.

Perfect Forward Secrecy: прошлые сессии защищены даже при компрометации ключа.
Perfect Forward Secrecy: прошлые сессии защищены даже при компрометации ключа.

Для защиты от понижения версии в TLS 1.3 предусмотрен механизм downgrade protection: сервер и клиент обмениваются специальными метками, которые атакующий не может подделать. Однако старые серверы без поддержки TLS 1.3 остаются уязвимыми.

Также существуют атаки на обмен ключами, например, Logjam (CVE-2015-4000) на Diffie-Hellman с малыми группами. Современные реализации используют безопасные кривые (Curve25519) или фиксированные группы, но некоторые серверы всё ещё поддерживают устаревшие параметры.

🛡️ HSTS и Certificate Pinning: защита от подмены сертификатов

HTTP Strict Transport Security (HSTS) — это заголовок, который сервер отправляет браузеру, указывая, что все последующие соединения должны быть только по HTTPS. Если злоумышленник пытается перехватить первый запрос (до получения HSTS), он может провести атаку SSLstrip — подменить HTTPS на HTTP. HSTS предотвращает это, но только после первого визита на сайт.

Certificate Pinning — это привязка сертификата или публичного ключа к домену. Браузер запоминает, какой сертификат должен быть у сайта, и отклоняет любые другие, даже если они подписаны доверенным CA. Однако механизм сложен в реализации и может привести к блокировке сайта при смене сертификата. Современная альтернатива — Certificate Transparency и требования к валидации сертификатов.

Для пользователей самый надёжный способ — вручную проверять сертификат при подозрительных ситуациях. Но в реальности это делают единицы.

🔒 Современные протоколы: TLS 1.3 и его преимущества

TLS 1.3, стандартизированный в 2018 году, устранил множество уязвимостей предыдущих версий. Он сократил количество шагов рукопожатия, убрал поддержку устаревших алгоритмов (RC4, 3DES, CBC-режимы), ввёл обязательное использование Perfect Forward Secrecy (PFS) через ECDHE. Благодаря PFS даже в случае компрометации долговременного ключа сервера прошлые сессии остаются защищёнными.

Тем не менее, TLS 1.3 не защищает от MITM-атак, если злоумышленник контролирует корневой сертификат на стороне клиента. Он также не решает проблему компрометации CA. Однако он значительно усложняет пассивный перехват и расшифровку трафика.

По данным SSL Labs, на август 2026 года около 80% серверов поддерживают TLS 1.3. Однако многие корпоративные системы и устаревшие устройства всё ещё используют TLS 1.2 или даже 1.0. Это создаёт поверхность атаки.

📋 Практические рекомендации для пользователей и администраторов

Для пользователей:

  • Всегда проверяйте адресную строку: HTTPS и правильное имя домена. Не игнорируйте предупреждения браузера о сертификате.
  • Не устанавливайте корневые сертификаты из непроверенных источников. Особенно это касается корпоративных устройств — убедитесь, что политика безопасности оправдана.
  • Используйте современные браузеры с актуальными обновлениями — они включают проверки CT и HSTS preload.
  • Избегайте публичных Wi-Fi без VPN (но не для обхода блокировок, а для шифрования трафика поверх HTTPS). Однако помните, что VPN-сервисы сами могут быть точкой перехвата.

Для администраторов:

  • Отключите поддержку TLS 1.0 и 1.1 на серверах. Используйте только TLS 1.2 и 1.3.
  • Настройте HSTS с preload и отправляйте заголовок Strict-Transport-Security.
  • Используйте Certificate Transparency (CT) для мониторинга выпущенных сертификатов на ваш домен.
  • Регулярно обновляйте TLS-библиотеки и операционную систему для устранения известных CVE.
  • Рассмотрите внедрение мультифакторной аутентификации и других мер, не полагаясь только на HTTPS.
Чек-лист защиты от перехвата HTTPS: 1) TLS 1.3 только; 2) HSTS preload; 3) Certificate Transparency; 4) Pinning (осторожно); 5) Обновления TLS-стека; 6) Обучение пользователей.

📚 Читайте также

📖 Термины

Ransomware · Сетевой трафик · Фишинг · Шифрование

🔗 Источники