TLS/SSL на практике: QSslSocket, сертификаты, проверка цепочки доверия

Введение

Темы TLS уже затрагивались в gRPC-цикле (статья 329) и MQTT-цикле (статья 318) в специфичном контексте этих протоколов. В этой статье разберём TLS более общо и подробно — через QSslSocket, базовый класс Qt для защищённых сетевых соединений, и углубимся в механику проверки сертификатов, обычно скрытую за высокоуровневыми API.

Концепция

TLS обеспечивает три свойства одновременно: конфиденциальность (шифрование, статья 373, защищающее содержимое от перехвата), целостность (любое изменение данных при передаче обнаруживается), и аутентификацию сервера (через цепочку сертификатов, подтверждающую, что сервер действительно тот, за кого себя выдаёт) — именно последнее свойство наиболее тонкое и чаще всего реализуется с ошибками на практике. Цепочка доверия (certificate chain) строится от сертификата конкретного сервера через один или несколько промежуточных сертификатов до корневого сертификата (root CA), которому операционная система или приложение явно доверяет — QSslSocket по умолчанию проверяет эту цепочку автоматически, но разработчики нередко неосознанно отключают эту проверку при отладке, забывая включить её обратно для production.

Пример кода: TLS/SSL на практике

// QSslSocket — базовое защищённое соединение с автоматической проверкой сертификата сервера
#include <QSslSocket>

void connectSecurely()
{
    auto *socket = new QSslSocket();

    connect(socket, &QSslSocket::encrypted, []() {
        qDebug() << "TLS-соединение успешно установлено, сертификат сервера проверен";
    });

    // sslErrors — КРИТИЧНО ВАЖНОЕ подключение: без него ошибки сертификата
    // могут быть проигнорированы автоматически в зависимости от конфигурации
    connect(socket, &QSslSocket::sslErrors, [socket](const QList<QSslError> &errors) {
        for (const auto &error : errors) {
            qWarning() << "Ошибка SSL:" << error.errorString();
        }
        // НЕ вызываем socket->ignoreSslErrors() — соединение будет корректно прервано
        // при настоящей проблеме с сертификатом, что и является желаемым поведением
    });

    socket->connectToHostEncrypted("api.example.com", 443);
}

// Явная проверка деталей цепочки сертификатов — для диагностики или дополнительных проверок
void inspectCertificateChain(QSslSocket *socket)
{
    const QList<QSslCertificate> chain = socket->peerCertificateChain();
    for (const auto &cert : chain) {
        qDebug() << "Субъект:" << cert.subjectInfo(QSslCertificate::CommonName);
        qDebug() << "Издатель:" << cert.issuerInfo(QSslCertificate::CommonName);
        qDebug() << "Действителен до:" << cert.expiryDate();
    }
}

// АНТИПАТТЕРН — явно показанный как пример того, чего НЕ следует делать в production-коде
void insecureConnectionExample(QSslSocket *socket)
{
    // Полное отключение проверки ошибок сертификата — допустимо ТОЛЬКО для
    // временного, локального тестирования с самоподписанным сертификатом,
    // и должно быть убрано перед выпуском приложения в production
    connect(socket, &QSslSocket::sslErrors, socket,
            static_cast<void (QSslSocket::*)(const QList<QSslError> &)>(&QSslSocket::ignoreSslErrors));
}

Пояснения к коду

Подключение к sslErrors без вызова ignoreSslErrors() (первый, корректный пример) показывает желаемое поведение для production-кода — при возникновении проблемы с сертификатом (просрочен, не соответствует имени хоста, выпущен недоверенным центром сертификации) соединение не будет автоматически разорвано Qt без явного действия программиста, поэтому код приложения должен либо явно вызвать socket->abort() при получении ошибок, либо просто не вызывать ignoreSslErrors(), что само по себе приведёт к прекращению handshake без установления соединения. inspectCertificateChain() показывает, как получить доступ к деталям уже проверенного (или ещё не до конца проверенного) сертификата для дополнительной, специфичной для приложения логики — например, проверки конкретного, ожидаемого значения поля Common Name сверх стандартной проверки самой цепочки доверия (certificate pinning, продвинутая техника, упоминаемая в подводных камнях).

Подводные камни

Вызов ignoreSslErrors() без аргументов (игнорирование ВСЕХ ошибок сертификата) в production-коде, что катастрофически устраняет всю защиту, которую призван давать TLS — это один из самых распространённых и опасных антипаттернов в реальном коде, часто появляющийся как «временное» решение проблемы с самоподписанным сертификатом при разработке, но забытый и оставленный в финальной, выпущенной версии приложения; явно показанный антипаттерн в примере должен использоваться (если вообще) исключительно во временном, локальном тестовом коде с чётким планом его удаления перед релизом.
Игнорирование конкретных типов ошибок без разбора, вместо избирательной обработки только действительно ожидаемых, понятых случаев (например, для тестового окружения с известным самоподписанным сертификатом стоит игнорировать именно QSslError::SelfSignedCertificate, а не вызывать общий ignoreSslErrors() без аргументов, потенциально маскирующий и другие, неожиданные и реально опасные проблемы) — даже для оправданных случаев частичного игнорирования ошибок стоит явно перечислять конкретные, ожидаемые типы ошибок, а не отключать проверку полностью.
Полное доверие проверке сертификата без дополнительного certificate pinning для особо критичных соединений (банковские приложения, передача особо чувствительных данных) — стандартная проверка цепочки доверия защищает от большинства угроз, но теоретически уязвима при компрометации какого-либо доверенного центра сертификации в цепочке; certificate pinning (явная проверка точного, заранее известного отпечатка сертификата конкретного сервера, а не просто действительности цепочки доверия в целом) даёт дополнительный уровень защиты для особо критичных соединений, хотя и требует более сложного процесса обновления при легитимной смене сертификата сервера.
Использование устаревших версий протокола TLS (TLS 1.0/1.1, признанные небезопасными и постепенно выводимые из эксплуатации основными браузерами и стандартами) без явной настройки минимально допустимой версии протокола — современный код должен явно ограничивать допустимые версии протокола через QSslConfiguration::setProtocol(), выбирая TLS 1.2 как минимум (предпочтительно TLS 1.3), а не полагаться на потенциально устаревшие настройки по умолчанию используемой версии Qt/OpenSSL.