🧠 Skills: Crypto Agility — навык который нужен сисадмину прямо сейчас, а не в 2030-м

Коллеги, пятничный пост в четверг — потому что тема важная, а пятницу займёт что-нибудь свежее.

Май 2026 дал нам два отличных примера почему crypto agility — это не теоретическая концепция. Secure Boot 2011 → 2023: ротация корневых сертификатов требует ручного вмешательства на тысячах серверов. RC4 в Kerberos: 30 лет использовали, теперь принудительное отключение в июле. Оба случая — болезненная миграция из-за отсутствия гибкости.

Crypto agility — это способность менять криптографические алгоритмы и ключи без переписывания всей инфраструктуры. Это не про квантовые компьютеры. Это про то, что алгоритмы устаревают регулярно.

Три практических элемента которые нужны прямо сейчас:

ЭЛЕМЕНТ 1: КРИПТОГРАФИЧЕСКАЯ ИНВЕНТАРИЗАЦИЯ

Что нужно знать о каждом сервисе:
  - Какие алгоритмы используются (RSA? ECDSA? AES?)
  - Где хранятся ключи и сертификаты
  - Когда истекают сертификаты
  - Какие зависимости (приложения, протоколы)

Инструменты:
  # Linux: сканируем конфиги
  grep -r "SSLProtocol\|SSLCipherSuite\|ssl_protocols\|ssl_ciphers" \
      /etc/nginx/ /etc/apache2/ /etc/haproxy/ 2>/dev/null

  # Проверяем TLS на работающих сервисах:
  nmap --script ssl-enum-ciphers -p 443 <IP>

  # Сертификаты в системе:
  find /etc -name "*.crt" -o -name "*.pem" 2>/dev/null | \
      xargs -I{} openssl x509 -in {} -noout -subject -enddate 2>/dev/null

  # Windows: сертификаты в хранилищах
  Get-ChildItem Cert:\LocalMachine\My |
      Select-Object Subject, NotAfter, Thumbprint |
      Sort-Object NotAfter

ЭЛЕМЕНТ 2: МОНИТОРИНГ СРОКА ЖИЗНИ

Автоматический алерт за 90/30 дней до истечения любого сертификата.
Это то чего не было для Secure Boot 2011 — никто не получил алерт
в 2024 году что через два года сертификаты истекут.

  # Простой скрипт мониторинга сертификатов:
  find /etc -name "*.crt" -o -name "*.pem" 2>/dev/null | \
    while read cert; do
      exp=$(openssl x509 -in "$cert" -noout -enddate 2>/dev/null | \
            cut -d= -f2)
      if [ -n "$exp" ]; then
        exp_epoch=$(date -d "$exp" +%s 2>/dev/null)
        now_epoch=$(date +%s)
        days_left=$(( (exp_epoch - now_epoch) / 86400 ))
        if [ "$days_left" -lt 90 ]; then
          echo "WARN: $cert expires in $days_left days ($exp)"
        fi
      fi
    done

ЭЛЕМЕНТ 3: ЗАМЕНА БЕЗ ДАУНТАЙМА

Для каждого критичного сервиса должен быть ответ на вопрос:
"Если нам нужно сменить сертификат/алгоритм прямо сейчас —
сколько это займёт и что потребует перезапуска?"

Если ответ "несколько дней и полный downtime" — это проблема.
Если "15 минут и горячая перезагрузка конфига" — это crypto agility.

nginx -s reload          # Hot reload сертификата без downtime
systemctl reload apache2 # То же для Apache

Зачем это важно именно сейчас а не в 2030-м: криптографическая гибкость — это не просто ответ на квантовую угрозу. Слабое шифрование может быть взломано уже сегодня, а скомпрометированные долгоживущие сертификаты готовы для будущей подделки. Прежде чем справляться с живыми угрозами — нужно понимать текущую криптографическую архитектуру.

Итог: инвентаризация + мониторинг + план замены. Это три часа работы которые меняют "паника в июне 2026" на "плановое обновление в марте 2026". Сделай это сейчас — следующий Secure Boot истечёт в 2033-м, и это уже твоя задача.

#skills #security #crypto #pkи #sysadmin #admin_future

🔐 APT учится SHA3: Ubuntu готовится к дню, когда SHA-2 падёт. Зачем это нужно уже сейчас

Коллеги, понедельник. Сегодня пост не про очередную горящую CVE на периметре, а про эталонную инженерную предусмотрительность и архитектурную дальновидность.

📌 ФАКТЫ
Инициатива: инженеры Canonical (в частности, Gianpiero Carpinelli) внесли в апстрим пакетного менеджера APT поддержку семейства хешей SHA3-256 и SHA3-384 для проверки целостности индексных файлов (Release, Packages, Sources).

Дефолт не меняется: SHA-256/SHA-512 остаются базовым стандартом. Поддержка SHA3 внедряется как спящий резервный механизм.

Математика жизненного цикла: современные Enterprise-релизы (такие как Ubuntu 24.04 LTS в рамках расширенной поддержки Ubuntu Pro) живут 10–12 лет — то есть вплоть до 2036 года. Если на этом горизонте математический аппарат SHA-2 даст критическую трещину, миллионы установленных хостов должны уметь валидировать пакеты по альтернативному алгоритму без аврального обновления самого APT.

Текущий статус криптографии: семейство SHA-2 (SHA-256/512) не скомпрометировано, практических атак нет. При аппруве патча в апстриме Debian/APT функционал планируют бэкпортировать в LTS-ветку 24.04.

