Как работает HTTPS: принцип работы, устройство и порядок соединения

Как работает HTTPS — это не история про один «волшебный замок» рядом с адресом сайта, а последовательность вполне конкретных действий. Браузер находит сервер, устанавливает сетевое соединение, проверяет его цифровое удостоверение, договаривается о способе защиты и только после этого передаёт HTTP-запрос внутри зашифрованного канала.

HTTPS не просто «шифрует сайт». Он связывает HTTP, TLS и сетевые протоколы так, чтобы данные можно было передать серверу конфиденциально, с контролем целостности и проверкой подлинности сервера.

Ниже разберём путь от ввода адреса https://cio-navigator.ru/ до отображения страницы буквально по шагам. Сначала будет простая модель, затем — устройство HTTPS, TLS handshake, сертификаты, ключи, HTTP-запросы, ответы, особенности HTTP/2 и HTTP/3, повторное использование соединений и ограничения защиты.

Иерархия знаний по HTTPS

HTTPS
├── HTTPS: что это такое, как работает и зачем нужен протокол
├── Как работает HTTPS: принцип работы, устройство и порядок соединения
├── HTTPS, SSL и TLS: как работает шифрование и защита данных
├── Порт HTTPS — 443: какой порт использует протокол и зачем он нужен
├── HTTPS, TCP/IP, HTTP и FTP: как связаны сетевые протоколы
├── Как подключить HTTPS к сайту: установка, настройка и переход с HTTP
├── DNS over HTTPS (DoH): что это такое, как работает и как настроить
├── Проверка HTTPS: как протестировать протокол и исправить ошибки
└── HTTPS, DNS, SSH, FTP и API: чем отличаются сетевые протоколы

HTTPS — это не один отдельный процесс, а взаимодействие нескольких уровней. DNS помогает определить IP-адрес, транспортный протокол доставляет данные, TLS создаёт защищённый канал, а HTTP описывает, какой ресурс запросить и какой ответ вернуть. В классической модели между этими уровнями также участвуют TCP и IP.

Как работает HTTPS простыми словами

Если объяснять принцип работы HTTPS без сложной терминологии, браузер проходит примерно такую цепочку. Это базовая модель: в современных сетях часть этапов может объединяться, повторно использоваться или выполняться иначе, особенно при HTTP/3.

1. Пользователь вводит HTTPS-адрес.
2. Браузер определяет, к какому серверу обращаться.
3. Устанавливается сетевое соединение.
4. Начинается TLS handshake.
5. Сервер показывает сертификат.
6. Браузер проверяет сертификат.
7. Клиент и сервер договариваются о параметрах защиты.
8. Создаётся защищённый канал.
9. Браузер отправляет HTTP-запрос.
10. Сервер отправляет HTTP-ответ.
11. Обмен HTTP-данными продолжается внутри TLS.

Первый шаг — пользователь вводит URL, например https://cio-navigator.ru/. Схема https сообщает браузеру, что нужно использовать защищённый вариант веб-соединения, а не обычный HTTP.

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

После определения адреса браузер устанавливает транспортное соединение. В классической схеме HTTPS это TCP-соединение, но HTTP/3 использует QUIC поверх UDP. Поэтому утверждение «HTTPS всегда работает через TCP» слишком грубое.

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

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

Этап	Что происходит	Главный участник
URL	Браузер узнаёт схему, домен, путь и порт	Браузер
DNS	Домен сопоставляется с IP-адресом	DNS-резолвер
Соединение	Создаётся транспортный канал	Клиент и сервер
TLS handshake	Согласуются параметры защиты	Клиент и сервер
Сертификат	Проверяется личность сервера	Сервер и браузер
HTTP-запрос	Клиент просит ресурс	Браузер
HTTP-ответ	Сервер возвращает данные	Веб-сервер

HTTPS-соединение от начала до конца

На примере условного обращения к https://cio-navigator.ru/ путь можно представить так. Схема упрощена: реальная сеть может использовать кэши, CDN, прокси, HTTP/2 или HTTP/3.

Браузер
   ↓
DNS
   ↓
IP-адрес
   ↓
TCP
   ↓
