SSL vs TLS

Замок в адресной строке видели все, а объяснить, что именно он подтверждает, может далеко не каждый владелец сайта. В панели хостинга услуга называется «SSL-сертификат», в статьях пишут про TLS, а в конфигурации веб-сервера встречаются обе аббревиатуры сразу.

Разберёмся сразу. Протокол SSL сегодня не работает нигде: все его версии официально выведены из употребления, и по данным SSL Labs поддержку сохраняют около 1% сайтов. Соединение защищает TLS, а слово «SSL» осталось привычным названием услуги. Актуальную версию TLS 1.3 по данным Qualys SSL Pulse на июнь 2025 года поддерживают 75,3% крупнейших сайтов.

Ниже разберём, чем отличаются протоколы, что происходит при установке соединения и почему сертификаты в 2026 году стали жить вдвое меньше.

SSL и TLS: два разных протокола или два названия одного

Что такое SSL и почему его официально запретили

SSL расшифровывается как Secure Sockets Layer, протокол защищённых сокетов. Его разработала Netscape в середине 1990-х, когда в интернете появились первые магазины и потребовался способ безопасно передавать номера карт. Версий было три, и до наших дней не дожила ни одна:

• SSL 1.0 публично так и не вышел, критические уязвимости нашли ещё до релиза;
• SSL 2.0 (1995) опирался на слабый алгоритм MD5 и был запрещён документом RFC 6176 в 2011 году;
• SSL 3.0 (1996) продержался дольше всех. В 2014 году появилась атака POODLE, которая позволяла расшифровывать защищённые cookies, принудительно откатив соединение к устаревшей версии. В 2015 году эту версию запретили документом RFC 7568.

Что изменилось, когда протокол передали в IETF

К концу 1990-х стало понятно, что протокол защиты соединений слишком важен, чтобы принадлежать одной компании. Разработку передали в IETF, международную организацию по интернет-стандартам, и в 1999 году появился TLS, Transport Layer Security. Первая версия была доработанным SSL 3.0, поэтому её иногда в шутку называют «SSL 3.1».

Дальше протокол развивался как открытый стандарт: TLS 1.1 (2006) закрыл уязвимости в режиме шифрования CBC, TLS 1.2 (2008) принёс алгоритмы SHA-256 и AES-GCM, а TLS 1.3 (2018) вышел после почти десяти лет работы при участии Google, Mozilla, Microsoft и Cloudflare.

Почему в панелях хостингов до сих пор пишут «SSL-сертификат»

Старое название оказалось живучее самого протокола: формулировка «купить SSL-сертификат» привычнее рынку, чем технически точная «купить TLS-сертификат». Даже библиотека OpenSSL, которая давно реализует именно TLS, сохранила историческое имя.

Здесь полезно развести три вещи, которые постоянно путают. Протокол описывает правила установки защищённого соединения, сегодня это TLS. Сертификат подтверждает, что сервер принадлежит владельцу домена. Реализация это библиотека, которая исполняет правила протокола в коде, например OpenSSL.

Разница важная. Уязвимость Heartbleed 2014 года в прессе часто называли дырой в SSL, хотя проблема сидела в коде OpenSSL и сам стандарт тут был ни при чём. Ошибка в реализации означает, что нужно обновить библиотеку, и не говорит о надёжности протокола.

Какие версии работают в 2026 году, а какие давно отключены

Выведены из употребления. Кроме обеих версий SSL, это TLS 1.0 и TLS 1.1: они формально устарели в марте 2021 года по RFC 8996, браузеры отключили их ещё в 2020 году, и обе прямо запрещены требованиями платёжного стандарта PCI DSS.

Работает, но считается запасным вариантом. TLS 1.2 формально не устарел, и правильно настроенный сервер на нём остаётся безопасным. Слова «правильно настроенный» несут здесь большую нагрузку: нужен обмен ключами только через ECDHE, современные наборы шифров, отключённые сжатие и ренеготиация.

Рекомендуемый стандарт. TLS 1.3. Показательно: громкие атаки последних пятнадцати лет, включая BEAST, CRIME, POODLE и Logjam, били по механизмам, которых в TLS 1.3 физически нет. Протокол собрали заново на сокращённом наборе возможностей. Рабочая конфигурация: TLS 1.3 основным, TLS 1.2 запасным для старых клиентов, остальное отключено явно.

Главные различия SSL и TLS в одной таблице

Что происходит за доли секунды до того, как откроется страница

Как браузер и сервер договариваются о шифровании

Перед обменом данными стороны проходят процедуру знакомства, которую называют handshake, то есть рукопожатие. У неё две задачи: договориться о способе шифрования и убедиться, что на другом конце находится именно тот сайт, который вы открывали. Сложность в том, что стороны видят друг друга впервые и договариваются по открытому каналу.

1. Приветствие клиента. Браузер отправляет список поддерживаемых наборов шифров, версию протокола и случайную последовательность байт.
2. Ответ сервера. Сервер выбирает набор шифров и отправляет свой сертификат вместе с собственной случайной последовательностью.
3. Проверка сертификата. Браузер проверяет его по цепочке доверия до корневого центра сертификации, список которых встроен в систему и в браузер. Если цепочка не сходится, соединение обрывается.
4. Обмен секретом. В схеме Диффи-Хеллмана общий секрет по сети не передаётся: каждая сторона вычисляет его сама из открытых данных собеседника и своего закрытого значения.
5. Переход на быстрое шифрование. Из общего секрета обе стороны выводят одинаковый симметричный ключ, которым шифруется весь дальнейший обмен.

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

Почему TLS 1.3 справляется за один круг обмена вместо двух

В TLS 1.2 на рукопожатие уходит два полных круга сообщений, и на медленном мобильном соединении это заметная задержка. TLS 1.3 сократил процедуру до одного круга: браузер сразу отправляет предполагаемые параметры для вычисления общего ключа, не дожидаясь ответа сервера. Экономия составляет порядка 100-300 миллисекунд на каждое новое соединение.

Для повторных визитов есть ещё более быстрый режим, 0-RTT: браузер использует сохранённый билет сессии и отправляет данные без ожидания ответа. Такие данные уязвимы к повторной отправке перехваченного запроса, поэтому режим применяют только для безопасных операций.

Изменился и состав протокола: из TLS 1.3 убрали устаревшие наборы шифров, обмен ключами без прямой секретности, сжатие и ренеготиацию. Меньше опций означает меньше способов случайно настроить сервер небезопасно.

DV, OV и EV: за что вы платите, когда заказываете сертификат

Сам протокол бесплатен и встроен в любой веб-сервер. Деньги берут за сертификат, точнее за проверку, которую центр сертификации проводит перед выпуском. Уровней проверки три:

• DV, Domain Validation. Подтверждается только управление доменом: письмом на служебный адрес, файлом на сайте или DNS-записью. Выпуск занимает минуты и часто бесплатен, подходит блогам, визиткам, внутренним сервисам.
• OV, Organization Validation. Дополнительно проверяется юридическое лицо: наименование, регистрационные данные, адрес. Занимает несколько дней, подходит корпоративным сайтам и ресурсам с личным кабинетом.
• EV, Extended Validation. Центр изучает документы и связывается с заявителем для подтверждения полномочий. Раньше такой сертификат подсвечивал название компании в адресной строке, сейчас индикатор убрали, но проверка осталась, поэтому EV берут банки и крупные магазины.

Отдельно от уровня проверки существует охват доменов, и его постоянно путают с уровнем доверия. Обычный сертификат закрывает один домен, WildCard закрывает домен вместе с поддоменами, SAN вписывает в один сертификат несколько разных доменов. Охват настраивается поверх любого уровня проверки.

В интерфейсе метки DV, OV и SAN стоят рядом на одной карточке, хотя отвечают за разные вещи.

Почему сертификат теперь живёт 200 дней вместо года

В апреле 2025 года CA/Browser Forum, объединение центров сертификации и разработчиков браузеров, принял документ Ballot SC-081v3: 29 голосов за и ни одного против. Он задаёт график сокращения максимального срока действия публично доверенных сертификатов:

• с 15 марта 2026 года максимум составляет 200 дней вместо прежних 398;
• с 15 марта 2027 года он опустится до 100 дней;
• с 15 марта 2029 года до 47 дней.

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

Бесплатные центры двигаются в ту же сторону и даже быстрее. Let’s Encrypt с 15 января 2026 года выдаёт сертификаты со сроком жизни около 160 часов, чуть больше шести суток, а по объявленному плану обычный срок сократится до 64 дней в феврале 2027 года и до 45 дней в феврале 2028-го.

Логика одна: чем короче живёт сертификат, тем меньше окно, в котором можно воспользоваться скомпрометированным ключом. Вывод для владельца сайта: ручное продление по напоминанию в календаре перестало быть рабочей схемой, нужен ACME-клиент и мониторинг сроков.

От чего TLS защищает, а от чего не защитит никогда

Что протокол действительно делает:

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

Что остаётся за его пределами:

• Добросовестность владельца сайта. Сертификат получить легко, в том числе мошенникам. По данным Anti-Phishing Working Group, уже в 2023 году более 90% фишинговых сайтов показывали пользователю замок. Замок говорит, что канал зашифрован, и ничего не говорит о том, кому вы отправляете данные.
• Безопасность сервера. При доступе к самому серверу злоумышленник читает данные уже после расшифровки.
• Качество приложения. Уязвимости в коде, слабые пароли администраторов и утечки через сторонние скрипты протокол не закрывает.

Пять сценариев, где TLS работает прямо сейчас

