TLS и SSL: одна задача, два названия
TLS (Transport Layer Security) работает между TCP и HTTP и превращает открытое соединение в закрытое. Если адрес начинается с https://, защищает его именно TLS; тот же протокол охраняет почту, DNS over TLS и большинство API.
SSL (Secure Sockets Layer) — то, с чего всё началось. Netscape выпустила SSL 2.0 в 1995 году и SSL 3.0 в 1996-м. Когда протокол перешёл к IETF, его переименовали: TLS 1.0 (1999) — по сути SSL 3.1. Затем появились TLS 1.1 (2006), TLS 1.2 (2008) и TLS 1.3 (2018).
Все версии SSL сегодня запрещены. SSL 3.0 пал под атакой POODLE в 2014 году и был официально запрещён в 2015-м; TLS 1.0 и 1.1 объявили устаревшими в 2021 году, когда браузеры уже от них отказались. Сегодня используются TLS 1.2 и TLS 1.3.
Старое название живёт в обиходе. Говоря «SSL-сертификат», имеют в виду сертификат, который предъявляет TLS-сервер; отдельных SSL- и TLS-сертификатов не существует. Это один и тот же файл X.509, и он работает с той версией протокола, о которой договорятся стороны. Если вам нужен сам сертификат, начните с материала о бесплатных SSL-сертификатах.
Что TLS гарантирует, а что нет
TLS даёт соединению три свойства.
Конфиденциальность. Всё, что идёт после рукопожатия, шифруется ключами, которые знают только две стороны. Тот, кто сидит в той же сети Wi-Fi, у провайдера или на транзитном канале, видит лишь зашифрованные байты.
Целостность. Каждая запись несёт код аутентификации. Изменённый по дороге байт обнаруживается, и соединение закрывается, вместо того чтобы передать приложению искажённые данные.
Аутентификация. Сервер доказывает, что владеет закрытым ключом сертификата, выпущенного на имя, которое запросил браузер. Именно это мешает злоумышленнику просто ответить вместо вас. Клиента тоже можно аутентифицировать — с помощью взаимного TLS (mTLS), — но в публичном вебе так делают редко.
Не менее полезно знать, чего TLS не делает. Он не скрывает, с каким сервером вы говорите: IP-адреса видны, как и домен в SNI (об этом ниже). Он не делает безопасным содержимое: SQL-инъекция приходит так же зашифрованной, как форма входа, и останавливать её — задача WAF. И он защищает данные только в пути: как только сервер их расшифровал, TLS больше ни при чём.
Рукопожатие TLS 1.2: два круговых обмена
Прежде чем уйдёт хотя бы один байт HTTP, браузер и сервер должны договориться о версии и шифре, проверить сертификат и вывести общие ключи. Эти переговоры и есть рукопожатие TLS (TLS handshake), и в TLS 1.2 они занимают два полных круговых обмена поверх TCP-соединения.
Первый обмен. Браузер отправляет ClientHello: поддерживаемые версии и наборы шифров, случайное значение и расширения вроде SNI и ALPN (какую версию HTTP он хочет). Сервер отвечает ServerHello (выбранные версия и шифр), своей цепочкой сертификатов и, при наборе с ECDHE, своей частью обмена ключами, подписанной ключом сертификата.
Второй обмен. Браузер проверяет сертификат, отправляет свою часть ключа, и обе стороны вычисляют одинаковые сеансовые ключи. Затем каждая отправляет Finished — контрольную сумму всего, что было сказано до этого момента. Если кто-то вмешался в рукопожатие, оно сорвётся именно здесь.
Только теперь может уйти первый запрос. Если учесть и рукопожатие TCP, новое HTTPS-соединение по TLS 1.2 тратит три круговых обмена, прежде чем браузер вообще сможет запросить страницу. При 20 мс на обмен этого никто не замечает; на мобильном канале со 150 мс между посетителем и сервером набегает почти полсекунды. Это одна из причин, по которым CDN завершает TLS на edge, а не на далёком origin: обмены, нужные рукопожатию, становятся короткими.
TLS 1.3: один обмен и меньше мест для ошибки
TLS 1.3 (RFC 8446, 2018) построен на одном наблюдении: браузер может угадать. Почти все серверы поддерживают одни и те же несколько групп обмена ключами, поэтому браузер кладёт свою часть ключа прямо в ClientHello, не дожидаясь вопроса.
Сервер выбирает шифр, отвечает своей частью ключа — и с этого момента ключи есть у обеих сторон. Всё, что идёт после ServerHello, включая сертификат, уже зашифровано. Браузер проверяет сертификат, отправляет Finished и сразу за ним — первый запрос: один круговой обмен на TLS, два вместе с TCP. В HTTP/3, где QUIC несёт TLS 1.3 внутри собственного рукопожатия, транспорт и шифрование вместе укладываются в один.
Если догадка не сработала — сервер хочет группу, для которой браузер не прислал ключ, — сервер отвечает HelloRetryRequest, и рукопожатие обходится в один лишний обмен. Поскольку X25519 предлагает практически любой браузер, такое случается редко.
Вторая половина TLS 1.3 — то, что из него убрали.
Обмена ключами RSA больше нет. Каждое рукопожатие использует эфемерный (EC)DHE, так что у каждого соединения есть прямая секретность: закрытый ключ, украденный через год, не расшифрует трафик, записанный сегодня.
Остались только шифры AEAD: AES-GCM и ChaCha20-Poly1305. Режима CBC, RC4, 3DES, SHA-1 и MD5 в протоколе нет вовсе.
Пересогласование и сжатие удалены, а вместе с ними — целые семейства атак.
Кроме того, TLS 1.3 защищён от понижения версии: сервер TLS 1.3, которого вынуждают перейти на старую версию, помечает свой ответ, и клиент TLS 1.3, увидев метку, обрывает соединение. Если обе стороны говорят на 1.3, они его и используют; никакой настройки «предпочитать 1.3» помнить не нужно.
0-RTT и возобновление сессии: короткий путь и его цена
Посетителю, который уже подключался, полное рукопожатие не нужно. В конце рукопожатия TLS 1.3 сервер может выдать браузеру сессионный билет (session ticket); в следующий раз браузер предъявляет его, и стороны пропускают сертификат и дорогое согласование ключей. Это возобновление сессии, и оно по-прежнему занимает один круговой обмен.
0-RTT (early data) идёт ещё дальше. С билетом браузер шифрует первый запрос ключами прошлой сессии и отправляет его в одном пакете с ClientHello. Сервер может ответить сразу, и запрос не ждёт никакого рукопожатия.
Цена — повторное воспроизведение (replay). Ранние данные уходят до того, как сервер сказал в этом соединении хоть слово, поэтому в них нет ничего свежего от сервера. Злоумышленник, записавший этот первый пакет, может отправить его снова, и сервер дважды увидит корректный запрос. Для GET таблицы стилей это безвредно; для POST, который оформляет заказ, переводит деньги или меняет пароль, — нет. К тому же у ранних данных нет прямой секретности: тот, кто позже добудет ключ билетов, сможет их расшифровать.
Отсюда правила. Принимайте 0-RTT только для идемпотентных запросов (GET и HEAD без побочных эффектов). Пусть сервер или прокси помечает запросы с ранними данными заголовком Early-Data: 1 и статусом 425 Too Early из RFC 8470, чтобы приложение могло отказаться их выполнять. И не считайте 0-RTT бесплатным ускорением, которое можно включить везде.
Edge CDN.com.tr не принимает ранние данные 0-RTT, поэтому вопрос повторного воспроизведения до вашего приложения просто не доходит. Вернувшийся посетитель возобновляет сессию с рукопожатием TLS в один круговой обмен.
Сертификаты и цепочка доверия
Сертификат — это способ, которым сервер доказывает, кто он. Сертификат связывает открытый ключ с одним или несколькими доменами, перечисленными в поле Subject Alternative Name, имеет срок действия и подписан удостоверяющим центром (CA).
Браузеры не доверяют вашему сертификату напрямую. Они доверяют нескольким десяткам корневых сертификатов из своего хранилища, а корневые не подписывают сертификаты сайтов сами: они подписывают промежуточные, и уже промежуточный подписывает ваш. Браузеру нужно построить путь от вашего сертификата до известного ему корня: конечный (ваш сертификат для www.example.com) → промежуточный (выпускающий сертификат CA) → корневой (в хранилище доверия).
От сервера ожидают, что он отдаст конечный сертификат и промежуточные. Забытый промежуточный сертификат — классическая поломка: настольные браузеры часто всё равно работают, потому что недостающий сертификат у них в кеше или они умеют его скачать, а curl, Android-приложения, платёжные колбэки и API-клиенты падают с ошибкой «unable to get local issuer certificate». Если что-то работает в браузере, но не с сервера, сначала проверьте цепочку.
Реальный пример: 7 октября 2026 года cdn.com.tr отдавал сертификат Let's Encrypt, подписанный промежуточным YR1, цепочка вела к ISRG Root YR, а сервер дополнительно отдавал Root YR с перекрёстной подписью ISRG Root X1 — корня, которому браузеры доверяют много лет. Именно перекрёстная подпись позволяет совсем новому корню работать на устройствах, которые о нём ещё не знают.
Срок действия. Сертификаты Let's Encrypt действуют 90 дней, и вся отрасль движется туда же: по правилам CA/Browser Forum, принятым в 2025 году, максимальный срок публичного сертификата сократился до 200 дней в марте 2026 года и к 2029 году составит 47 дней. Продление — больше не ежегодная рутина, а процесс, который должен работать сам.
DV, OV, EV. Уровень проверки говорит о том, что проверил CA (только контроль над доменом или ещё и организацию), а не о стойкости шифрования. Бесплатный сертификат с проверкой домена и дорогой EV-сертификат дают абсолютно одинаковое TLS-соединение.
SNI: много HTTPS-сайтов на одном IP
У раннего HTTPS была проблема курицы и яйца. Сервер должен предъявить сертификат во время рукопожатия, а домен, который нужен посетителю, приходит в HTTP-заголовке Host — уже после рукопожатия. Поэтому каждому HTTPS-сайту требовался собственный IP-адрес.
SNI (Server Name Indication) решает это, помещая домен в ClientHello. Сервер читает его до выбора сертификата — так один адрес может обслуживать тысячи HTTPS-сайтов, у каждого из которых свой сертификат. На этом держатся все CDN и весь виртуальный хостинг, и каждый браузер последнего десятилетия отправляет SNI.
У этого есть два следствия.
Клиент без SNI получает сертификат по умолчанию. Очень старые клиенты, некоторые встраиваемые устройства и скрипты, которые подключаются к IP-адресу, не указывая имя сервера, получают запасной сертификат сервера и падают на несовпадении имени. Тестируя через openssl, всегда передавайте -servername.
SNI не шифруется. Домен идёт открытым текстом внутри ClientHello, поэтому сеть может видеть — и фильтровать, — какой сайт вы открываете, хотя саму страницу не видит. Так работают блокировки по SNI. Скрывает его расширение Encrypted Client Hello (ECH), и браузеры начали его внедрять; пока оно не стало повсеместным, исходите из того, что домен виден.
Наборы шифров: как читать названия
Набор шифров (cipher suite) называет алгоритмы, которые использует соединение. В TLS 1.2 в одно название упаковано четыре решения.
ECDHE-RSA-AES128-GCM-SHA256 означает: обмен ключами ECDHE (эфемерный Диффи — Хеллман на эллиптических кривых, дающий прямую секретность), аутентификация RSA (тип ключа сертификата), шифрование данных AES-128 в режиме GCM (шифр AEAD: конфиденциальность и целостность за один шаг) и SHA-256 для выработки ключей.
Названия в TLS 1.3 короче, потому что обмен ключами и подпись согласуются отдельно, а наборов всего пять, из которых реально используются три: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 и TLS_CHACHA20_POLY1305_SHA256. Все они AEAD и все дают прямую секретность — настраивать больше нечего.
В хорошем списке TLS 1.2 наверху стоят обмен ECDHE и шифры AEAD, нет ничего с RC4, 3DES, MD5, NULL или EXPORT, и выбирает сервер по своему порядку, а не по порядку клиента. Старые наборы CBC часто оставляют в конце для совсем старых клиентов; когда выбирает сервер, современный браузер до них не доходит. Сканер перечисляет всё, что сервер предлагает; чтобы увидеть, что реальное соединение использует, смотрите на согласованный набор — командами в конце этого руководства.
ChaCha20-Poly1305 существует для устройств без аппаратного ускорения AES, в основном старых телефонов: программно он работает быстрее, чем AES-GCM.
Частые ошибки TLS и что они на самом деле значат
ERR_SSL_PROTOCOL_ERROR (Chrome): рукопожатие оборвалось так, что браузер не смог это классифицировать. Обычные причины: на порту 443 отвечает что-то кроме TLS (открытый HTTP, портал авторизации в гостевой сети), соединение перехватывает антивирус или сетевое устройство, либо у сервера нет сертификата для этого домена. Сначала попробуйте из другой сети; если ошибка только в одной, проблема не в сервере.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH, в Firefox — SSL_ERROR_NO_CYPHER_OVERLAP: у клиента и сервера нет ни общей версии, ни общего набора шифров. Сегодня это почти всегда значит, что одна из сторон очень старая — например, встраиваемое устройство, которое говорит только на TLS 1.0, или сервер, всё ещё настроенный под него.
ERR_CERT_COMMON_NAME_INVALID: в сертификате нет домена, который вы открыли. Типично, когда DNS уже направил новый поддомен на сервер, у которого для него ещё нет сертификата, или когда в сертификате не хватает www.
ERR_CERT_DATE_INVALID: срок сертификата истёк, или у посетителя неверные часы. Если ошибку видит один человек, проверьте его часы; если все — продление остановилось.
unable to get local issuer certificate (curl, OpenSSL и многие SDK): сервер не отдал промежуточный сертификат. Исправляйте цепочку на сервере, а не хранилище доверия на клиенте.
502 от прокси или CDN при действительном замке в браузере: TLS посетителя был в порядке, но не удалось собственное соединение прокси с вашим origin. Это отдельное рукопожатие со своим сертификатом и своими версиями; руководство по ошибке 502 Bad Gateway разбирает его по шагам.
Как CDN.com.tr завершает TLS на edge
Когда ваш сайт работает через CDN.com.tr, TLS-соединение посетителя завершается на edge-сервере CDN.com.tr, а не на вашем origin: сертификат хранит edge, и рукопожатие проводит тоже он. Так происходит для каждого домена, без настройки на уровне сайта, о которой можно забыть.
Только TLS 1.2 и TLS 1.3. TLS 1.0 и 1.1 отклоняются при рукопожатии, а не понижаются. Edge выбирает шифр из собственного списка, где первыми идут обмен ECDHE и шифры AEAD; в нашей проверке 7 октября 2026 года TLS 1.3 согласовал TLS_AES_256_GCM_SHA384 поверх X25519. Политика одинакова для всех аккаунтов, а подробности, которые спрашивают анкеты по безопасности, собраны на странице о политике TLS.
HTTP/3 для каждого сайта. HTTP/3 работает поверх QUIC со встроенным TLS 1.3. Браузеры узнают о нём из заголовка Alt-Svc и переходят при следующем соединении; ничего включать не нужно. Подробнее — в разделе HTTP/3 и IPv6.
Свой сертификат для каждого домена, выбор по SNI. Каждый ваш домен обслуживается со своим сертификатом.
Let's Encrypt: выпуск и продление за вас. С автоматическим SSL сертификат запрашивается, как только домен подтверждён и его DNS указывает на нас, и автоматически продлевается за 30 дней до истечения. Если DNS вашего домена находится в CDN.com.tr, сертификат может быть wildcard — он покрывает корневой домен и все поддомены первого уровня и подтверждается DNS-записью. Переносите работающий сайт? Мастер без простоя выпускает этот wildcard через TXT-запись у вашего текущего DNS-провайдера ещё до переключения, и HTTPS работает с первой секунды.
Собственный сертификат, если нужен. OV- или EV-сертификат, купленный в другом месте, можно загрузить и привязать к домену, и к нему применяется точно та же политика TLS.
Отдельное TLS-соединение до вашего origin. По умолчанию HTTPS-запрос и с origin забирается по HTTPS: edge открывает собственное соединение с HTTPS-портом вашего origin. Посетитель этого рукопожатия не видит; если оно не удалось, он получит 502, а не предупреждение о сертификате.
HSTS, когда будете готовы. Как только всё работает по HTTPS, предустановка безопасности HSTS велит браузерам больше никогда не пробовать открытый HTTP для вашего домена.
Проверьте TLS любого сайта за минуту
Пять команд отвечают на большинство вопросов о TLS: какую версию и шифр использует реальное соединение, какую цепочку отдаёт сервер, когда истекает сертификат, отклоняются ли старые версии и сколько длится рукопожатие. Замените www.example.com своим доменом и не убирайте -servername: без него вы проверите сертификат сервера по умолчанию, а не свой.
Версия, шифр, цепочка, срок действия и время рукопожатия из командной строки
# Согласованная версия и шифр
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher is"
# Цепочка, которую отдаёт сервер: владелец (s:) и издатель (i:) каждого сертификата
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9]+ s:|^ *i:"
# Когда истекает сертификат
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate
# TLS 1.1 должен быть отклонён (SECLEVEL=0 не даёт вашему OpenSSL отказаться первым)
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1 -cipher 'DEFAULT:@SECLEVEL=0' </dev/null
# Секунды до TCP и до TCP + TLS
curl -so /dev/null -w 'tcp %{time_connect} tls %{time_appconnect}\n' https://www.example.com/Частые вопросы
TLS и SSL — это одно и то же?
TLS — преемник SSL. IETF переименовала протокол, когда взяла его под своё крыло в 1999 году, так что TLS 1.0 — по сути SSL 3.1. Все версии SSL сегодня запрещены; когда говорят «SSL», почти всегда имеют в виду TLS, а «SSL-сертификат» — это просто сертификат, который предъявляет TLS-сервер.
TLS 1.2 всё ещё безопасен?
Да, если он правильно настроен: обмен ключами ECDHE, шифры AEAD вроде AES-GCM или ChaCha20-Poly1305 и никаких RC4, 3DES и экспортных наборов. Серверы продолжают предлагать его рядом с TLS 1.3 для старых клиентов. Отключать нужно TLS 1.0 и 1.1.
Ускоряет ли TLS 1.3 сайт?
Он ускоряет новые соединения: рукопожатие занимает один круговой обмен вместо двух, то есть каждое новое соединение экономит один сетевой обмен, что заметнее всего на медленных мобильных сетях. Саму передачу он не ускоряет: после открытия соединения TLS 1.2 и 1.3 передают данные практически с одинаковой скоростью.
Безопасно ли включать 0-RTT?
Только для запросов, которые можно повторить без вреда. Злоумышленник, перехвативший данные 0-RTT, может воспроизвести их снова, поэтому запрос, меняющий состояние, никогда не должен обрабатываться из ранних данных. Серверы, которые их принимают, должны ограничиваться безопасными методами и помечать такие запросы (заголовок Early-Data, статус 425), чтобы приложение могло отказать. Edge CDN.com.tr ранние данные не принимает.
Что такое SNI и видят ли его другие?
Server Name Indication — это домен, который браузер отправляет в начале рукопожатия, чтобы сервер выбрал нужный сертификат; благодаря ему один IP обслуживает много HTTPS-сайтов. Он передаётся открытым текстом, так что сеть видит, какой сайт вы открываете, но не страницу и не её содержимое. Скрывает его расширение Encrypted Client Hello (ECH).
Какие версии TLS поддерживает CDN.com.tr?
TLS 1.2 и TLS 1.3 на каждом домене, а также HTTP/3, который всегда работает на TLS 1.3. TLS 1.0 и 1.1 отклоняются. Политика одинакова для всех аккаунтов и не зависит от того, используете ли вы автоматический сертификат Let's Encrypt или загрузили собственный.
Нужно ли что-то менять на моём сервере ради TLS 1.3?
Для посетителей — нет. За CDN.com.tr их рукопожатие происходит на edge, поэтому они получают TLS 1.3 и HTTP/3, что бы ни работало на вашем origin. Origin участвует только в отдельном соединении от edge, где работают и TLS 1.2, и TLS 1.3.