Когда вы открываете сайт по HTTPS, браузер не начинает сразу загружать страницу. Сначала ему нужно убедиться, что он действительно общается с нужным сервером, согласовать параметры защиты и получить ключи для шифрования. На всё это обычно уходят доли секунды.
Именно этим занимается TLS — Transport Layer Security.
TLS работает практически незаметно для пользователя, но без него современный интернет выглядел бы совсем иначе. Пароли, сообщения, формы, данные аккаунтов и содержимое веб-страниц можно было бы значительно проще перехватывать или подменять по дороге.
Актуальное поколение протокола называется TLS 1.3.
Разберёмся, как оно работает, не превращая объяснение в учебник по криптографии.
Что именно делает TLS
У TLS есть три основные задачи.
- Первая — шифрование. Данные между клиентом и сервером передаются в защищённом виде. Участник сети, который перехватит трафик, не должен получить его содержимое в открытом виде.
- Вторая — контроль целостности. Если кто-то попытается изменить защищённые данные по пути, принимающая сторона должна это обнаружить.
- Третья — аутентификация. Обычно браузер проверяет, что сервер действительно соответствует домену, который пользователь собирался открыть.
Именно эти свойства — конфиденциальность, целостность и аутентификация — лежат в основе TLS.
HTTPS и TLS — не одно и то же
Слова HTTPS и TLS часто используют рядом, поэтому их легко спутать. HTTP отвечает за обмен веб-запросами и ответами. TLS отвечает за защиту канала, по которому этот обмен идёт.
Упрощённо:
HTTPS = HTTP поверх TLS
Поэтому, когда браузер загружает страницу по HTTPS, HTTP-запросы не исчезают. Они просто передаются внутри защищённого TLS-соединения.
TLS при этом используется не только для сайтов. На него могут опираться API, почтовые протоколы, мобильные приложения и другие сетевые системы.
Что было бы без защищённого соединения
Представим, что пользователь отправляет форму входа:
login=alex
password=my-password
Если такой запрос передавать по сети открытым текстом, участник сети, имеющий возможность перехватывать пакеты, потенциально сможет увидеть эти данные. Проблема не ограничивается чтением.
Без криптографической проверки целостности можно пытаться менять ответы сервера прямо по дороге к пользователю. TLS создаёт защищённый канал именно для того, чтобы подобные действия не проходили незаметно.
Как начинается TLS-соединение
Первоначальное согласование называется TLS handshake.
По-русски часто говорят «рукопожатие». В этот момент клиент и сервер ещё не обмениваются обычными данными приложения в привычном режиме. Сначала им нужно договориться, как именно будет защищено соединение. Для сайта клиентом обычно является браузер. Сервером — веб-сервер.
Схема в сильно упрощённом виде выглядит так:
браузер → сервер:
«Вот какую версию TLS и криптографические параметры я поддерживаю».
сервер → браузер:
«Используем вот эти параметры. Вот информация для установления ключей и подтверждения моей подлинности».
После проверок обе стороны получают ключевой материал и переходят к защищённой передаче данных.
ClientHello: первое сообщение браузера
Handshake начинается с сообщения ClientHello. В нём браузер передаёт серверу набор параметров, необходимых для выбора режима соединения.
Среди них могут быть:
- поддерживаемые версии TLS;
- наборы шифров;
- поддерживаемые группы для обмена ключами;
- алгоритмы цифровой подписи;
- key share;
- дополнительные TLS-расширения.
Пользователь ничего из этого вручную не выбирает. За него это делает браузер или другое клиентское приложение.
Что отвечает сервер
Сервер анализирует ClientHello и выбирает совместимые параметры. Его ответ начинается с ServerHello.
В TLS 1.3 после ServerHello дальнейшая основная часть handshake уже шифруется. Это одно из важных отличий от TLS 1.2.
Дальше сервер обычно передаёт клиенту данные, необходимые для:
- завершения согласования;
- проверки сертификата;
- подтверждения владения соответствующим закрытым ключом;
- подтверждения целостности самого handshake.
После успешной проверки обе стороны завершают рукопожатие и получают возможность передавать прикладной трафик.
Как стороны получают общий секрет
На первый взгляд здесь возникает проблема. Чтобы шифровать данные, нужен секретный ключ. Но просто отправить этот ключ по интернету нельзя: его сможет перехватить тот, от кого соединение как раз и пытаются защитить. Поэтому TLS использует криптографический механизм согласования ключей.
В классических конфигурациях TLS 1.3 для этого применяются эфемерные механизмы Diffie-Hellman, в том числе ECDHE. Клиент и сервер обмениваются открытой криптографической информацией и независимо вычисляют общий секрет. Готовый секретный ключ в открытом виде по сети при этом не передаётся.
Почему в TLS используется не один ключ
После получения базового секрета TLS не использует его как универсальный ключ для всех операций. Из исходного материала создаются отдельные секреты и ключи для разных этапов соединения.
Для этого TLS 1.3 использует HKDF — HMAC-based Extract-and-Expand Key Derivation Function.
Разделение ключевого материала полезно с точки зрения криптографического проектирования: разные части протокола не зависят от одного и того же ключа напрямую.
TLS 1.3 переработал систему вывода ключей по сравнению с предыдущей версией именно с целью лучшего разделения ключевого материала и более удобного анализа безопасности.
Тогда зачем нужен сертификат
Шифрование ещё не отвечает на вопрос, с кем именно установлено соединение. Можно создать защищённый канал и со злоумышленником. Поэтому браузеру нужно проверить подлинность сервера. В обычном HTTPS для этого используется цифровой сертификат. Он связывает доменное имя с криптографическим ключом и входит в цепочку доверия, которую браузер может проверить.
Что проверяет браузер в сертификате
Проверок несколько. В частности, браузеру важно убедиться, что:
- сертификат подходит для запрошенного домена;
- срок его действия не истёк;
- подпись сертификата корректна;
- цепочка ведёт к доверенному центру сертификации;
- сервер способен подтвердить владение закрытым ключом.
Если критическая проверка не проходит, браузер обычно предупреждает пользователя.
Что такое центр сертификации
Certificate Authority, или CA, — организация, участвующая в выпуске и подтверждении сертификатов. В браузерах и операционных системах существуют хранилища доверенных корневых сертификатов.
Цепочка может выглядеть примерно так:
корневой сертификат
↓
промежуточный сертификат
↓
сертификат сайта
Браузер строит и проверяет эту цепочку, а затем решает, можно ли доверять предъявленному сертификату в контексте конкретного домена.
Сертификат не шифрует весь трафик
Это распространённое упрощение. Иногда можно встретить фразу: «сайт шифрует данные SSL-сертификатом». Технически она неточна.
Сертификат в HTTPS прежде всего участвует в аутентификации сервера и подтверждении владения ключом. Основной объём данных затем защищается симметричными алгоритмами, которые значительно лучше подходят для быстрого шифрования больших потоков информации.
Симметричная и асимметричная криптография
У этих подходов разные задачи.
При симметричном шифровании стороны работают с общим секретным ключевым материалом. Такой способ хорошо подходит для постоянной передачи больших объёмов данных.
В асимметричной криптографии используются открытые и закрытые ключи. Она удобна для цифровых подписей, аутентификации и ряда механизмов обмена ключами.
TLS объединяет несколько криптографических инструментов, а не пытается решить все задачи одной технологией.
Чем TLS 1.3 шифрует данные
TLS 1.3 серьёзно сократил набор допустимых алгоритмов по сравнению с предыдущими версиями. Для защиты записей используются только AEAD-механизмы — Authenticated Encryption with Associated Data.
Они одновременно обеспечивают:
- конфиденциальность данных;
- проверку их целостности.
В спецификации TLS 1.3 предусмотрены наборы шифров на основе таких алгоритмов, как AES-GCM, ChaCha20-Poly1305 и AES-CCM.
Важен не только выбор конкретного шифра, но и то, что старые и проблемные классы алгоритмов из нового протокола были исключены.
Зачем проверять целостность
Шифрование не должно ограничиваться сокрытием содержимого. Предположим, злоумышленник не понимает, что находится внутри пакета, но пытается изменить несколько байтов. Если получатель не способен обнаружить такую подмену, система остаётся уязвимой. Поэтому TLS должен гарантировать, что защищённые данные не были незаметно изменены между отправителем и получателем. Если криптографическая проверка записи завершается неудачно, такая запись не должна приниматься как корректная.
Что такое Forward Secrecy
Forward Secrecy можно перевести как «прямая секретность». Идею проще объяснить на примере.
Предположим, злоумышленник сегодня записывает зашифрованный трафик сервера. Через несколько лет ему удаётся получить долгосрочный закрытый ключ этого сервера.
В старых схемах обмена ключами такая ситуация могла позволить восстановить секреты ранее записанных соединений. TLS 1.3 устранил статический RSA и статический Diffie-Hellman из публичного обмена ключами. Его публичные механизмы key exchange обеспечивают Forward Secrecy.
Это означает, что компрометация долгосрочного ключа сервера в будущем не должна автоматически раскрывать старые сессии, построенные с корректным эфемерным обменом.
Почему RSA не исчез полностью
Здесь легко сделать неправильный вывод: «TLS 1.3 больше не использует RSA». Это не совсем так.
TLS 1.3 удалил статический RSA key exchange, но RSA может применяться для цифровых подписей при аутентификации в совместимых конфигурациях, то есть изменилась прежде всего роль RSA внутри протокола.
Почему TLS 1.3 быстрее предыдущей версии
При загрузке сайта задержка зависит не только от скорости шифрования. Очень важен RTT — время, которое требуется пакету, чтобы пройти до удалённой стороны и получить ответ. Если перед началом обмена данными нужно выполнить несколько последовательных сетевых циклов, задержка быстро накапливается.
TLS 1.3 перестроил handshake так, чтобы новое соединение обычно можно было согласовать быстрее, чем классический полный handshake TLS 1.2. Именно поэтому переход на TLS 1.3 дал не только криптографические, но и производительные преимущества.
Что такое 0-RTT
TLS 1.3 также поддерживает механизм 0-RTT, или early data. Он применяется не при первом знакомстве с сервером, а при определённых повторных соединениях, когда у клиента уже есть информация от предыдущей сессии.
В некоторых случаях клиент может отправить прикладные данные ещё до завершения нового handshake. Это уменьшает задержку, но здесь появляется компромисс.
Почему 0-RTT требует осторожности
Early data защищены слабее обычного трафика после полноценного handshake.
Актуальная спецификация TLS 1.3 подчёркивает два важных ограничения:
- для 0-RTT нет стандартной гарантии Forward Secrecy;
- между соединениями возможны replay-атаки.
Replay означает повторное воспроизведение ранее отправленного запроса.
Для запроса вроде:
GET /weather
повторение может оказаться безобидным.
А для действия вроде:
POST /purchase
повторная обработка уже способна иметь последствия.
Поэтому приложения не должны бездумно отправлять через 0-RTT операции, которые небезопасно повторять. 0-RTT — оптимизация задержки, а не «улучшенный режим TLS для всего подряд».
Чем TLS 1.3 отличается от TLS 1.2
Основные различия можно свести к следующему:
| Параметр | TLS 1.2 | TLS 1.3 |
| Структура handshake | Сложнее | Существенно упрощена |
| Статический RSA key exchange | Допускался | Удалён |
| Статический DH | Допускался | Удалён |
| Forward Secrecy | Зависела от выбранной схемы | Есть у публичных key exchange |
| Шифры | Было больше исторических вариантов | Оставлены современные AEAD |
| Handshake после ServerHello | Часть данных открыта | Сообщения зашифрованы |
| Вывод ключей | Старая схема | HKDF |
| 0-RTT | Нет | Поддерживается для определённых возобновлений |
| Compression внутри TLS | Была предусмотрена ранее | Удалена |
TLS 1.3 стал не просто «TLS 1.2 с более сильным шифром». Архитектуру протокола заметно упростили и избавили от ряда исторически накопившихся механизмов.
Почему меньше алгоритмов — это преимущество
На первый взгляд большой выбор кажется полезным. В криптографии он может создавать обратную проблему.
Если сервер поддерживает много устаревших комбинаций, возрастает вероятность:
- неправильной настройки;
- сохранения слабого алгоритма ради совместимости;
- ошибок реализации;
- неожиданного согласования нежелательного режима.
TLS 1.3 сознательно сократил количество допустимых вариантов. Например, были удалены статические RSA и DH cipher suites, TLS compression, DSA и ряд устаревших криптографических механизмов.
Что видит интернет-провайдер при HTTPS
TLS защищает содержимое соединения, но не делает сетевой трафик невидимым. При корректном HTTPS провайдер не должен получать в открытом виде:
- содержимое страницы;
- HTTP-заголовки внутри защищённого соединения;
- тело запросов;
- пароль, передаваемый через HTTPS-форму.
Но IP-пакетам всё равно нужно пройти через сеть. Поэтому провайдер способен видеть определённые сетевые метаданные, например:
- IP-адрес пользователя;
- IP-адрес назначения;
- время соединения;
- продолжительность;
- объём переданных данных.
Видимость доменных имён зависит от того, какие технологии используются для DNS и установления соединения. TLS защищает содержание канала, но не скрывает сам факт сетевого обмена.
Скрывает ли TLS IP-адрес
Нет. Обычный TLS не предназначен для маскировки сетевого адреса клиента или сервера. Маршрутизаторам нужен IP-адрес назначения, иначе пакет просто невозможно доставить. Это одно из различий между TLS и VPN.
TLS защищает связь между приложением и конечным сервисом. VPN создаёт отдельный защищённый туннель до VPN-сервера.
Как TLS работает вместе с VPN
Эти технологии не заменяют друг друга. Когда пользователь открывает HTTPS-сайт через VPN, схема выглядит примерно так:
браузер → TLS-соединение → внутри VPN-туннеля → VPN-сервер → сайт
Для сайта сохраняется TLS-соединение между браузером и веб-сервером. VPN добавляет ещё один слой защиты на участке между устройством и VPN-сервером.
Поэтому сравнивать их в формате «что лучше — TLS или VPN» не совсем корректно: они решают разные задачи.
Видит ли VPN-провайдер содержимое HTTPS
Обычный VPN-провайдер не получает автоматически возможность расшифровать HTTPS только потому, что трафик проходит через его сервер. TLS-сессия заканчивается на конечном сайте, а не на VPN-сервере.
VPN-провайдер потенциально может видеть часть сетевых метаданных, но содержимое правильно защищённого HTTPS-трафика остаётся зашифрованным.
Отдельный случай — TLS-инспекция.
Например, в корпоративной сети на устройство может быть специально установлен доверенный корневой сертификат, после чего промежуточная система фактически создаёт отдельные TLS-сессии с клиентом и удалённым сайтом. Это уже другая модель и требует доверия устройства к такому посреднику.
Означает ли HTTPS, что сайту можно доверять
Нет. Это одна из самых важных вещей, которую стоит понимать пользователю.
TLS подтверждает защищённость соединения и помогает установить, что сертификат соответствует домену. Но злоумышленник тоже может зарегистрировать собственный домен и получить для него действительный сертификат.
Например: example-secure-bank.com
Если сертификат для этого домена корректен, соединение может быть отлично защищено TLS. Проблема в том, что пользователь изначально пришёл не на сайт своего банка.
Поэтому HTTPS означает примерно следующее:
соединение с этим доменом защищено и аутентифицировано в рамках используемой инфраструктуры сертификатов.
Но это не равнозначно утверждению:
владелец сайта честный и безопасный. TLS не защищает от вредоносных файлов
По той же причине можно безопасно скачать вредоносную программу по HTTPS. Передача будет защищена от перехвата и незаметной подмены. Но сам файл останется вредоносным. TLS отвечает за канал связи, а не за анализ содержимого.
Что обычно атакуют вместо самого TLS 1.3
Современная криптография TLS достаточно хорошо изучена. В реальных инцидентах злоумышленнику зачастую проще атаковать другие элементы системы:
- украсть пароль;
- заразить конечное устройство;
- использовать уязвимость веб-приложения;
- получить доступ к серверу;
- провести фишинговую атаку;
- эксплуатировать ошибку реализации;
- воспользоваться неправильной конфигурацией.
Защищённый транспорт не исправляет уязвимость на одном из концов соединения.
Почему TLS не даёт полной анонимности
TLS не проектировался как средство анонимизации. Он защищает данные между двумя конечными точками. При этом сеть всё равно должна знать, куда доставлять пакеты.
Поэтому наблюдателю могут оставаться доступны:
- IP-адреса;
- время соединения;
- объём трафика;
- некоторые характеристики его структуры.
Для сокрытия или изменения части такой информации используются другие технологии.
Как понять, что сайт использует TLS
Самый простой признак — адрес начинается с: https://
Современный браузер также сообщает о состоянии соединения через элементы интерфейса рядом с адресной строкой. При этом браузеры постепенно ушли от идеи показывать HTTPS как некий «особо безопасный режим». Сегодня HTTPS считается нормой.
Гораздо важнее предупреждение, если браузер обнаружил проблему с защищённым соединением.
Можно ли посмотреть версию TLS
Да. Разработчик или системный администратор может проверить используемую версию через:
- инструменты браузера;
- серверные логи;
- сетевые анализаторы;
- специализированные TLS-тесты.
Обычному пользователю это, как правило, не требуется. Клиент и сервер согласовывают поддерживаемую версию автоматически.
Что стало с TLS 1.0 и TLS 1.1
Эти версии устарели и были официально выведены из использования. Современная инфраструктура ориентируется на TLS 1.2 и TLS 1.3. Актуальная спецификация TLS 1.3 прямо запрещает согласование TLS 1.0 и TLS 1.1.
Почему теперь встречается RFC 9846, а не RFC 8446
TLS 1.3 первоначально был стандартизирован в 2018 году как RFC 8446. В 2026 году был опубликован RFC 9846.
Он заменил RFC 8446, но не создал новую версию TLS. Протокол по-прежнему называется TLS 1.3.
RFC 9846 представляет собой обратно совместимое обновление спецификации: он уточняет ряд требований, исправляет неоднозначности и вносит отдельные технические изменения.
Среди изменений, например:
- запрет повторного использования KeyShare между соединениями;
- более строгие требования к обновлению ключей;
- уточнения вокруг session resumption;
- обновлённые правила для некоторых алгоритмов и сообщений;
- более общая формулировка механизма асимметричного обмена ключами, учитывающая развитие KEM.
Поэтому в современных технических материалах корректнее ссылаться на RFC 9846 как на актуальную спецификацию TLS 1.3.
Что происходит после ввода адреса HTTPS-сайта
Если собрать всё вместе, цепочка выглядит примерно так.
Пользователь вводит адрес сайта. → Браузер определяет IP-адрес и устанавливает сетевое соединение. → Затем отправляет ClientHello. → Сервер отвечает ServerHello и выбирает параметры TLS.
Стороны получают общий ключевой материал. → Сервер подтверждает свою подлинность. → Браузер проверяет сертификат и handshake.
После успешного завершения стороны переходят к защищённой передаче данных. Дальше HTTP-запросы и ответы идут внутри TLS.
И только после этого пользователь видит страницу.
Почему TLS 1.3 важен, хотя пользователь его не замечает
Хорошие механизмы безопасности часто почти невидимы. Пользователю не приходится каждый раз выбирать алгоритм, создавать ключ или вручную проверять цифровую подпись.
За него эту работу делают браузер, операционная система и сервер. TLS ежедневно защищает соединения, через которые проходят:
- формы авторизации;
- банковские операции;
- сообщения;
- API-запросы;
- облачные документы;
- данные мобильных приложений;
- содержимое веб-страниц.
Современный веб в значительной степени опирается на TLS как на базовый уровень транспортной защиты.
Частые вопросы
Что такое TLS 1.3 простыми словами?
Это протокол, который создаёт защищённое соединение между клиентом и сервером. Он шифрует передаваемые данные, контролирует их целостность и позволяет проверить подлинность удалённой стороны.
TLS и SSL — одно и то же?
Нет. SSL — старый предшественник TLS. Термин «SSL-сертификат» до сих пор используется в разговорной речи, но современные веб-соединения работают с TLS.
TLS 1.3 шифрует весь интернет?
Нет. Он защищает конкретные соединения приложений. IP-адреса, объём трафика и некоторые другие метаданные могут оставаться видимыми сети.
Может ли провайдер увидеть пароль, который я ввожу на HTTPS-сайте?
При корректном TLS-соединении содержимое HTTPS-запроса не передаётся провайдеру открытым текстом. Но если вы ввели пароль на мошенническом сайте, TLS не помешает самому владельцу этого сайта получить данные.
Зачем нужен сертификат?
Чтобы клиент мог проверить, с каким сервером он устанавливает защищённое соединение. Одного шифрования недостаточно: необходимо ещё аутентифицировать удалённую сторону.
TLS 1.3 быстрее TLS 1.2?
При установлении нового соединения TLS 1.3 обычно требует меньше последовательных сетевых обменов, поэтому способен уменьшать задержку.
Что такое 0-RTT?
Это механизм ускорения некоторых повторных TLS-соединений. Он позволяет передать определённые данные до завершения нового handshake, но обладает более слабыми свойствами безопасности и требует защиты приложений от replay-рисков.
TLS заменяет VPN?
Нет. TLS и VPN работают на разных уровнях и часто используются одновременно. TLS защищает соединение приложения с сервисом, а VPN создаёт туннель между устройством и VPN-сервером.
TLS 1.3 — это не просто «замок рядом с адресом сайта».
За несколько миллисекунд или долей секунды браузеру и серверу приходится решить сразу несколько задач: выбрать криптографические параметры, установить общий ключевой материал, подтвердить подлинность сервера и подготовить защищённый канал.
После этого прикладные данные можно передавать так, чтобы сетевой посредник не получил их содержимое в открытом виде и не мог незаметно изменить их по дороге. По сравнению с TLS 1.2 архитектура стала компактнее: из неё исключили ряд устаревших механизмов, публичный обмен ключами получил Forward Secrecy, оставшиеся после ServerHello сообщения handshake стали шифроваться, а набор допустимой криптографии был заметно сокращён.
При этом возможности TLS имеют чёткие границы. Он не скрывает IP-адрес, не превращает вредоносный сайт в безопасный, не проверяет скачиваемые файлы на вирусы и не обеспечивает анонимность.
TLS решает более конкретную задачу: защищает данные при передаче между участниками соединения через сеть, которой нельзя полностью доверять.
Именно поэтому он стал одним из фундаментальных механизмов безопасности современного интернета.