На криптоаудите API финтех-сервиса я нашёл TLS 1.0 с RC4 на трёх внутренних эндпоинтах - межсервисное взаимодействие, не обновлявшееся с 2018 года, потому что "не смотрит наружу". Через полтора месяца после исправления команда threat intelligence зафиксировала на сетевом оборудовании артефакты перехвата и записи трафика - классический Harvest Now, Decrypt Later. RC4 ломают уже классическими методами, тут и квантовый компьютер не нужен. А RSA-2048 на внешнем периметре - вопрос ближайшего десятилетия. Постквантовая криптография в пентесте 2026 года обязана учитывать оба горизонта: алгоритмы, которые дырявые прямо сейчас, и те, что станут мишенью с приходом квантовых вычислений.
Harvest Now, Decrypt Later и тестирование криптографической устойчивости
Harvest Now, Decrypt Later (HNDL) - главный аргумент в пользу немедленного криптоаудита приложений. Злоумышленник перехватывает зашифрованный трафик сейчас, складирует его и ждёт момента, когда квантовый компьютер позволит расшифровать захваченное. Формально сценарий HNDL не покрыт MITRE ATT&CK Enterprise, но ближайшие аналоги - Network Sniffing (T1040) при доступе к сетевому сегменту и Adversary-in-the-Middle (T1557) при активном перехвате с downgrade.По данным NIST, полная миграция криптографической инфраструктуры занимает от 10 до 20 лет с момента стандартизации нового алгоритма. В 2024 году NIST выпустил первые три финализированных постквантовых стандарта: FIPS 203 (ML-KEM, ранее CRYSTALS-Kyber - механизм инкапсуляции ключей), FIPS 204 (ML-DSA, ранее CRYSTALS-Dilithium - цифровые подписи) и FIPS 205 (SLH-DSA - хеш-базированные подписи). Согласно NIST IR 8547 (draft, ноябрь 2024), асимметричные алгоритмы уровня 112-bit security (RSA-2048, ECDSA P-256) должны быть deprecated после 2030 года и disallowed после 2035 в федеральных системах. Симметричные шифры (AES-256) этим таймлайном не затронуты.
Формула Моски (Mosca's theorem) переводит это в риск-метрику: если время миграции (X) плюс период обязательной конфиденциальности данных (Y) превышает время появления криптографически значимого квантового компьютера (Z) - миграция уже запоздала. Для банковских данных с 10-летним сроком хранения и реалистичным 5-летним циклом миграции формула показывает: начинать надо было вчера. По данным Eviden, для средней организации минимальный неснижаемый срок миграции - три года, и это без учёта инвентаризации и оценки рисков.
Для SOC-команды это конкретная задача: знать, какие криптографические алгоритмы используются в инфраструктуре, определить каналы, уязвимые к будущей дешифровке, и настроить detection перехвата и downgrade-атак.
Слабые криптографические алгоритмы: что искать при аудите
При криптографическом аудите приложений алгоритмы делятся на три категории. Первая - дырявые прямо сейчас, эксплуатация не требует квантовых вычислений. Вторая - уязвимые при появлении квантового компьютера, критичные для данных с долгим сроком конфиденциальности. Третья - квантово-устойчивые алгоритмы, на которые нужно мигрировать.
Уязвимые сейчас (критический приоритет):
| Алгоритм / протокол | Статус | Риск | Замена |
|---|---|---|---|
| RC4 | Сломан | Дешифровка трафика классическими методами | AES-GCM |
| 3DES (Triple DES) | Deprecated NIST | Атака Sweet32, коллизии блоков | AES-256-GCM |
| MD5 (в подписях, HMAC) | Сломан | Коллизии, подделка подписей | SHA-256 / SHA-3 |
| SHA-1 (в подписях) | Сломан | Коллизии, подделка сертификатов | SHA-256 / SHA-3 |
| TLS 1.0 / 1.1 | Deprecated | BEAST, POODLE, downgrade-атаки | TLS 1.3 |
| RSA < 2048 бит | Небезопасен | Факторизация классическими методами | RSA 3072+ или ECDSA P-256+ |
| AES в режиме ECB | Небезопасен | Утечка паттернов в шифротексте | AES-GCM, AES-CBC с HMAC |
Уязвимые при появлении квантового компьютера (HNDL-приоритет):
| Алгоритм | Квантовая угроза | PQC-замена |
|---|---|---|
| RSA (любой размер ключа) | Алгоритм Шора - полиномиальная факторизация | ML-KEM (FIPS 203) + ML-DSA (FIPS 204) |
| ECDSA / ECDH | Алгоритм Шора - дискретный логарифм на кривых | ML-DSA (FIPS 204) для подписей |
| Diffie-Hellman | Алгоритм Шора | ML-KEM (FIPS 203) для обмена ключами |
| DSA | Алгоритм Шора | ML-DSA (FIPS 204) |
Симметричные шифры затрагивает алгоритм Гровера, но он даёт лишь квадратичное ускорение - компенсируется удвоением длины ключа. Переход с AES-128 на AES-256 закрывает вопрос. Для симметрики миграция менее срочна, чем для асимметрики.
В терминах MITRE ATT&CK наличие слабых алгоритмов в инфраструктуре создаёт предпосылки для Weaken Encryption (T1600) - атакующий эксплуатирует слабую конфигурацию - и Reduce Key Space (T1600.001) - целенаправленное понижение стойкости через downgrade или подмену параметров.
[Применимо: внешний и внутренний пентест] На внутреннем аудите устаревшие протоколы встречаются куда чаще - legacy-сервисы из серии "работает и не трогаем". На внешнем периметре основной фокус - TLS-конфигурация фронтов и поддержка слабых cipher suites.
Инструменты и методология поиска устаревших алгоритмов шифрования
. Проверяет deprecated-протоколы, слабые cipher suites, валидность сертификатной цепочки, OCSP stapling.
openssl s_client - точечная проверка PQC
Для ручной диагностики поддержки постквантового обмена ключами:
Bash:
openssl s_client -connect target:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>&1 | grep "Negotiated"Аудит уровня приложения и ограничения инструментов
testssl.sh и sslyze видят только TLS-конфигурацию сетевых сервисов. Они не обнаружат криптографию внутри приложения: ECB-режим AES для шифрования полей в базе, MD5 для хеширования паролей, SHA-1 в JWT-подписях. Для уровня приложения нужен анализ кода и конфигураций - грубый, но рабочий подход:
Bash:
grep -rn "DES\|RC4\|MD5\|ECB\|SHA1" --include="*.conf" --include="*.yaml"Detection слабой криптографии в SIEM: правила и алерты для SOC
Криптоаудит - разовое мероприятие. Непрерывный мониторинг криптографических аномалий - задача SOC. Ниже - конкретные правила корреляции.Согласование deprecated cipher suites
Если в логах TLS-терминатора (nginx, HAProxy, F5) или в данных Zeek всплывает согласование cipher suite из deprecated-списка - это алерт. Логика:- Источник: логи TLS-терминатора, поле
ssl_cipher/cipher_suite; для Zeek - полеcipherвssl.log - Условие: значение содержит
RC4,3DES,DES-CBC,NULL,EXPORTилиanon - Severity: High для external-facing сервисов, Medium для internal
- Действие: уведомление SOC, автоматический тикет на remediation
$ssl_cipher в access log - её нужно включить в формат логирования явно.Downgrade TLS-версии
Сервер, ранее работавший на TLS 1.3, вдруг начал согласовывать TLS 1.0 - это может быть кривой деплой, а может быть активная downgrade-атака (T1557, Adversary-in-the-Middle). Правило корреляции:- Baseline: зафиксировать "нормальную" TLS-версию для каждого сервиса
- Алерт: отклонение от baseline в сторону понижения
- Обогащение: проверить совпадение с окном деплоя или изменением конфигурации; если совпадения нет - эскалация
Сертификатные аномалии
- Сертификат с RSA < 2048 бит на production-сервисе - немедленный алерт
- Подпись сертификата по SHA-1 - алерт
- Самоподписанный сертификат на сервисе, где раньше использовался CA-signed - критический алерт, возможен MitM
- Истекающий сертификат (менее 30 дней) - операционный алерт
Неожиданное появление PQC-параметров
Если в трафике обнаруживается согласование X25519MLKEM768, а организация не инициировала PQC-миграцию - это аномалия, требующая расследования. Реальный сценарий: Kubernetes v1.33, собранный на Go 1.24, получил X25519MLKEM768 как default key exchange - побочный эффект обновления тулчейна, без отдельного релиз-флага. Увеличенный ClientHello (~1.6 КБ для X25519MLKEM768 из-за публичного ключа ML-KEM-768 в ~1184 байта) превышает один TCP-сегмент и фрагментируется, что ломает middleware и сетевые устройства, ожидающие ClientHello в одном пакете. Это не атака, но незапланированное изменение криптографического профиля - SOC должен его видеть.Чеклист квантово-устойчивого аудита приложений
Готовый чеклист для передачи команде эксплуатации или включения в отчёт:- Криптоинвентаризация. Составить реестр всех используемых алгоритмов, протоколов и длин ключей: TLS-конфигурации, сертификаты, JWT-подписи, шифрование at rest, хеширование паролей. Привязать к сервисам и владельцам.
- Сканирование TLS. Запустить
testssl.sh --fullна всех внешних и внутренних HTTPS-эндпоинтах. Собрать JSON-отчёты, отфильтровать severity HIGH и CRITICAL. - Удаление deprecated-алгоритмов. Ни один сервис не должен согласовывать RC4, 3DES, MD5-подписи, SHA-1-подписи, TLS 1.0/1.1, RSA < 2048 бит. Зафиксировать remediation-план с ответственными и дедлайнами.
- Оценка crypto agility. Проверить, можно ли заменить алгоритм на каждом уровне стека через конфигурацию, без пересборки приложения. Хардкод алгоритмов - риск, фиксируется в отчёте.
- Классификация по HNDL-риску. Выделить данные с длительным сроком конфиденциальности (>10 лет) - персональные данные, коммерческая тайна. Приоритизировать переход на гибридные схемы (classical + PQC).
- SIEM-правила. Настроить корреляции: deprecated cipher suites, TLS downgrade, сертификатные аномалии, неожиданные PQC-параметры в трафике.
- PQC-совместимость на стенде. Проверить работу сервисов с X25519MLKEM768 (OpenSSL 3.5.0+, Go 1.24+). Зафиксировать несовместимости middleware.
- Roadmap миграции. Сформировать план с учётом сроков NIST: deprecated после 2030, disallowed после 2035. Приоритет: сначала обмен ключами (KEM), затем подписи - обмен ключами критичнее из-за HNDL.
За последние три года я провёл десятки криптоаудитов, и в каждом втором случае алгоритм шифрования оказывался хардкодом: в конфиге приложения, в коде, в параметрах библиотеки, которую не обновляли годами. Формально аудит пройден - алгоритмы актуальные. Но попробуйте переключить этот сервис на ML-KEM через конфигурацию, без пересборки. Не выйдет. И это не теоретическая претензия - NIST-таймлайн с дедлайном 2035 года не оставляет пространства для "разберёмся, когда придёт время". Организации с жёстко зашитой криптографией окажутся в позиции, где замена одного алгоритма потянет за собой пересборку десятков сервисов. Crypto agility - не модный термин, а архитектурное требование, которое должно фигурировать в каждом отчёте по криптоаудиту как отдельная категория риска, а не в разделе "рекомендации на будущее". Если интересно, как другие команды выстраивают криптоинвентаризацию и приоритизируют миграцию - на codeby.net есть тред по PQC-планированию, где обсуждают реестры, HNDL-оценку и приоритизацию сервисов под конкретные инфраструктуры.
Последнее редактирование модератором:
