Когда вы открываете интернет-банк, вводите пароль, отправляете сообщение через веб-сервис или просто заходите на сайт по HTTPS, данные обычно не передаются по сети в открытом виде. За защиту соединения отвечает TLS — Transport Layer Security.

Именно TLS позволяет браузеру договориться с сервером о шифровании, проверить его подлинность и создать защищённый канал передачи данных.

Современная версия протокола — TLS 1.3. По сравнению с предыдущими поколениями она получила более компактную схему установления соединения, отказалась от ряда устаревших криптографических механизмов и сделала Forward Secrecy обязательным свойством публичного обмена ключами.

Разберёмся, что происходит с момента, когда пользователь вводит адрес сайта, и до появления страницы в браузере.

Что такое TLS

TLS — криптографический протокол для защиты соединения между двумя сторонами.

В типичном случае это:

браузер → веб-сервер

Но TLS используется далеко не только в браузерах. Он применяется в API, мобильных приложениях, почтовых протоколах, системах обмена сообщениями и многих других сетевых сервисах.

У TLS три основные задачи:

1. Конфиденциальность. Посторонний участник сети не должен иметь возможности прочитать передаваемые данные.
2. Целостность. Данные не должны незаметно изменяться по дороге.
3. Аутентификация. Клиент должен иметь возможность проверить, что действительно связался с нужным сервером, а не с системой злоумышленника.

Именно сочетание этих свойств превращает обычное сетевое соединение в защищённый канал.

TLS и HTTPS — это не одно и то же

Эти понятия часто используют как взаимозаменяемые, хотя технически они обозначают разные вещи.

HTTP — протокол, по которому браузер и веб-сервер обмениваются запросами и ответами.

TLS — механизм защиты транспортного канала.

Когда HTTP работает поверх TLS, получается:

HTTPS = HTTP + TLS

Поэтому замок рядом с адресом сайта в браузере означает не наличие какого-то отдельного «протокола HTTPS-шифрования», а использование HTTP внутри защищённого TLS-соединения.

TLS при этом способен защищать и другие прикладные протоколы.

Что было бы без TLS

Представим публичную Wi-Fi-сеть без шифрования на уровне сайта.

Пользователь отправляет запрос:

POST /login

а вместе с ним — логин и пароль.

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

Без механизма проверки целостности злоумышленник может попытаться изменить передаваемые данные: например, подменить содержимое ответа сервера.

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

Простая аналогия

Работу TLS удобно представить как разговор в комнате с прозрачными стенами.

Все окружающие видят, что два человека общаются, но не должны понимать содержание разговора.

Перед началом разговора собеседники:

1. определяют правила защищённого обмена;
2. проверяют личность нужной стороны;
3. договариваются о секретах, из которых будут получены ключи;
4. после этого переходят на зашифрованное общение.

TLS делает примерно то же самое, только при помощи криптографии. Процесс первоначального согласования называется TLS handshake, или TLS-рукопожатие.

Что происходит, когда вы открываете HTTPS-сайт

Допустим, пользователь вводит: https://example.com

Перед загрузкой самой страницы браузеру необходимо установить защищённое соединение.

В упрощённом виде процесс выглядит так:

Браузер → сервер:
«Я поддерживаю TLS 1.3. Вот параметры, которые умею использовать, и информация для обмена ключами».

Сервер → браузер:
«Используем вот этот вариант. Вот мои параметры и сертификат».

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

Важно: стороны не пересылают по интернету готовый симметричный ключ в открытом виде.

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

Первый этап: ClientHello

Первое важное сообщение обычно отправляет клиент. Для сайта клиентом выступает браузер.

Сообщение называется ClientHello. В нём браузер сообщает серверу информацию, необходимую для начала переговоров.

Например:

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

Для TLS 1.3 клиент обычно сразу отправляет материал, который позволит выполнить обмен ключами быстрее. Именно это является одной из причин, по которой обычное установление TLS 1.3 может требовать меньше сетевых обменов, чем классический полный handshake TLS 1.2.

Затем отвечает сервер

Сервер анализирует ClientHello и выбирает параметры, которые поддерживают обе стороны.

Он отправляет ServerHello. После него значительная часть оставшихся сообщений handshake уже защищена шифрованием.