TLS
   ↓
HTTP
   ↓
HTTPS-ответ
   ↓
Браузер

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

Практический пример

URL: https://cio-navigator.ru/
Схема: HTTPS
Домен: cio-navigator.ru
Путь: /
Стандартный порт: 443
Первый ресурс: HTML-документ главной страницы

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

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

Этап	Что происходит	Кто участвует
DNS	Определяется IP-адрес домена	DNS и клиент
TCP	Создаётся транспортное соединение	Клиент и сервер
TLS	Создаётся защищённый канал	Клиент и сервер
HTTP	Передаётся запрос ресурса	Браузер и веб-сервер
Ответ	Сервер возвращает данные	Веб-сервер и браузер

Это базовая модель, а не обязательная последовательность для любого современного соединения. DNS мог быть закэширован, TLS-сессия может возобновляться, а HTTP/3 вообще использует QUIC вместо классической пары TCP и TLS в привычном виде.

Из каких компонентов состоит HTTPS

Устройство HTTPS становится понятнее, если разделить его на уровни. Каждый уровень решает свою задачу: HTTP описывает веб-сообщения, TLS защищает их, TCP доставляет поток данных, а IP помогает пакетам найти путь между сетями.

HTTPS
│
├── HTTP — веб-запросы и ответы
│
├── TLS — защита соединения
│
├── TCP — транспортная передача
│
└── IP — адресация и доставка пакетов

Компонент	Задача	Что важно помнить
HTTP	Описывает запросы, ответы и ресурсы	Сам по себе не обязан шифровать данные
TLS	Шифрует поток, проверяет целостность и сервер	Это основной защитный слой HTTPS
TCP	Передаёт поток данных с контролем доставки	Не шифрует содержимое
IP	Адресует пакеты и помогает маршрутизировать их	Не отвечает за веб-формат и TLS

HTTP

HTTP — прикладной веб-протокол. Он определяет, как клиент просит ресурс и как сервер отвечает. HTTP отвечает за методы, заголовки, тело сообщения и коды состояния.

• Запрос сообщает серверу, что хочет клиент.
• Ответ содержит результат обработки.
• Методы описывают действие: GET, POST, PUT, DELETE и другие.
• Заголовки передают служебные параметры.
• Тело содержит данные, например HTML или JSON.
• Код состояния показывает результат: 200, 404, 500 и так далее.

GET / HTTP/1.1
Host: cio-navigator.ru
Accept: text/html

В этом примере браузер просит корневой ресурс сайта. В реальном HTTPS-соединении такой текст не отправляется открыто по сети: HTTP-сообщение передаётся внутри TLS-канала.

Практический пример API

GET /api/ HTTP/1.1
Host: cio-navigator.ru
Accept: application/json

TLS

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

Компонент	Задача
Шифрование	Скрывает содержимое HTTP-сообщений от постороннего наблюдателя
Проверка подлинности	Помогает убедиться, что клиент подключился к нужному серверу
Контроль целостности	Позволяет обнаружить изменение защищённых данных

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

TCP

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

TLS защищает данные, а TCP обеспечивает их транспорт. TCP не превращает обычный HTTP в HTTPS и не является протоколом шифрования.

TLS: «Содержимое должно быть защищено».
TCP: «Данные должны быть доставлены потоком».
IP:  «Пакеты должны найти адресата».

IP

IP отвечает за адресацию и маршрутизацию пакетов. Браузер не отправляет запрос «домену» в бытовом смысле: сначала домен сопоставляется с IP-адресом, а затем сеть доставляет пакеты по этому адресу.

домен
  ↓
DNS
  ↓
IP-адрес
  ↓
соединение с сервером

Подробное взаимодействие уровней TCP/IP, HTTP и HTTPS рассмотрено в статье HTTPS, TCP/IP, HTTP и FTP: как связаны сетевые протоколы.

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

Рассмотрим конкретный условный адрес https://cio-navigator.ru/. URL состоит из нескольких частей, и каждая влияет на дальнейшие действия браузера.

