SSL и TLS: в чём разница, как работает HTTPS и сертификаты

При обращении к сайту по HTTPS браузер проверяет подлинность сервера и защищает передаваемые HTTP-данные. За это отвечает TLS. Однако в настройках серверов и названиях сертификатов до сих пор встречается SSL. Разница становится важной, когда соединение не устанавливается или браузер предупреждает о проблеме с сертификатом.

TLS (Transport Layer Security) — протокол защиты данных в процессе передачи между участниками соединения. Он позволяет согласовать криптографические ключи, проверить подлинность сервера и защищать сообщения от чтения и незаметного изменения в пути. SSL — название более раннего семейства протоколов, которое современным TLS заменено. HTTPS — HTTP, работающий через защищённое соединение; для привычного HTTPS его обеспечивает TLS.

Проследим путь от адреса сайта до первого HTTP-запроса: согласование TLS, проверку сертификата и передачу данных. В конце вы сможете посмотреть параметры реального соединения через OpenSSL и отличить проблему доверия к сертификату от проблемы с именем сервера.

Основной пример — новое HTTPS-соединение поверх TCP с TLS 1.3 и сертификатом сервера. В HTTP/3 последовательность установки транспорта другая, и мы отметим это отдельно.

SSL и TLS: в чём разница

SSL (Secure Sockets Layer) появился раньше TLS и решал похожую задачу: защищённый обмен между клиентом и сервером. TLS (Transport Layer Security) развил эту модель, но его версии не являются просто другим названием SSL. У них отличаются протокольные сообщения, согласование криптографических параметров и требования к безопасности.

Название	Статус	Что означает для HTTPS
SSL 2.0 и SSL 3.0	Устаревшие версии	Не использовать для новых соединений
TLS 1.0 и TLS 1.1	Выведены из использования	Не согласовывать даже ради совместимости
TLS 1.2	Используемая версия TLS	Возможна защищённая конфигурация; механизм handshake отличается от TLS 1.3
TLS 1.3	Современная версия TLS	Основная модель соединения в этой статье

SSL 3.0 нельзя согласовывать: RFC 7568 прямо запрещает использование SSLv3. Требование содержится в разделе 3 RFC 7568.

TLS 1.0 и TLS 1.1 выведены из использования: RFC 8996 запрещает согласовывать эти версии. RFC 8996, разделы 4–5 объясняет запрет, в том числе отсутствием современных криптографических механизмов у прежних версий. TLS 1.2 при этом нельзя автоматически считать небезопасным лишь по номеру версии: важны допустимые алгоритмы и конфигурация.

Термин «SSL-сертификат» по-прежнему встречается в названиях услуг и интерфейсах администрирования. Отдельного формата сертификата «для SSL» в сравнении с «для TLS» здесь нет: для обычной проверки HTTPS-сервера используются сертификаты X.509. Сертификат сам по себе также не выбирает версию TLS — её согласовывают клиент и сервер.

Как работает HTTPS

HTTP определяет смысл запроса и ответа: метод, путь, заголовки, статус, тело. TLS защищает перенос этих данных между конечными точками соединения и помогает клиенту проверить сервер. Обозначение https:// сообщает клиенту, что для данного ресурса требуется защищённое соединение. Назначение схемы https описано в RFC 9110, разделе 4.2.2.

Для типичного нового соединения с HTTP/1.1 поверх TCP процесс выглядит так:

Клиент определяет адрес назначения через DNS или другой настроенный механизм разрешения имени. DNS-ответ сам по себе не подтверждает личность HTTPS-сервера.
Клиент устанавливает TCP-соединение, обычно с портом 443. Доступность порта ещё не означает, что TLS проверен.
Клиент и сервер выполняют TLS-handshake: согласовывают параметры и ключи, сервер подтверждает владение соответствующим закрытым ключом, а клиент проверяет сертификат.
После успешного handshake клиент передаёт HTTP-запрос внутри защищённого соединения и получает HTTP-ответ.

Предположим, браузер запрашивает путь /account у сайта example.com по HTTPS. После успешного установления защищённого соединения промежуточный наблюдатель не сможет прочитать путь, HTTP-заголовки и тело ответа без доступа к ключам. При этом IP-адреса, размеры пакетов и время передачи остаются видимыми. Имя сервера в обычном расширении SNI сообщения ClientHello также может быть открыто, если не используется его шифрование.

Эта схема не является описанием всех версий HTTP. HTTP/2 тоже может работать поверх TLS и TCP, а HTTP/3 использует QUIC. В HTTP/3 TLS 1.3 используется внутри QUIC, поэтому схема TCP → TLS → HTTP к нему не относится. Границу модели определяет RFC 9001; для HTTP/3 нельзя просто искать отдельный TCP-handshake.

Как проходит TLS 1.3 handshake