Это важное отличие TLS 1.3 от предыдущего поколения протокола: спецификация предусматривает шифрование сообщений handshake после ServerHello, уменьшая объём открыто передаваемой служебной информации.

Далее сервер может передать:

• зашифрованные расширения;
• сертификат;
• подтверждение владения ключом сертификата;
• сообщение Finished.

После успешной проверки handshake клиент отвечает своим Finished. Соединение готово к передаче данных приложения.

Откуда берётся общий секрет, если его нельзя просто отправить

Это один из самых интересных моментов TLS. Для стандартного публичного обмена ключами TLS 1.3 использует эфемерный механизм обмена, исторически связанный с Diffie-Hellman и эллиптическими кривыми.

На практике часто используется ECDHE — Elliptic Curve Diffie-Hellman Ephemeral.

Идея состоит в следующем. Клиент создаёт временную пару параметров. Сервер создаёт свою.

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

Наблюдатель, записавший сетевой обмен, не получает сам закрытый материал, необходимый для простого вычисления этого секрета. Дальше из полученного секрета TLS выводит несколько отдельных ключей для разных этапов соединения.

Почему нельзя одним ключом шифровать всё подряд

Современные криптографические протоколы стараются разделять ключевой материал. TLS 1.3 использует механизм на основе HKDF — HMAC-based Extract-and-Expand Key Derivation Function.

Из исходных секретов выводятся отдельные ключи для различных задач. Например, отдельно защищается handshake, отдельно — прикладной трафик.

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

Зачем сайту сертификат

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

Он мог бы попытаться установить одно зашифрованное соединение с пользователем, а второе — с банком. Получились бы два прекрасно зашифрованных канала, но центральным участником обоих оказался бы злоумышленник.

Нужен механизм ответа на вопрос: «Откуда браузер знает, что сейчас разговаривает именно с нужным сайтом?»

Для этого в типичном HTTPS-соединении используются цифровые сертификаты.

Что находится в TLS-сертификате

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

В частности, проверяет:

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

Если критическая проверка завершается неудачно, браузер обычно показывает предупреждение о небезопасном соединении.

Кто такие центры сертификации

Браузеру нужен исходный набор организаций, которым он доверяет при проверке сертификатов. Такие организации называют Certificate Authorities, или центрами сертификации.

Операционные системы и браузеры имеют хранилища доверенных корневых сертификатов. Сертификат сайта обычно связан с одним из доверенных корней через цепочку сертификатов.

Упрощённо:

доверенный корневой CA
↓
промежуточный CA
↓
сертификат сайта

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

Сертификат не шифрует весь интернет-трафик

Популярное заблуждение заключается в том, что сертификат якобы является ключом, которым шифруются все данные сайта.

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

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

Чем симметричное шифрование отличается от асимметричного

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

При асимметричной криптографии используются связки открытого и закрытого ключей. Открытый ключ можно распространять. Закрытый должен оставаться секретным.

TLS комбинирует разные криптографические примитивы, поскольку они решают разные задачи. Это одна из причин, почему фраза «TLS шифрует данные сертификатом» слишком упрощает реальную архитектуру.

Какие алгоритмы шифрования использует TLS 1.3

TLS 1.3 заметно сократил число поддерживаемых вариантов по сравнению с TLS 1.2. Из стандарта убрали множество устаревших и проблемных механизмов.

Для защиты записей используются схемы класса AEAD — Authenticated Encryption with Associated Data. Они одновременно обеспечивают шифрование и проверку целостности защищённых данных.

Среди предусмотренных TLS 1.3 наборов шифров используются, в частности, варианты на основе:

• AES-GCM;
• ChaCha20-Poly1305;
• AES-CCM.

Конкретный алгоритм выбирается при согласовании соединения из вариантов, поддерживаемых клиентом и сервером.

Почему проверка целостности так важна

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

Поэтому современное шифрование должно обеспечивать не только секретность.

Получатель должен определить: эти данные действительно пришли в том виде, в котором их отправила другая сторона, или кто-то пытался их изменить?

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

Что такое Forward Secrecy

Одна из важных особенностей TLS 1.3 — Forward Secrecy, которую часто переводят как прямая секретность. Рассмотрим проблему.

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

Возникает вопрос: можно ли теперь расшифровать все старые записанные соединения?