Часть адреса	Пример	Назначение
Схема	https	Указывает на защищённое веб-соединение
Домен	cio-navigator.ru	Имя нужного ресурса
Путь	/	Путь к ресурсу на сервере
Порт	443	Стандартный порт HTTPS

Порт :443 обычно не пишут, потому что браузер знает: для схемы HTTPS используется стандартное значение 443. Но адрес https://cio-navigator.ru:443/ явно указывает тот же порт и по смыслу эквивалентен обычному варианту.

Браузер разбирает URL

Схема URL определяет, какой протокол и какие правила нужно применять. Внешне адреса похожи, но их смысл различается.

https://cio-navigator.ru/
└── используется HTTPS, обычно порт 443

http://cio-navigator.ru/
└── используется обычный HTTP, обычно порт 80

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

DNS определяет IP-адрес

Доменное имя нужно сопоставить с IP-адресом. Для этого используется DNS — система имён, которая отвечает на вопрос: к какому сетевому адресу обращаться.

cio-navigator.ru
        ↓
       DNS
        ↓
    IP-адрес

DNS и HTTPS решают разные задачи. DNS ищет адрес, а TLS защищает последующее соединение. Обычный DNS не является частью TLS handshake. Отдельная технология DNS over HTTPS защищает сам DNS-запрос и рассматривается в статье DNS over HTTPS (DoH): что это такое, как работает и как настроить.

Практический пример

Домен: cio-navigator.ru
Результат DNS: IP-адрес сервера
Следующий шаг: подключение к найденному адресу

Устанавливается TCP-соединение

В классической модели HTTPS поверх TCP клиент сначала устанавливает TCP-соединение. Для этого используется упрощённое трёхстороннее рукопожатие.

Клиент → SYN → Сервер
Клиент ← SYN/ACK ← Сервер
Клиент → ACK → Сервер

Так стороны подтверждают готовность обмениваться данными и согласуют начальные параметры потока. Это ещё не TLS и не шифрование. После TCP handshake начинается TLS handshake.

Схема применима к классическому HTTPS поверх TCP. HTTP/3 использует QUIC поверх UDP и устанавливает транспортную и криптографическую часть иначе.

TLS handshake: как устанавливается защищённое соединение

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

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

Клиент                         Сервер
  │                              │
  │ ClientHello                  │
  ├─────────────────────────────>│
  │                              │
  │ ServerHello                  │
  │ Сертификат и параметры       │
  │<─────────────────────────────┤
  │                              │
  │ Проверка сертификата         │
  │ Согласование ключей          │
  │                              │
  │ Защищённый обмен TLS         │
  │<────────────────────────────>│

ClientHello

Клиент начинает handshake сообщением ClientHello. Браузер сообщает серверу, какие варианты соединения он поддерживает и какие параметры предлагает.

• поддерживаемые версии TLS;
• криптографические параметры;
• случайные значения;
• расширения протокола;
• имя сервера, к которому клиент обращается, например через SNI;
• дополнительные возможности, связанные с HTTP/2 или другими режимами.

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

Условный ClientHello

Клиент: поддерживаю TLS 1.2 и TLS 1.3
Клиент: вот список криптографических вариантов
Клиент: обращаюсь к cio-navigator.ru
Клиент: поддерживаю дополнительные расширения

ServerHello

Сервер отвечает сообщением ServerHello. Он выбирает версию TLS и набор параметров, которые одновременно поддерживаются обеими сторонами.

Клиент → ClientHello → Сервер
Сервер → ServerHello → Клиент

После этого сервер обычно передаёт сертификат и необходимые криптографические параметры. Конкретный состав сообщений зависит от версии TLS и выбранного сценария.

Сертификат сервера

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

В сертификате можно найти или проверить:

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

Если браузер открывает https://cio-navigator.ru/, он ожидает сертификат, подходящий для домена cio-navigator.ru. Сертификат для совершенно другого домена не подтверждает нужный сервер, даже если сам по себе он настоящий и подписан доверенным центром.

Проверка сертификата браузером

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