Handshake — начальный обмен сообщениями, в котором стороны выбирают параметры защиты, получают общие криптографические секреты и подтверждают, что обмен не был подменён. Ни один из этих секретов не передаётся в виде готового симметричного ключа для HTTP-трафика.

Упрощённая последовательность полного TLS 1.3 handshake с аутентификацией сервера выглядит так:

Полный TLS 1.3 handshake: после ClientHello и ответа сервера клиент проверяет цепочку доверия и имя; только при успехе стороны завершают handshake и переходят к HTTP по защищённому каналу

ClientHello. Клиент объявляет поддерживаемые версии TLS, наборы алгоритмов и материал для обмена ключами (key_share). Обычно здесь присутствует расширение SNI с именем сервера, к которому обращаются. При необходимости указываются поддерживаемые протоколы приложения через ALPN.
ServerHello. Сервер выбирает согласуемые параметры и присылает свой материал для обмена ключами. По результатам обмена стороны независимо вычисляют общий секрет и выводят ключи защиты handshake. В TLS 1.3 следующие сообщения сервера, включая сертификат, уже передаются под защитой ключей handshake.
EncryptedExtensions, Certificate и CertificateVerify. Сервер сообщает расширения, присылает сертификат и криптографически доказывает владение закрытым ключом, соответствующим открытому ключу сертификата. Проверка подписи CertificateVerify не заменяет проверку доверия к сертификату и имени узла.
Finished сервера и клиента. Каждая сторона проверяет криптографическое подтверждение согласованного обмена. Клиент также выполняет применимые проверки сертификата и имени сервера до того, как доверять соединению.
Данные приложения. Стороны переходят к передаче HTTP-сообщений с использованием ключей приложения.

TLS 1.3 защищает данные приложения симметричными ключами, выведенными из секретов согласования. Это позволяет эффективно шифровать поток после установления соединения. Открытый ключ из сертификата не используется как ключ для непосредственного шифрования каждого HTTP-запроса.

Подробные последовательности и вывод секретов описаны в RFC 8446, разделы 2, 4 и 7. Здесь показано новое соединение с серверным сертификатом. При возобновлении сессии стороны могут использовать ранее согласованный ключ (PSK), и серверу не требуется заново отправлять сертификат. Ранние данные 0-RTT могут передаваться до завершения нового handshake, но для них нужно учитывать риск повторного воспроизведения запросов.

В соединении с аутентификацией по сертификату согласование ключей обеспечивает конфиденциальность обмена, а проверка сертификата связывает этот канал с ожидаемым сервером. Одного шифрования недостаточно, чтобы подтвердить, с кем именно вы обмениваетесь данными.

Что такое TLS-сертификат и зачем он нужен

Сертификат HTTPS-сервера обычно использует формат X.509. Он связывает открытый ключ с идентификаторами сервера и содержит сведения для проверки цепочки доверия. Сам сервер хранит соответствующий закрытый ключ и с его помощью подтверждает владение ключевой парой. Закрытый ключ в сертификат не включают и передавать клиенту его нельзя.

У сертификата есть несколько важных полей:

Поле или расширение	Зачем проверять
`Subject Alternative Name` (SAN)	Для каких DNS-имён или IP-адресов выдан сертификат
`Subject Public Key Info`	Какой открытый ключ связан с сертификатом
`Issuer` и цифровая подпись	Указанный издатель и подпись, которую проверяют открытым ключом издателя
`Not Before` и `Not After`	В какой период сертификат действителен
`Key Usage` и `Extended Key Usage`	Разрешён ли ключ для требуемого назначения

Это не полный список проверок. Формат и алгоритм проверки пути сертификации описаны в RFC 5280.

Что означает доверенная цепочка

Сервер обычно предъявляет конечный сертификат и промежуточные сертификаты. Клиент пытается построить путь к доверенному корневому центру сертификации (CA) из своего хранилища доверия, проверяет подписи и ограничения сертификатов, срок действия и применимые правила проверки. Доверенный корневой сертификат не обязан приходить от сервера в составе цепочки: клиент уже может иметь его локально.

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

Как проверяется имя сайта

Предположим, вы открываете сайт example.com по HTTPS. Сертификат должен подходить именно для идентификатора example.com, а не просто быть подписан доверенным CA. Имя DNS для проверки берут из расширения Subject Alternative Name (SAN), а не из поля Common Name (CN). Актуальные правила для идентификаторов и сопоставления DNS/IP изложены в RFC 9525, разделы 4 и 6; поле CN не следует использовать вместо SAN в новых реализациях по этому стандарту.

DNS-имя и IP-адрес в сертификате — разные виды идентификаторов. Если клиент подключается по HTTPS к IP-адресу 127.0.0.1, одного DNS:localhost в SAN для проверки IP-адреса недостаточно. Для IP требуется соответствующий идентификатор iPAddress в SAN.