В правильно реализованном TLS 1.3 при публичном обмене ключами — нет. Для отдельных соединений используются временные криптографические секреты.

Получение долгосрочного ключа сервера впоследствии не должно автоматически раскрывать старый сеансовый трафик. Именно это свойство называется Forward Secrecy.

Почему TLS 1.3 отказался от старого RSA key exchange

В старых конфигурациях TLS применялась схема, где клиент мог создавать секрет и шифровать его долгосрочным RSA-ключом сервера. У такого подхода была неприятная особенность.

Если злоумышленник:

1. заранее записал соединение;
2. позже получил закрытый RSA-ключ сервера,

он потенциально мог использовать его для восстановления старого сеансового секрета. TLS 1.3 отказался от статического RSA key exchange.

Асимметричный публичный обмен ключами в протоколе проектируется с обеспечением Forward Secrecy.

RSA при этом не исчез из мира сертификатов полностью: RSA может применяться для цифровых подписей в допустимых конфигурациях. Просто его роль изменилась.

Почему TLS 1.3 быстрее TLS 1.2

При открытии сайта значение имеет не только скорость шифрования, но и количество сетевых обменов перед отправкой полезных данных. Если сервер находится далеко, каждый дополнительный round trip добавляет задержку.

TLS 1.3 значительно переработал handshake и в обычном случае позволяет установить новое защищённое соединение за 1-RTT на уровне TLS.

В упрощённом виде:

Клиент → ClientHello + key share

Сервер → ServerHello + остальные параметры

После этого стороны уже могут перейти к защищённому обмену прикладными данными после завершения соответствующих шагов handshake. По сравнению с традиционным полным TLS 1.2 это уменьшает задержку при установлении соединения.

Особенно разница заметна в сетях с высоким ping.

А что такое 0-RTT

TLS 1.3 содержит ещё один механизм — 0-RTT, или early data. Он может использоваться при повторном соединении с сервером, с которым клиент уже взаимодействовал.

Идея очень привлекательна: отправить определённые прикладные данные сразу, не ожидая полного завершения нового handshake. Это сокращает задержку.

Но у 0-RTT есть важное ограничение безопасности. Early data не обладают всеми теми же свойствами защиты от повторного воспроизведения, что обычный трафик после завершённого handshake.

В чём риск 0-RTT

Представим запрос: GET /news

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

Теперь другой пример: POST /transfer-money

Повторная обработка уже может иметь серьёзные последствия. Поэтому приложения и серверы должны очень осторожно относиться к данным, допускаемым в 0-RTT.

0-RTT — не режим «сделать весь TLS ещё быстрее». Это специализированная оптимизация со своими компромиссами безопасности.

TLS 1.2 против TLS 1.3

Основные изменения удобно представить так:

Характеристика	TLS 1.2	TLS 1.3
Полный handshake	Обычно больше обменов	Упрощён
Устаревшие cipher suites	Много исторических вариантов	Значительная часть удалена
Статический RSA key exchange	Был возможен	Удалён
Forward Secrecy для публичного key exchange	Зависела от конфигурации	Предусмотрена архитектурой
Шифрование handshake	Частично открытый	После ServerHello основная часть защищена
AEAD	Поддерживался наряду с другими схемами	Используются AEAD-схемы
0-RTT	Нет в таком виде	Есть для возобновляемых соединений
Сложность конфигурации	Больше устаревших вариантов	Сильно сокращена

Главное преимущество TLS 1.3 состоит не в одном новом алгоритме.

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

Почему удаление старых алгоритмов повышает безопасность

Совместимость — полезное свойство, но у неё есть цена.

Если протокол поддерживает десятки старых алгоритмов, сервер может по ошибке оставить включённым слабый вариант.

Появляется больше:

• конфигурационных ошибок;
• несовместимых комбинаций;
• потенциальных downgrade-сценариев;
• устаревшего кода.

TLS 1.3 пошёл другим путём. Вместо бесконечного сохранения исторической совместимости многие старые решения были исключены.

Среди удалённых или фактически оставшихся в предыдущих версиях технологий — устаревшие схемы обмена ключами, старые алгоритмы и TLS-level compression. Это уменьшило поверхность потенциальных ошибок.

Может ли провайдер прочитать HTTPS-трафик с TLS 1.3

