Аудит конфигурации HTTPS / TLS

Целевой аудит того, как ваш эндпоинт согласует TLS и отдаёт HTTPS — для команд, которым мало значка «A+». Мы проверяем версии протоколов, выбор шифров и forward secrecy, всю цепочку сертификатов и отзыв, HSTS/preload, mixed content и заголовки безопасности, после чего выдаём приоритизированный список исправлений по базам Mozilla и NIST.

Что мы проверяем

Перечисление версий протоколов

Проверяем поддержку SSLv2/SSLv3/TLS1.0/1.1/1.2/1.3 и отмечаем любое согласование TLS 1.0/1.1 или SSL, которые устарели (RFC 8996) и запрещены PCI DSS и NIST SP 800-52r2.

Наборы шифров и forward secrecy

Перечисляем предлагаемые наборы по каждому протоколу, проверяем обмен ключами ECDHE/DHE для forward secrecy и отмечаем RC4, 3DES, устаревшие режимы CBC, NULL, EXPORT и анонимные наборы, а также слабые параметры DH (<2048 бит).

Цепочка и срок сертификата

Валидируем конечный сертификат, промежуточные и порядок цепочки, длину ключа и алгоритм подписи (отмечая SHA-1 и RSA <2048), окно действия, соответствие SAN/имени хоста и случаи self-signed или недоверенного корня.

Отзыв: OCSP и stapling

Проверяем доступность OCSP-респондера, OCSP stapling и must-staple, а также доступность CRL — чтобы отозванный сертификат действительно отклонялся, а не молча принимался.

HSTS и preload

Проверяем наличие Strict-Transport-Security, max-age не менее года, includeSubDomains и право на preload, а также подтверждаем, что заголовок отдаётся только по HTTPS, как требует спецификация.

Усиление редиректов и mixed content

Подтверждаем, что HTTP постоянно перенаправляет на HTTPS до любого чувствительного ответа, и сканируем страницы на активный/пассивный mixed content (скрипты, стили, изображения по http://), ломающий границу доверия.

Уязвимость к известным атакам TLS

Тестируем BEAST, POODLE, Heartbleed (CVE-2014-0160), ROBOT, CRIME/BREACH, Sweet32, LOGJAM, FREAK и ошибки ренеготиации безопасной детекцией класса testssl — без эксплуатации живых данных.

Заголовки безопасности ответа

Разбираем CSP (включая upgrade-insecure-requests), X-Content-Type-Options, X-Frame-Options/frame-ancestors, Referrer-Policy и Permissions-Policy на предмет пробелов, ослабляющих транспортный уровень.

Методология

  1. 1

    Область и разведка

    Подтверждаем авторизацию и хосты/порты в области, затем перечисляем каждый эндпоинт, терминирующий TLS — apex, www, поддомены API, балансировщики и края CDN — так как конфигурация между ними часто расходится.

  2. 2

    Автоматическое базовое сканирование

    Запускаем инструменты класса testssl.sh и проверки в стиле Mozilla Observatory по каждому эндпоинту, фиксируя протоколы, порядок шифров, данные сертификатов и заголовки как воспроизводимое свидетельство.

  3. 3

    Ручная верификация

    Вручную подтверждаем находки — согласуя конкретные наборы, проходя цепочку, проверяя stapling — чтобы устранить ложные срабатывания сканера до попадания в отчёт.

  4. 4

    Сопоставление с базами и оценка

    Каждую находку оцениваем относительно Mozilla Intermediate/Modern и NIST SP 800-52r2, с CVSS там, где применим CVE, чтобы серьёзность отражала реальный стандарт, а не буквенную оценку инструмента.

  5. 5

    Отчёт и рекомендации по исправлению

    Вы получаете приоритизированный отчёт с точными исправлениями — строки шифров, директивы HSTS, починка цепочки — и готовой конфигурацией для nginx/Apache/HAProxy или вашего CDN.

  6. 6

    Ретест и верификация

    После устранения мы повторно сканируем изменённые эндпоинты и выдаём обновлённую аттестацию, подтверждающую соответствие базе — в рамках окна ретеста.

Стандарты и ссылки

Mozilla Server Side TLS (Modern / Intermediate / Old)NIST SP 800-52r2 — Guidelines for TLS ImplementationsRFC 8996 — Deprecating TLS 1.0 and TLS 1.1RFC 8446 — TLS 1.3RFC 6797 — HTTP Strict Transport Security (HSTS)OWASP WSTG-CRYP-01 — Testing for Weak Transport Layer SecurityPCI DSS v4.0 Треб. 4 — защита данных сильной криптографиейCA/Browser Forum Baseline Requirements

Что вы получаете

  • Резюме для руководства Одностраничный обзор риска с текущей позицией по Mozilla/NIST и немногими изменениями с наибольшим эффектом — для менеджмента и аудиторов.
  • Технический отчёт Детали по каждому эндпоинту: протоколы, полный список шифров, цепочка сертификатов, заголовки, каждая находка с серьёзностью, свидетельством и шагами воспроизведения.
  • Готовая ремедиация Усиленные фрагменты конфигурации для nginx/Apache/HAProxy/CDN — строки шифров, только TLS 1.2+, OCSP stapling, HSTS и указания по подаче в preload.
  • Аттестация после ретеста Подписанное письмо-верификация после исправлений, подтверждающее соответствие согласованной базе — для комплаенса и проверок безопасности со стороны клиентов.

Частые вопросы

Сколько длится аудит TLS и сколько стоит?+

Один хост обычно готов за 1–2 рабочих дня; набор связанных эндпоинтов (apex, www, несколько поддоменов API) — за 3–5. Цена фиксирована для области и зависит от числа эндпоинтов, терминирующих TLS, поэтому вы знаете стоимость до старта, а не платите по часам.

Что нужно от нас для начала?+

Достаточно хостов/IP и портов в области и письменной авторизации от владельца домена или инфраструктуры. Аудит выполняется по вашему публичному TLS-эндпоинту, поэтому не нужны исходный код, учётные данные или установка агентов — хотя сведения о CDN и WAF перед сервисом помогают точно протестировать каждый слой.

Безопасно ли запускать это по продакшену?+

Да. Проверки — это зонды конфигурации и согласования плюс безопасная, неразрушающая детекция уязвимостей (класса testssl). Мы не эксплуатируем находки, не вытягиваем данные и не создаём значимую нагрузку. Тесты Heartbleed и подобные используют мягкую детекцию, которая не читает память и не повреждает сервис.

Входит ли ретест после исправлений?+

Да. Один ретест исправленных эндпоинтов входит в оговорённое окно (обычно 30 дней) и завершается обновлённой аттестацией. Если нужна непрерывная защита при ротации сертификатов и дрейфе конфигурации, мы предлагаем и плановый мониторинг.

Вы просто выдадите мне оценку SSL Labs?+

Нет. Буквенные оценки скрывают реальный риск — сайт может иметь «A», но всё ещё не иметь HSTS preload, stapling или корректной цепочки. Мы сопоставляем каждую находку с Mozilla и NIST SP 800-52r2 и приоритизируем по реальному влиянию, с точными исправлениями вместо значка.

Проверяете ли вы также заголовки безопасности HTTP?+

Да. Безопасность транспорта ослабевает, если слой ответа слаб, поэтому мы разбираем HSTS, CSP (включая upgrade-insecure-requests), X-Frame-Options/frame-ancestors, X-Content-Type-Options, Referrer-Policy и Permissions-Policy и отмечаем mixed content, ломающий границу доверия HTTPS.

Закажите аудит TLS с фиксированной областью для ваших эндпоинтов — запросите объём и смету сегодня.