Проверка сертификата включает проверку цепочки доверия и соответствия имени сервиса. Обе проверки необходимы: доверенный сертификат для другого домена не подтверждает тот узел, к которому вы обращаетесь. Кроме имени и цепочки клиент учитывает назначение ключа и ограничения сертификата; проверка отзыва зависит от политики и возможностей конкретного клиента.

Как проверить TLS и сертификат через OpenSSL

Для диагностики доступного HTTPS-сервера удобно использовать утилиту openssl s_client. Она показывает согласованные параметры TLS и результат проверки предъявленного сертификата. Для примера понадобится OpenSSL 3.x и возможность соединиться с example.com:443. В примере используется домен example.com. Версия TLS, сертификат и набор шифров могут меняться в зависимости от сервера и момента подключения.

Сначала узнайте версию утилиты:

openssl version

Затем установите TLS-соединение:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -brief

Назначение параметров:

Параметр	Что проверяет или задаёт
`-connect example.com:443`	Адрес и порт TCP-соединения
`-servername example.com`	SNI: имя виртуального сервера, для которого запрашивается сертификат
`-verify_hostname example.com`	Имя, которое клиент должен сопоставить с сертификатом
`-verify_return_error`	Остановка соединения при ошибке проверки сертификата
`-brief`	Краткий диагностический вывод вместо подробной трассы

Опция -verify_hostname проверяет имя в сертификате, а -verify_return_error завершает соединение при ошибке проверки. Назначение ключей и особенность s_client — продолжать работу при некоторых ошибках проверки без -verify_return_error — описаны в официальной справке OpenSSL 3.5.

Ищите в выводе поля Protocol version, Ciphersuite, Verification и, если выводится, Verified peername. Значения зависят от настроек сервера и клиента. Сообщение Verification: OK означает, что проверки сертификата в данном запуске прошли; одно лишь CONNECTION ESTABLISHED этого не подтверждает. Если утилита продолжает ожидать ввод после вывода результата, завершите соединение сочетанием Ctrl+C.

Что делать, если проверка не прошла

Если утилита сообщает об ошибке разрешения имени или подключения, сперва проверьте DNS, доступность сети и порт. До успешного TLS-handshake вы ещё не получили свидетельства о подлинности сервера.

Если проблема в сертификате, различайте два случая. Например, OpenSSL может сообщить hostname mismatch при несовпадении имени или unable to get local issuer certificate, когда клиент не может построить доверенную цепочку:

Недоверенная цепочка — у клиента нет подходящего доверенного CA, отсутствует промежуточный сертификат или проверка нарушена по другой причине. Уточните, какие центры сертификации действительно должны быть доверенными в вашем окружении.
Несовпадение имени — сертификат не подтверждает запрошенный DNS-идентификатор. Убедитесь, что -servername, -verify_hostname и имя, по которому вы планируете обращаться к сервису, соответствуют назначению сертификата.

Для HTTPS-сервера с собственным доверенным CA можно явно передать его PEM-файл через -CAfile, предварительно убедившись, что вы получили этот сертификат из доверенного источника. Отключение проверки сертификата скроет симптом, но не исправит нарушение доверия или несоответствие имени.

Чтобы воспроизвести эти случаи без зависимости от публичного сервера, используйте loopback-стенд XNova. Он создаёт временный CA и сертификат с SAN=DNS:localhost, запускает локальный TLS 1.3-сервер и проверяет успешное соединение, недоверенную цепочку и несовпадение имени. Инструкции и ожидаемый вывод находятся в README закреплённого коммита.

Эта команда исследует TLS, а не выполняет полноценный HTTP-запрос: отсутствие HTTP-статуса в выводе s_client нормально. Также она исследует TLS поверх TCP и не описывает QUIC-подключение браузера к HTTP/3.

Что HTTPS защищает и чего не гарантирует

TLS защищает HTTP-данные от чтения и незаметного изменения в пути, пока они передаются между конечными точками защищённого соединения. Он не исправляет ошибки сервера и не скрывает все сведения о сетевом обмене.

Успешная проверка сертификата не доказывает отсутствие уязвимостей в приложении. Подлинный HTTPS-сервер может отвечать с ошибкой 500, раскрывать лишние сведения, неправильно проверять права доступа или распространять вредоносное содержимое. Эти риски рассматриваются на уровне HTTP, приложения и его конфигурации.

Важно также определить границы TLS. Если соединение завершается на обратном прокси, между ним и конечным приложением может существовать другой канал. Защита браузерного HTTPS-соединения автоматически не распространяется на него.

Когда нужно оценить HTTPS-подключение, проверяйте три разных результата: согласованную версию и параметры TLS, доверие к цепочке сертификата и совпадение имени сервера. После этого переходите к HTTP-статусу, содержимому ответа и логике приложения. Такой порядок помогает не принимать ошибку TLS за ошибку HTTP и не считать рабочий сертификат доказательством безопасности всего сервиса.