Основы TLS

Transport Layer Security (TLS) — протокол, который ставит «S» в HTTPS. Он обеспечивает шифрование, аутентификацию и целостность данных. Для QA-инженеров понимание TLS необходимо: неправильно настроенные сертификаты вызывают сбои, заголовки безопасности предотвращают атаки, а смешанный контент ломает функциональность.

TLS 1.2 vs TLS 1.3

ХарактеристикаTLS 1.2TLS 1.3
Рукопожатие2 round-trip1 round-trip
0-RTTНе поддерживаетсяПоддерживается
Cipher suitesМного (включая слабые)Только 5 сильных
Forward secrecyОпциональноОбязательно

Рукопожатие TLS 1.3 быстрее и проще. Клиент отправляет свою долю ключа в первом сообщении, позволяя серверу немедленно вывести ключ шифрования.

Процесс рукопожатия

Каждое HTTPS-соединение начинается с TLS-рукопожатия:

  1. ClientHello: Клиент отправляет поддерживаемые версии TLS, cipher suites и случайное значение
  2. ServerHello: Сервер выбирает версию TLS и cipher suite, отправляет сертификат
  3. Проверка сертификата: Клиент валидирует цепочку против доверенных CA
  4. Обмен ключами: Обе стороны генерируют общие секретные ключи
  5. Finished: Начинается шифрованная коммуникация

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

  • Конечный сертификат (leaf): Установлен на сервере, содержит имя домена
  • Промежуточный сертификат(ы): Выданы CA, связывают leaf с root
  • Корневой сертификат: Предустановлен в хранилище доверия ОС/браузера

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

Чек-лист тестирования SSL/TLS

Валидность сертификата

  • Сертификат не просрочен (проверить дату notAfter)
  • Доменное имя совпадает с полями Subject или SAN
  • Цепочка полная (нет отсутствующих промежуточных)
  • Сертификат выдан доверенным CA (не self-signed в продакшене)
  • Статус отзыва чист (проверка OCSP/CRL)

Конфигурация протокола

  • TLS 1.2 и 1.3 включены
  • TLS 1.0 и 1.1 отключены
  • SSL 2.0 и 3.0 отключены
  • Только сильные cipher suites
  • Forward secrecy включён (ECDHE)

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

  • HSTS с подходящим max-age
  • Нет смешанного контента
  • Безопасные атрибуты cookie (Secure, HttpOnly, SameSite)
  • Редирект HTTP на HTTPS настроен

Инструменты тестирования SSL

openssl s_client 

# Подключиться и показать детали сертификата
openssl s_client -connect example.com:443 -servername example.com

# Проверить срок действия
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Проверить цепочку
openssl s_client -connect example.com:443 -showcerts

# Тестировать конкретную версию TLS
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

Qualys SSL Labs

Бесплатный онлайн-сканер ssllabs.com/ssltest даёт комплексную оценку (от A+ до F) и детальный анализ конфигурации TLS, cipher suites, цепочки и уязвимостей.

sequenceDiagram participant C as Клиент participant S as Сервер C->>S: ClientHello (версия TLS, шифры, случайное) S->>C: ServerHello (выбранный шифр, сертификат) Note over C: Проверка цепочки сертификатов C->>S: Обмен ключами + Finished S->>C: Finished Note over C,S: Начинается шифрованная коммуникация

Продвинутое тестирование TLS

Certificate Pinning (мобильные приложения)

Certificate pinning встраивает ожидаемый сертификат в мобильное приложение, отклоняя любой другой. Тестирование включает:

  • Проверку отклонения соединений с неверными сертификатами
  • Тестирование ротации pin: при смене сертификата приложение обновляется корректно?
  • Проверку network security config на Android (network_security_config.xml)

Mutual TLS (mTLS)

В mTLS и клиент, и сервер предъявляют сертификаты:

# Тест с клиентским сертификатом
openssl s_client -connect api.example.com:443 \
  -cert client.crt -key client.key

Тестовые сценарии: Валидный клиентский сертификат, просроченный, неверный CA, без сертификата, отозванный.

Тестирование автообновления Let’s Encrypt

Для сертификатов Let’s Encrypt (срок 90 дней):

  1. Процесс обновления работает до истечения
  2. Сертификат перезагружается без перезапуска сервера
  3. OCSP stapling продолжает работать
  4. Нет простоя во время ротации

Практическое упражнение

Проведите аудит SSL-конфигурации сайта:

  1. Запустите SSL Labs и задокументируйте оценку
  2. Используйте openssl для проверки деталей, цепочки и срока
  3. Определите уязвимости
  4. Задокументируйте с уровнями серьёзности
  5. Порекомендуйте исправления
Подход к решению
# Детали сертификата
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text | head -30

# Проверить срок
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Проверить протоколы
for proto in tls1 tls1_1 tls1_2 tls1_3; do
  echo -n "$proto: "
  echo | openssl s_client -connect example.com:443 -$proto 2>/dev/null | grep "Protocol"
done

Советы профессионала

  • Настройте оповещения об истечении сертификатов — просроченные сертификаты вызывают сбои
  • Тестируйте с отключёнными TLS 1.0/1.1, чтобы убедиться, что ничего не ломается
  • Проверяйте Subject Alternative Names (SANs) на все ожидаемые домены
  • Проверяйте редирект HTTP на HTTPS и заголовок HSTS при каждом деплое
  • Тестируйте с нескольких клиентов (браузер, мобильный, API-инструмент)

Ключевые выводы

  1. Конфигурация SSL/TLS — критическая область тестирования: ошибки вызывают сбои и уязвимости
  2. Управление жизненным циклом сертификатов требует непрерывного тестирования
  3. SSL Labs — лёгкий первый проход; openssl — детальное ручное исследование
  4. Тестирование смешанного контента обязательно для любой HTTPS-миграции