Проверка	Что проверяет	Возможная проблема
Домен	Подходит ли сертификат этому сайту	Сертификат выдан для другого имени
Срок	Не истёк ли сертификат и не слишком ли рано он используется	Просроченный сертификат
Цепочка	Можно ли доверять центру сертификации	Неизвестный или неподтверждённый издатель
Подпись	Не был ли сертификат изменён	Повреждённая или недействительная подпись
Дополнительные условия	Отозван ли сертификат и соблюдены ли ограничения	Сертификат отозван или нарушены правила

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

Ситуация

Пользователь открывает: https://cio-navigator.ru/
Сертификат предъявлен: для другого домена
Результат: браузер сообщает, что сертификат недействителен

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

Согласование ключей

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

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

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

Создание защищённого канала

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

Браузер
   │
   │ TLS
   ▼
Защищённый канал
   │
   ▼
Сервер

Практический результат handshake

До handshake: браузер и сервер ещё не обмениваются защищённым HTTP.
После handshake: можно передавать HTTP-запросы внутри TLS.

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

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

Этап	Тип механизма	Задача
Установление доверия и параметров	Асимметрическая криптография и цифровые подписи	Аутентификация сервера и согласование защиты
Передача данных	Симметричное шифрование	Эффективная защита большого объёма данных
Контроль целостности	Аутентифицированная защита сообщений	Обнаружение изменения или повреждения данных

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

Конкретные механизмы зависят от версии TLS и выбранного cipher suite. Подробное устройство криптографической части описано в статье HTTPS, SSL и TLS: как работает шифрование и защита данных.

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

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

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

Что происходит с HTTP-запросом

Браузер сначала формирует HTTP-сообщение. Затем TLS разбивает его на защищаемые фрагменты, шифрует и передаёт через сеть. Сервер принимает TLS-данные, проверяет их целостность и восстанавливает HTTP-запрос.

HTTP-запрос
     ↓
TLS
     ↓
зашифрованные данные
     ↓
сеть
     ↓
сервер
     ↓
TLS
     ↓
HTTP-запрос

Уровень	Что видит участник	Роль
Браузер	HTTP-запрос	Формирует обращение к ресурсу
TLS	Защищённые записи	Шифрует и проверяет данные
Сеть	Пакеты и метаданные соединения	Доставляет данные
Сервер	Восстановленный HTTP-запрос	Передаёт его веб-серверу или приложению

Как браузер отправляет HTTPS-запрос

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

GET / HTTP/1.1
Host: cio-navigator.ru
Accept: text/html

Строка GET / HTTP/1.1 означает запрос ресурса по пути / с использованием синтаксиса HTTP/1.1. Заголовок Host указывает домен, а Accept сообщает, какой тип содержимого предпочитает клиент.

Элемент	Значение	Смысл
Метод	GET	Получить ресурс
Путь	/	Корневой ресурс сайта
Версия	HTTP/1.1	Версия синтаксиса HTTP
Host	cio-navigator.ru	Имя запрошенного хоста
Accept	text/html	Предпочтительный тип ответа

В сети при HTTPS посредник не должен видеть эти строки в открытом виде. Он может видеть отдельные сетевые признаки соединения, но содержимое HTTP передаётся внутри TLS.

Что видит пользователь

Пользователь видит адрес https://cio-navigator.ru/, страницу и значок защищённого соединения. Внутренние сообщения ClientHello, ServerHello, сертификат и TLS-записи обычно скрыты от интерфейса, хотя технические сведения можно посмотреть в инструментах разработчика или диагностических программах.

Пользователь видит:
https://cio-navigator.ru/

Браузер дополнительно выполняет:
DNS → соединение → TLS handshake → HTTP-запрос

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

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

1. Сервер получает TLS-записи.
2. TLS проверяет целостность и обрабатывает поток.
3. Веб-сервер получает HTTP-запрос.
4. Приложение обрабатывает путь, параметры и заголовки.
5. Формируется HTTP-ответ.
6. Ответ снова передаётся через TLS.

Условный запрос к API

GET /api/ HTTP/1.1
Host: cio-navigator.ru
Accept: application/json

Сервер:
- принимает запрос;
- запускает обработчик API;
- формирует JSON;
- отправляет ответ внутри TLS.

Как сервер отвечает по HTTPS