🛠 АУДИТ РЕПОЗИТОРИЕВ И КЛЮЧЕЙ В СИСТЕМЕ
Пока Canonical закладывает фундамент на 10 лет вперед, полезно проверить, нет ли в вашей системе хвостов из прошлого века:

Bash

# 1. Какие типы хешей фактически задействованы в ваших текущих InRelease
grep -hoE '^(MD5Sum|SHA1|SHA256|SHA512|SHA3-[0-9]+):' \
  /var/lib/apt/lists/*InRelease 2>/dev/null | sort | uniq -c

# 2. Поиск устаревших GPG-ключей репозиториев (RSA 1024, DSA и legacy-форматы)
for k in /etc/apt/trusted.gpg.d/* /usr/share/keyrings/*; do
  [ -f "$k" ] || continue
  echo "== Файл: $k"
  gpg --show-keys "$k" 2>/dev/null | grep -E '^pub'
done

💡 В ЧЁМ СУТЬ

В криптографии это называется crypto-agility (криптографическая гибкость) — способность инфраструктуры переключиться на новые криптопримитивы без необходимости менять сам софт и переустанавливать ОС на клиентах.

Обновить центральное зеркало репозитория можно за полчаса. А вот обновить пакетный менеджер на тысячах серверов, изолированных промышленных контроллерах или банкоматах, если проверка подписей внезапно сломается из-за компрометации алгоритма, — задача на месяцы аварийных работ.

🛡 НА ЧТО ОБРАТИТЬ ВНИМАНИЕ В СВОЕЙ СЕТИ
Пока ядро APT готовится к будущему, аналогичный вопрос стоит задать собственной инфраструктуре:

Собственные Nexus / Artifactory / Aptly: поддерживают ли ваши локальные пайплайны сборки пакетов современные алгоритмы хеширования и подписи?

SSH-инфраструктура: давно ли вы вычищали из authorized_keys и конфигов sshd старые ключи ssh-rsa (SHA-1) в пользу ed25519 и ecdsa?

Внутренний PKI / CA: какой алгоритм подписи выставлен на корневых и промежуточных сертификатах корпоративного центра сертификации?

#linux #debian #ubuntu #apt #crypto #security #sysadmin #admin_future

🔐 OpenSSL 4.1 вышел: DTLS 1.3, оптимизации постквантовой криптографии и четыре известных бага в DTLS

Коллеги, понедельник. Разбираем свежий релиз библиотеки, который в скором времени доберётся до репозиториев дистрибутивов.

📌 ЧТО НОВОГО
DTLS 1.3 (RFC 9147) и поддержка датаграмм в едином SSL listener API

Постквантовые алгоритмы (PQC): существенное ускорение ML-KEM и ML-DSA благодаря векторизации AVX-512 на x86_64 и NTT-оптимизациям для архитектуры ppc64le

Ускорена расшифровка блочного шифра AES-CBC на x86_64 связкой инструкций AVX-512 + VAES

Реализован механизм GREASE (RFC 8701) для предотвращения закостеневания протоколов, добавлен KDF для IKEv2 (IPsec) и первичная поддержка отечественной архитектуры Эльбрус 2000 (e2k)

🗑 ЧТО УБРАЛИ И СЛОМАЛИ
Опции сборки ./config no-ecdsa и no-ecdh удалены: исторически они не отключали реализацию полностью; теперь эллиптические кривые выключаются строго целиком через no-ec

Окончательно вычищены таргеты сборки под устаревшие платформы: Windows на базе Itanium (IA-64) и Windows CE

Утилита меток времени tsget переведена с заброшенного Perl-модуля WWW::Curl::Easy на Net::Curl::Easy (без установки зависимости утилита перестанет работать)

⚠️ ИЗВЕСТНЫЕ ПРОБЛЕМЫ В РЕЛИЗЕ
Команда OpenSSL открыто опубликовала список из четырех известных багов в новой реализации DTLS:

#32878: Сброс неподтверждённых post-handshake пакетов (включая NewSessionTicket) из буфера ретрансмиссии при получении DTLS 1.3 KeyUpdate.

#33277: Постоянный сбой приёма на DTLS listener может возвращать SSL_ERROR_WANT_READ, загоняя приложение в бесконечное ожидание.

#33278: Временная ошибка записи на неблокирующем соединении репортится как фатальный SSL_ERROR_SYSCALL вместо SSL_ERROR_WANT_WRITE, из-за чего софт может рвать рабочие сессии.

#33242: Обрыв рукопожатия DTLS 1.3 алертом unexpected_message при частичной потере пакетов и повторном ACK.

🛠 АУДИТ ВЕРСИИ В ОКРУЖЕНИИ
Bash

# Текущая версия и параметры сборки OpenSSL
openssl version -a | head -2

# Проверяем, с чем слинкован ваш веб-сервер / балансировщик
ldd "$(command -v nginx)" 2>/dev/null | grep -E 'libssl|libcrypto'

💡 В ЧЁМ СУТЬ

Для классического веб-стека (TLS поверх TCP/QUIC) ветка 4.1 сохраняет полную обратную совместимость на уровне ABI/API с 4.0.

Однако для сервисов, критично завязанных на датаграммный DTLS (корпоративные VPN со шлюзами на UDP, AnyConnect-совместимые туннели, SIP, WebRTC и телеметрия), с миграцией на 4.1.0 стоит повременить до выхода корректирующего релиза 4.1.1 с исправлением логики ретрансмиссии и listener-ошибок.

#openssl #tls #dtls #crypto #linux #sysadmin #admin_future