При корректно установленном HTTPS-соединении интернет-провайдер не получает открытое содержимое HTTP-запросов и ответов внутри TLS.

То есть он не должен видеть непосредственно:

• содержимое веб-страницы;
• пароль, отправляемый сайту по HTTPS;
• содержимое HTTP-заголовков внутри защищённого соединения;
• тело отправляемых HTTPS-запросов.

Но это не означает полной сетевой невидимости. Провайдер всё равно участвует в передаче пакетов и может наблюдать метаданные сетевого уровня.

Например:

• ваш IP-адрес;
• IP-адрес назначения;
• время соединения;
• объём переданных данных;
• продолжительность соединения.

Кроме того, видимость некоторых доменных и DNS-данных зависит от применяемых технологий, версии протоколов и способа разрешения имён. TLS защищает содержимое соединения, а не превращает интернет-трафик в полностью невидимый поток.

Скрывает ли TLS IP-адрес

Нет. Для доставки IP-пакета маршрутизаторам необходимо знать адрес назначения.

Поэтому обычный HTTPS с TLS не скрывает от сети IP-адрес сервера, с которым устанавливается соединение. Именно здесь TLS отличается от VPS.

У них разные задачи. TLS: защищает соединение между приложением и конечным сервисом. VPS: создаёт защищённый туннель от устройства до VPS-сервера и меняет видимый для внешних сайтов источник сетевого трафика.

Эти технологии могут работать одновременно.

Например: браузер → TLS внутри VPS-туннеля → VPS-сервер → HTTPS-сайт

VPS не отменяет TLS, а TLS не заменяет VPS.

Может ли VPS читать HTTPS-трафик

Если пользователь подключён к обычному VPS и затем открывает HTTPS-сайт, между браузером и сайтом по-прежнему работает TLS. VPS-провайдер передаёт этот трафик, но не получает автоматически доступ к открытому содержимому TLS-сессии.

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

Защищает ли TLS от вредоносного сайта

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

Например, злоумышленник зарегистрировал: my-bank-example.com и получил для него действующий сертификат. Соединение с таким сайтом может быть прекрасно зашифровано. Проблема в том, что пользователь изначально открыл неправильный домен.

Поэтому значок HTTPS нельзя воспринимать как знак: «этому сайту можно доверять».

Он означает другое: «соединение с данным сайтом защищено TLS и сертификат соответствует установленным требованиям».

Это принципиальная разница.

Защищает ли TLS от вирусов

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

Можно совершенно безопасно с точки зрения TLS скачать вредоносный файл по HTTPS. Канал будет защищён. Содержимое файла — вредоносным.

Это не противоречие, просто разные уровни безопасности.

Может ли TLS быть взломан

На практике чаще атакуют не современную криптографию TLS напрямую, а всё, что находится вокруг неё.

Например:

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

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

Почему TLS 1.3 не означает «абсолютную безопасность»

TLS решает конкретную задачу: защитить канал связи между участниками соединения от прослушивания, незаметной подмены и определённых видов атак.

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

Хорошая модель безопасности всегда состоит из нескольких слоёв. TLS — один из наиболее важных, но далеко не единственный.

Как понять, что сайт использует TLS

Для обычного пользователя самый простой ориентир — адрес: https://

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

Браузер прежде всего сообщает о свойствах соединения и сертификата, а не проводит полный аудит владельца ресурса.

Можно ли увидеть версию TLS самостоятельно

Да. Версию соединения можно посмотреть через инструменты разработчика браузера или специализированные средства анализа сети.

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

Что произошло с TLS 1.0 и TLS 1.1

Старые версии протокола сегодня считаются устаревшими. Современная инфраструктура ориентируется прежде всего на TLS 1.2 и TLS 1.3, при этом TLS 1.3 является актуальным поколением протокола.

Поддерживать очень старые версии «на всякий случай» небезопасно и обычно не требуется для современного веба. TLS 1.3 также содержит механизмы, которые уменьшают риск нежелательного отката соединения на более старую версию.

Актуальный стандарт TLS 1.3

TLS 1.3 появился как стандарт IETF в 2018 году в RFC 8446. Позднее спецификация получила уточнения.

Актуальная редакция стандарта сохраняет название TLS 1.3 и совместимость с существующими реализациями, но уточняет ряд требований — в частности, правила работы с key share, обновлением ключей и некоторыми аспектами безопасности.