Сервер формирует обычный HTTP-ответ, но отправляет его не открытым текстом, а через установленный TLS-канал.

HTTP/1.1 200 OK
Content-Type: text/html

<html>
...
</html>

Код 200 OK сообщает об успешной обработке. Заголовок Content-Type указывает тип содержимого, а тело содержит HTML-документ. TLS защищает передачу всего этого ответа между конечными точками защищённого соединения.

Часть ответа	Пример	Назначение
Версия и статус	HTTP/1.1 200 OK	Результат обработки запроса
Заголовок	Content-Type: text/html	Тип передаваемого ресурса
Тело	HTML-документ	Содержимое страницы

Путь HTTP-ответа

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

Приложение
    ↓
HTTP-ответ
    ↓
TLS
    ↓
TCP
    ↓
IP
    ↓
Интернет
    ↓
Браузер

Что происходит в браузере после получения ответа

Браузер принимает сетевые данные, передаёт их TLS-слою, получает HTTP-ответ и анализирует HTML. Затем он обнаруживает ссылки на дополнительные ресурсы и отправляет новые запросы.

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

Поэтому открытие одной страницы обычно означает не один HTTPS-запрос, а целую серию запросов к различным ресурсам. Часть из них может обслуживаться тем же соединением, а часть — другими доменами или CDN.

Пример HTTP-ответа страницы

Статус: 200 OK
Тип: text/html
Результат: браузер получил HTML и начал его разбирать

Почему HTTPS-запросов обычно много

Главная страница редко является одним-единственным файлом. HTML может ссылаться на таблицу стилей, скрипты, изображения, шрифты, видео и данные API. Браузер загружает эти ресурсы по мере обнаружения.

GET /
GET /style.css
GET /script.js
GET /image.webp
GET /font.woff2

Это иллюстрация, а не утверждение о конкретном наборе файлов сайта cio-navigator.ru. Реальный список зависит от структуры страницы, настроек сборки, кэша и подключённых сервисов.

Один сайт — множество HTTPS-соединений и запросов

Важно не путать соединение, запрос, ответ и ресурс. Эти слова описывают разные сущности.

Термин	Что означает	Пример
Соединение	Установленный канал между сторонами	TLS-сеанс клиента с сервером
Запрос	Обращение клиента к серверу	GET /style.css
Ответ	Сообщение сервера клиенту	200 OK и содержимое CSS
Ресурс	Файл или данные, которые загружаются	HTML, CSS, JS, изображение

Одно соединение может обслужить множество запросов, особенно при HTTP/2 и HTTP/3. И наоборот, одна страница может получать ресурсы с нескольких доменов, для которых потребуются отдельные соединения.

Условная загрузка страницы

Соединение A:
  GET /
  GET /style.css
  GET /script.js

Соединение B:
  GET /image.webp

Соединение C:
  GET /font.woff2

Как HTTPS защищает соединение от перехвата

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

Пользователь
     ↓
Злоумышленник
     ↓
Сервер

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

HTTPS защищает не от самого факта прохождения трафика через чужие сети, а от незаметного чтения и изменения содержимого защищённого соединения.

Пример с публичной Wi-Fi-сетью

Пользователь подключается к Wi-Fi в аэропорту или кафе и открывает сайт. Владелец точки доступа видит, что устройство устанавливает сетевое соединение, но при корректном HTTPS не должен видеть пароль, содержимое формы или HTML внутри TLS.

HTTP:
Пользователь → Wi-Fi → сервер
Содержимое может передаваться открыто

HTTPS:
Пользователь → TLS → Wi-Fi → сервер
Содержимое HTTP защищено TLS

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

Атака «человек посередине»

MITM-атака, или атака «человек посередине», происходит, когда злоумышленник пытается стать посредником между клиентом и сервером.

Пользователь
     ↕
Злоумышленник
     ↕
Сервер

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

Условная попытка подмены

Запрошен домен: cio-navigator.ru
Предъявлен сертификат: attacker.invalid
Результат: несоответствие домена, предупреждение браузера

Что именно защищает HTTPS во время передачи

