TLS 1.3: как работает HTTPS-шифрование и почему сайты стали быстрее

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

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

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

TLS 1.3: что это и какую роль он играет в HTTPS

TLS расшифровывается как Transport Layer Security - "безопасность транспортного уровня". Его задача - создать защищённый канал между двумя участниками соединения. В случае обычного сайта этими участниками чаще всего становятся браузер пользователя и веб-сервер.

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

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

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

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

Именно поэтому выражения "HTTPS-шифрование" и "TLS-шифрование" часто используются почти как синонимы, хотя технически это разные уровни. HTTPS определяет, как браузер и веб-сервер обмениваются веб-данными, а TLS отвечает за безопасность канала, по которому этот обмен проходит.

Например, браузер может отправить запрос к странице, API или изображению по HTTP. Если используется HTTPS, перед отправкой этот трафик защищается механизмами TLS, а на стороне сервера расшифровывается после получения.

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

Какие данные защищает TLS

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

• содержимое открываемых страниц;
• логины и пароли;
• сообщения и комментарии;
• поисковые запросы;
• данные форм;
• запросы к API;
• передаваемые файлы;
• cookies и другие элементы HTTP-трафика.

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

Однако TLS не делает пользователя полностью анонимным. Наблюдатель всё ещё может видеть IP-адреса сторон соединения, объём передаваемых данных, время обмена и другие сетевые метаданные. Само содержимое HTTPS-трафика при этом остаётся защищённым.

Почему именно TLS 1.3

TLS развивался несколько десятилетий, и каждая новая версия исправляла недостатки предыдущих. TLS 1.3 был стандартизирован в 2018 году и стал существенной переработкой протокола, а не просто небольшим обновлением TLS 1.2.

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

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

Как работает HTTPS и устанавливается защищённое соединение

Когда пользователь вводит адрес сайта и нажимает Enter, браузер не начинает сразу передавать данные по HTTPS. Сначала он должен установить сетевое соединение с сервером, а затем создать защищённый канал с помощью TLS.

После определения IP-адреса сайта браузер подключается к серверу и запускает TLS handshake - процедуру, во время которой клиент и сервер согласовывают параметры будущего защищённого соединения.

Что происходит после ввода адреса сайта

В упрощённом виде процесс выглядит так: браузер находит IP-адрес домена через DNS, подключается к серверу и сообщает, какие версии TLS и криптографические параметры он поддерживает.

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

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

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

TLS handshake простыми словами

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

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

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

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

Как браузер проверяет сертификат сайта

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

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

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

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

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

Как стороны договариваются о ключах шифрования

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

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

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

После завершения проверки сервер и браузер подтверждают, что обе стороны вычислили правильные ключи и предыдущие сообщения не были изменены. Только затем соединение считается полностью установленным, и браузер может безопасно отправлять HTTP-запросы внутри HTTPS-канала.

Как TLS 1.3 шифрует данные

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

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

Симметричное и асимметричное шифрование

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

Поэтому TLS не пытается шифровать весь веб-трафик открытым ключом сертификата. После handshake браузер и сервер получают общие секреты и переходят на симметричное шифрование.

В TLS 1.3 используются современные алгоритмы аутентифицированного шифрования, например AES-GCM и ChaCha20-Poly1305. Они не только скрывают содержимое данных, но и позволяют проверить их целостность. Если зашифрованный пакет был изменён по пути, получатель сможет определить, что данные повреждены или подверглись вмешательству.

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

Зачем нужны временные ключи сессии

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

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

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

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

Что видит провайдер при HTTPS-соединении

Шифрование TLS защищает содержимое трафика, но не скрывает сам факт сетевого соединения. Провайдер по-прежнему должен понимать, куда направлять IP-пакеты, поэтому IP-адрес сервера остаётся видимым на сетевом уровне.

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

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

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

Почему перехваченный HTTPS-трафик нельзя просто расшифровать

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

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

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

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

TLS 1.3 против TLS 1.2: что изменилось

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

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

Более короткое рукопожатие

Одно из самых заметных изменений - сокращение TLS handshake.

В TLS 1.2 перед началом передачи данных клиенту и серверу часто требовалось выполнить несколько последовательных обменов сообщениями. Каждый такой обмен зависел от сетевой задержки между пользователем и сервером.

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

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

Удаление устаревших алгоритмов

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

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

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

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

Forward Secrecy как стандарт

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

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

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

Меньше вариантов - меньше ошибок

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

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

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

Поэтому TLS 1.3 безопаснее не только за счёт более современной криптографии, но и за счёт меньшего количества способов настроить соединение неправильно.

Почему TLS 1.3 сделал HTTPS быстрее

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

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

Что такое 1-RTT

RTT - Round Trip Time, время, необходимое пакету, чтобы пройти от клиента до сервера и получить ответ обратно.

Если RTT между браузером и сервером составляет 50 мс, каждый дополнительный обязательный раунд обмена добавляет примерно такую же задержку перед началом передачи данных.

Стандартное рукопожатие TLS 1.3 называют 1-RTT, потому что после ClientHello и ответа сервера стороны уже получают достаточно информации для завершения согласования ключей и перехода к защищённому обмену.

Для пользователя это означает, что браузер быстрее доходит до момента, когда может отправить первый полноценный HTTP-запрос.

Как работает возобновление сессии

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

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

В TLS 1.3 этот механизм интегрирован в новую модель обмена ключами и позволяет заметно сократить задержку повторного подключения.

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

Что такое 0-RTT

TLS 1.3 поддерживает ещё более быстрый режим - 0-RTT, или Early Data.

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

Получается, что дополнительный сетевой раунд перед отправкой запроса фактически исчезает.

Но у 0-RTT есть важное ограничение: такие данные потенциально подвержены повторному воспроизведению. Злоумышленник не сможет прочитать содержимое запроса, но в определённых условиях может попытаться повторно отправить уже записанные Early Data.

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

Насколько ускорение заметно пользователю

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

Совсем другая ситуация возникает при большой сетевой задержке. Например, пользователь может подключаться через мобильную сеть к серверу на другом континенте. Если RTT составляет 150 мс, устранение одного лишнего обмена уже экономит около 150 мс только на этапе установки защищённого соединения.

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

Именно поэтому оптимизация handshake особенно важна для современных веб-сервисов, которыми пользуются люди из разных регионов мира.

Почему скорость зависит не только от TLS

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

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

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

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

Заключение

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

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

При этом TLS 1.3 не делает соединение анонимным и не решает все проблемы скорости сайта. IP-адреса и некоторые сетевые метаданные остаются видимыми, а итоговая производительность зависит также от DNS, расстояния до сервера, CDN, HTTP/2 или HTTP/3 и качества самой сети.

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