Для пользователя это не означает появления «TLS 1.4». Протокол по-прежнему называется TLS 1.3. Меняется и совершенствуется его нормативное описание.

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

Теперь можно собрать весь процесс вместе. Пользователь открывает HTTPS-сайт. Браузер узнаёт IP-адрес сервера и устанавливает сетевое соединение. Затем начинается TLS handshake.

Клиент сообщает поддерживаемые параметры и передаёт материал для обмена ключами. Сервер выбирает совместимые параметры, отвечает своим key share и предоставляет данные для аутентификации. Клиент проверяет сертификат. Обе стороны получают общий секрет.

Из него выводятся ключи для различных этапов соединения. После завершения handshake HTTP-запросы и ответы передаются внутри защищённого TLS-канала.

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

Почему TLS 1.3 важен для обычного пользователя

Большинство людей никогда не настраивает TLS вручную. И именно так и должно быть.

Хорошая инфраструктура безопасности работает незаметно.

TLS 1.3 позволяет ежедневно:

• входить в аккаунты;
• отправлять сообщения;
• пользоваться банковскими сервисами;
• работать с облачными приложениями;
• передавать формы;
• обращаться к API;
• загружать файлы

через недоверенные сети, не передавая содержимое этих соединений обычным открытым текстом. Без TLS современный веб в привычном нам виде был бы практически невозможен.

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

Что означает TLS 1.3?

TLS 1.3 — современная версия протокола Transport Layer Security, предназначенного для создания защищённого канала между сетевыми приложениями. В интернете наиболее знакомое применение TLS — HTTPS.

Чем TLS отличается от SSL?

SSL — предшественник TLS. Современные защищённые интернет-соединения используют TLS, хотя выражение «SSL-сертификат» до сих пор широко применяется в разговорной речи и маркетинге.

Технически корректнее говорить о TLS и TLS-сертификатах.

TLS 1.3 шифрует весь интернет?

Нет. TLS защищает конкретное соединение между приложениями. Другие сетевые метаданные и соединения могут оставаться видимыми на соответствующих уровнях сети.

TLS 1.3 и HTTPS — одно и то же?

Нет. HTTPS — это HTTP, передаваемый через TLS. TLS может использоваться и другими протоколами.

Может ли провайдер увидеть пароль на HTTPS-сайте?

При корректно установленном TLS-соединении пароль, отправленный внутри HTTPS-запроса, не передаётся провайдеру в открытом виде. Но если сам сайт вредоносный, пароль получит владелец этого сайта — TLS от этого не защищает.

Зачем нужен сертификат, если данные уже шифруются?

Сертификат помогает клиенту аутентифицировать сервер. Без проверки личности стороны можно было бы создать зашифрованное соединение не с тем сервером.

Что лучше: TLS или VPS?

Это не конкурирующие технологии. TLS защищает соединение приложения с конкретным сервисом, а VPS создаёт дополнительный защищённый туннель между устройством и VPS-сервером. Они часто используются одновременно.

Нужно ли пользователю включать TLS 1.3 вручную?

В обычной ситуации — нет. Современные браузеры и серверы согласовывают версию TLS автоматически.

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

 

TLS 1.3 — одна из базовых технологий безопасности современного интернета. Когда пользователь открывает HTTPS-сайт, браузер и сервер за короткое время выполняют довольно сложный процесс:

согласовывают параметры → аутентифицируют сервер → получают общий криптографический секрет → выводят ключи → переходят к защищённому обмену данными.

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

TLS 1.3 сделал эту архитектуру компактнее и безопаснее по сравнению с предыдущими поколениями: из протокола убрали ряд устаревших механизмов, публичный обмен ключами получил Forward Secrecy, большая часть handshake стала скрыта после ServerHello, а полное установление нового соединения стало быстрее.

При этом TLS не следует воспринимать как универсальный инструмент безопасности. Он не делает сайт честным, не заменяет антивирус, не скрывает IP-адрес и не обеспечивает полную анонимность.

Его задача конкретнее — создать защищённый канал через сеть, которой нельзя полностью доверять.

И именно эту задачу TLS выполняет каждый раз, когда браузер открывает современный HTTPS-сайт.