Чтобы правильно понимать безопасность протокола HTTPS, нужно разделять содержимое соединения и метаданные. TLS защищает HTTP-данные, но не делает соединение невидимым для всей сетевой инфраструктуры.

Данные или свойство	Защищается TLS	Комментарий
Содержимое HTTP-запроса	Да	Передаётся внутри TLS
Пароль	Да, во время передачи	Хранение пароля — отдельная задача сервера
Cookie	Да, при передаче через HTTPS	Также важны флаги Secure, HttpOnly и SameSite
HTML	Да, при передаче	Содержимое ответа находится внутри TLS
URL-путь	Обычно да, в содержимом запроса	Остаются сетевые метаданные
IP-адрес сервера	Нет	Нужен для маршрутизации пакетов
Сам факт соединения	Нет	Соединение не становится невидимым

Например, при обращении к https://cio-navigator.ru/api/ TLS защищает HTTP-запрос и его путь от обычного сетевого наблюдателя. Но IP-адрес назначения всё равно нужен маршрутизаторам, а факт подключения и объём переданных данных могут быть заметны.

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

HTTPS и DNS: что происходит до TLS

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

https://cio-navigator.ru/
          ↓
        DNS
          ↓
       IP-адрес
          ↓
         TCP
          ↓
         TLS
          ↓
         HTTP

DNS не является частью TLS handshake. Он выполняет отдельную задачу — разрешение имени. После получения IP-адреса браузер может начинать соединение с сервером.

Где здесь DNS over HTTPS

DNS over HTTPS, или DoH, — это способ передать сам DNS-запрос внутри HTTPS-соединения к DNS-резолверу. Он защищает этап разрешения имени от некоторых видов наблюдения и вмешательства.

При этом DoH и HTTPS сайта — не одно и то же. DoH защищает DNS-запрос, а HTTPS сайта защищает дальнейший обмен браузера с веб-сервером. Подробнее — в статье DNS over HTTPS (DoH): что это такое, как работает и как настроить.

HTTPS и HTTP/2 и HTTP/3

HTTPS не равен конкретной версии HTTP. HTTPS описывает защищённый способ передачи веб-данных, а HTTP/1.1, HTTP/2 и HTTP/3 определяют разные варианты самого веб-протокола и его транспорта.

Версия	Типичная основа	Особенность
HTTP/1.1	TLS поверх TCP	Текстовая модель запросов и ответов
HTTP/2	TLS поверх TCP в вебе	Бинарный формат и мультиплексирование потоков
HTTP/3	QUIC поверх UDP	Транспорт и криптографические механизмы организованы иначе

HTTPS и HTTP/1.1

Классическая модель выглядит так: HTTP/1.1 передаёт запросы и ответы, TLS защищает поток, TCP обеспечивает транспорт, а IP маршрутизирует пакеты.

HTTP/1.1
    ↓
TLS
    ↓
TCP
    ↓
IP

HTTPS и HTTP/2

HTTP/2 обычно используется поверх TLS в современном вебе. Он позволяет передавать несколько логических потоков в рамках одного соединения и эффективнее работать с множеством ресурсов страницы.

HTTP/2
   ↓
TLS
   ↓
TCP
   ↓
IP

При этом сертификат, TLS handshake и базовая идея защищённого канала остаются важными. Меняется способ организации HTTP-обмена и транспортировки потоков.

HTTPS и HTTP/3

HTTP/3 использует QUIC, а QUIC работает поверх UDP. Поэтому к HTTP/3 нельзя механически применять схему «HTTPS → TCP». Упрощённое сравнение выглядит так:

HTTP/1.1
    ↓
TLS
    ↓
TCP

HTTP/2
    ↓
TLS
    ↓
TCP

HTTP/3
    ↓
QUIC
    ↓
UDP

Схема упрощена: QUIC включает собственные механизмы надёжной передачи и использует криптографию на базе TLS. Главное для читателя — HTTP/3 не строится как обычный HTTP поверх TCP.

Пример выбора транспорта

Если браузер и сервер договорились об HTTP/2:
HTTP/2 → TLS → TCP

Если договорились об HTTP/3:
HTTP/3 → QUIC → UDP

Что происходит при повторном посещении сайта

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