Сайты и HTTPS. Браузер проверяет сертификат и защищает пароли, платёжные данные и содержимое форм от перехвата в публичных сетях.

Электронная почта. Explicit TLS, он же STARTTLS, начинает соединение открытым и запрашивает переход на шифрование внутри протокола: порт 587 для SMTP, 143 для IMAP, 110 для POP3. Implicit TLS шифрует соединение с первого пакета на отдельном порту: 465, 993 и 995. Второй вариант надёжнее, при сбое соединение просто не установится.

Внутренние API и микросервисы. Здесь применяют mTLS, взаимный TLS: сертификаты предъявляют обе стороны, поэтому и сервер проверяет, кто к нему обращается. Подход используют в архитектурах Zero Trust.

VPN и удалённый доступ. Часть решений строит защищённый туннель поверх TLS: например, OpenVPN в этом режиме получает ту же проверку подлинности, что и обычный сайт на HTTPS.

Собственный сервер. Если сайт работает на вашем VPS, сертификат нужно получить и подключить к веб-серверу самостоятельно, например бесплатный от Let’s Encrypt для Nginx. Порядок такой: сначала нужен сервер, на котором работает сайт, затем к нему подключается сертификат. Арендовать VPS-сервер под такую задачу можно за несколько минут, а сертификат заказать в той же панели управления.

Казахстанский кейс: почему проверка сертификата важнее самого шифрования

С 17 июля 2019 года операторы связи начали рассылать абонентам сообщения с просьбой установить на все устройства корневой сертификат с сайта qca.kz. Установка стороннего корневого сертификата означает, что система начинает доверять всему, что им подписано: трафик продолжает шифроваться, однако расшифровать его может ещё одна сторона в середине канала. Это классическая схема атаки «человек посередине».

Производители браузеров отреагировали в течение месяца: Mozilla, Google, Apple и Microsoft заблокировали такие сертификаты в Firefox, Chrome, Safari и Edge. В декабре 2020 года последовала ещё одна попытка с тем же результатом.

Вывод простой: шифрование само по себе задачу не решает. Работает связка из двух механизмов, где шифрование закрывает содержимое, а проверка сертификата отвечает на вопрос, с кем вы обмениваетесь данными.

Для казахстанских проектов к этому добавляются два практических требования:

• Размещение внутри страны. Ресурс на домене .kz должен находиться на сервере в дата-центре на территории Республики Казахстан. При привязке домена к зарубежному IP-адресу регистрант получает предупреждение и 10 дней на исправление, после чего домен приостанавливают.
• Новые правила по персональным данным. С 12 июля 2026 года сбор, обработка и хранение персональных данных ограниченного доступа выполняются в центрах обработки данных на территории Казахстана. Передавать их разрешено только по защищённым каналам или в зашифрованном виде, а о нарушении безопасности нужно уведомить уполномоченный орган в течение рабочего дня.

Оба требования сходятся в одной точке: сайту на домене .kz нужен сервер внутри страны, а передаче данных нужен настроенный TLS. Serverspace размещает оборудование в алматинском дата-центре Halyk Kazteleport, поэтому виртуальный сервер в Казахстане закрывает требование к локации.

Частые ошибки при настройке TLS и как их исправить

Что дальше: постквантовое шифрование уже включено в вашем браузере

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

Ответ индустрии уже развёрнут. NIST утвердил постквантовый механизм обмена ключами ML-KEM в 2024 году, а браузеры внедрили гибридную схему X25519MLKEM768: она совмещает классический и постквантовый алгоритмы, и соединение остаётся защищённым, пока держится хотя бы один из двух. Chrome, Edge и Firefox согласовывают такой обмен по умолчанию.

К апрелю 2026 года больше двух третей клиентского трафика в сети Cloudflare использовало постквантовый обмен ключами. Интереснее обратная сторона: на соединениях в сторону собственных серверов компаний показатель держится около 10%, потому что браузеры и CDN обновились централизованно, а типичный сервер работает на той версии криптографической библиотеки, которая попала в базовый образ при сборке. Ещё одна деталь в пользу обновления: постквантовые механизмы стандартизируются только для TLS 1.3.

Что проверить на своём сайте сегодня

SSL как протокол свою историю закончил, любое защищённое соединение работает по TLS, а привычное слово в названии услуги осталось данью традиции. Если вы отвечаете за сайт, проверьте три вещи.

1. Версия протокола. Должны быть включены TLS 1.3 и TLS 1.2, остальное отключено явно. Проверяется публичным сканером за пару минут.
2. Автоматическое продление. С учётом сокращения срока до 200 дней убедитесь, что ACME-клиент настроен и действительно отрабатывает, а не падает молча.
3. Тип сертификата. Для личного проекта хватит бесплатного DV. Для сайта с оплатой и персональными данными имеет смысл рассмотреть OV или EV, а при нескольких доменах сразу заложить SAN.

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

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