• Keep-alive позволяет сохранять соединение открытым.
• Повторное использование соединения уменьшает число новых handshake.
• TLS session resumption ускоряет повторное установление защиты.
• HTTP-кэш позволяет не скачивать неизменившиеся ресурсы.

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

TLS session resumption

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

Первое посещение:
DNS → соединение → полный TLS handshake → HTTP

Повторное посещение:
кэш или возобновление → сокращённый обмен → HTTP

Почему HTTPS не обязательно медленный

Старое представление «HTTPS всегда сильно тормозит» сегодня некорректно. TLS 1.3 сокращает число необходимых обменов, session resumption ускоряет повторные подключения, keep-alive уменьшает количество новых соединений, а HTTP/2 и HTTP/3 эффективнее работают с множеством ресурсов.

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

Полная схема работы HTTPS

Теперь соберём основные этапы в одну последовательность. Здесь показана расширенная учебная схема, объединяющая URL, DNS, транспорт, TLS и HTTP.

Пользователь
     │
     ▼
Браузер
     │
     │ https://cio-navigator.ru/
     ▼
DNS
     │
     │ IP-адрес
     ▼
TCP / QUIC
     │
     ▼
TLS
     │
     ├── ClientHello
     ├── ServerHello
     ├── Сертификат
     ├── Проверка сертификата
     ├── Согласование параметров
     └── Создание защищённого соединения
     │
     ▼
HTTP
     │
     ├── HTTP-запрос
     └── HTTP-ответ
     │
     ▼
Браузер
     │
     ├── HTML
     ├── CSS
     ├── JavaScript
     ├── изображения
     └── другие ресурсы

На уровне браузера пользователь вводит URL, а программа разбирает его части. На уровне DNS домен превращается в IP-адрес. Затем выбирается транспорт: TCP для классической схемы или QUIC для HTTP/3.

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

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

Чем отличается реальная работа HTTPS от упрощённой схемы

Учебная цепочка помогает понять принцип, но реальная сеть сложнее. В ней участвуют разные версии TLS и HTTP, кэши, CDN, прокси, балансировщики и обратные прокси.

• DNS-ответ может находиться в кэше браузера или операционной системы.
• HTML может быть взят из браузерного кэша.
• Соединение может быть уже открыто.
• Сервером для браузера может быть CDN, а не origin-сервер.
• Балансировщик может направить запрос на один из нескольких серверов.
• HTTP/3 может использовать QUIC вместо TCP.
• Прокси может менять маршрут и точку завершения соединения.

HTTPS через CDN и обратный прокси

Веб-сайт не всегда принимает TLS-соединение непосредственно на сервере приложения. Часто первым узлом является CDN или reverse proxy, который принимает запрос, завершает HTTPS, кэширует ответ или передаёт запрос дальше.

Браузер
   ↓ HTTPS
CDN / Reverse Proxy
   ↓
Веб-сервер
   ↓
Приложение

В таком случае HTTPS-соединение браузера может завершаться на CDN. Между CDN и внутренним сервером может существовать отдельное соединение — также защищённое или настроенное иначе. Поэтому выражение «браузер подключился к сайту» иногда означает подключение к инфраструктурному узлу, который обслуживает сайт от имени владельца.

Условный маршрут

Браузер → HTTPS → CDN
CDN → внутренний HTTPS → веб-сервер
Веб-сервер → приложение

HTTPS через прокси

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

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

Типичные ошибки в понимании работы HTTPS

Ошибки возникают, когда HTTPS смешивают с TLS, TCP, портом 443 или полной безопасностью сайта. Таблица помогает разделить эти понятия.

Заблуждение	Как правильно
HTTPS — это просто шифрование	HTTPS — защищённый способ передачи HTTP через TLS
HTTPS = SSL	Современный HTTPS использует TLS; SSL — устаревшее семейство протоколов
443 — номер HTTPS	443 — стандартный TCP-порт HTTPS
HTTPS полностью анонимен	HTTPS не обеспечивает полную анонимность
HTTPS защищает от всех вирусов	HTTPS не является антивирусом
HTTPS скрывает всё	TLS защищает содержимое, но остаются метаданные
Каждый запрос требует нового TLS handshake	Соединения и сессии могут переиспользоваться
HTTP/3 работает через TCP	HTTP/3 использует QUIC поверх UDP

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

Пример полного HTTPS-соединения

Рассмотрим сквозной условный сценарий для https://cio-navigator.ru/. Он показывает порядок работы HTTPS от ввода адреса до отображения страницы.

1. Пользователь вводит URL.
2. Браузер разбирает схему, домен, путь и стандартный порт.
3. DNS помогает найти IP-адрес.
4. Браузер устанавливает TCP-соединение или использует QUIC, если выбран HTTP/3.
5. Начинается TLS handshake.
6. Сервер отправляет сертификат.
7. Браузер проверяет домен, срок действия и цепочку доверия.
8. Клиент и сервер согласуют параметры и создают ключи сеанса.
9. Браузер отправляет HTTP-запрос GET /.
10. Сервер обрабатывает запрос и формирует HTTP-ответ.
11. TLS защищает ответ при передаче.
12. Браузер получает HTML и запрашивает дополнительные ресурсы.
13. После загрузки ресурсов браузер отображает страницу.

Шаг	Что происходит	Результат
1	URL введён	Браузер понимает, что нужен HTTPS
2	DNS	Найден IP-адрес
3	Соединение	Клиент связан с сервером
4	TLS handshake	Согласована защита
5	Сертификат	Подтверждена личность сервера
6	TLS	Создан защищённый канал
7	HTTP	Отправлен запрос
8	Сервер	Сформирован ответ
9	TLS	Ответ защищён
10	Браузер	Страница отображена

Сквозной пример

1. Введено: https://cio-navigator.ru/
2. Домен: cio-navigator.ru
3. Путь: /
4. Порт: 443 по умолчанию
5. DNS: домен сопоставлен с IP
6. TLS: проверен сертификат
7. Запрос: GET /
8. Ответ: 200 OK, text/html
9. Браузер: HTML разобран
10. Дополнительно: CSS, JavaScript, изображения и шрифты

Важная деталь: сертификат не шифрует HTML и не заменяет TLS-сеанс. Он помогает браузеру проверить принадлежность открытого ключа нужному домену. Сам обмен данными защищается ключами текущего TLS-соединения.

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

Короткие ответы ниже помогают закрепить последовательность, не заменяя подробное объяснение выше.

Как работает HTTPS простыми словами?

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

Что происходит при подключении к HTTPS-сайту?

Сначала разбирается URL и определяется IP через DNS. Затем устанавливается транспорт, выполняется TLS handshake, проверяется сертификат, создаётся защищённый канал, после чего отправляется HTTP-запрос.

Что происходит во время TLS handshake?

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

Зачем HTTPS проверяет сертификат?

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

HTTPS шифрует HTTP?

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

HTTPS работает через TCP?

Классическая модель HTTPS использует TCP: HTTP → TLS → TCP → IP. Но HTTP/3 использует QUIC поверх UDP, поэтому для него схема другая.

Почему HTTPS использует 443 порт?

443 — стандартный порт для HTTPS в классической модели. Это соглашение, а не «номер протокола» и не часть криптографии. Подробнее — в статье Порт HTTPS — 443: какой порт использует протокол и зачем он нужен.

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

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

Можно ли расшифровать HTTPS?

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

Заключение

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

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

HTTPS — это не один «магический» протокол, а взаимодействие HTTP и TLS поверх сетевой инфраструктуры. В классической модели в эту цепочку также входят TCP и IP, а при HTTP/3 вместо TCP используется QUIC поверх UDP.

URL
 ↓
DNS
 ↓
соединение
 ↓
TLS handshake
 ↓
сертификат
 ↓
защищённый канал
 ↓
HTTP-запрос
 ↓
HTTP-ответ
 ↓
браузер

Чтобы глубже разобраться в соседних аспектах, можно перейти к материалам HTTPS, SSL и TLS, статье про порт HTTPS — 443, разбору HTTPS и TCP/IP, руководству по проверке HTTPS и материалу о подключении HTTPS к сайту.