HTTPS, SSL и TLS часто упоминают вместе, хотя это не одно и то же. Когда вы открываете сайт, вводите пароль или отправляете номер заказа, данные проходят через несколько уровней защиты: HTTP отвечает за содержимое обмена, TLS создаёт защищённый канал, сертификат помогает проверить сервер, а криптографические ключи позволяют шифровать трафик.
HTTPS не делает сайт автоматически честным и безопасным, но помогает защитить данные во время передачи между браузером и сервером.
Ниже разберём, что такое SSL и TLS, почему современные сайты используют именно TLS, как работает шифрование HTTPS, зачем нужны сертификаты и ключи, что скрывает защищённое соединение, а какие сведения всё равно могут оставаться видимыми. Объяснение будет технически точным, но без обязательного погружения в математические формулы и криптографический фольклор.
- Иерархия знаний по HTTPS
- HTTPS, SSL и TLS — что это такое простыми словами
- Что означает HTTPS — расшифровка
- Что такое SSL
- Что такое TLS
- HTTPS, SSL и TLS: кто за что отвечает — Таблица
- Чем отличаются HTTP, HTTPS, SSL и TLS — Таблица
- HTTPS — это не просто «SSL-сертификат»
- SSL-сертификат и TLS-сертификат — почему названия путают
- Зачем HTTPS использует TLS
- Конфиденциальность — данные нельзя просто прочитать
- Целостность — данные нельзя незаметно изменить
- Аутентификация — браузер понимает, с каким сервером устанавливает соединение
- Как TLS шифрует данные
- Что такое открытый и зашифрованный текст — Пример
- Симметричное шифрование
- Асимметричная криптография
- Почему HTTPS использует сразу несколько криптографических механизмов
- Симметричное и асимметричное шифрование в HTTPS — Таблица
- Почему нельзя шифровать весь трафик только асимметричным шифрованием
- Что такое ключ шифрования в HTTPS
- Открытый ключ
- Закрытый ключ
- Сессионные ключи
- Как браузер и сервер приходят к общему секрету — Упрощённая схема
- Что такое сертификат HTTPS
- Какие данные содержит сертификат — Таблица
- Зачем сайту нужен сертификат
- Что делает удостоверяющий центр
- Как браузер проверяет сертификат — Порядок проверки
- Что происходит, если сертификат недействителен — Пример
- Как TLS подтверждает подлинность сервера
- Что такое цепочка сертификатов
- Зачем нужны промежуточные сертификаты
- Что происходит, если цепочка доверия нарушена
- Почему значок замка не означает «этому сайту можно доверять»
- Версии SSL и TLS — Таблица
- Почему SSL 3.0 больше нельзя использовать
- Почему TLS 1.0 и TLS 1.1 устарели
- TLS 1.2 — почему он до сих пор используется
- TLS 1.3 — что изменилось
- TLS 1.2 и TLS 1.3: в чем разница — Таблица
- Почему TLS 1.3 быстрее TLS 1.2
- Что такое Perfect Forward Secrecy и зачем она нужна
- Что произойдёт, если закрытый ключ сервера украдут
- Forward Secrecy — Пример
- Что именно шифруется при работе HTTPS
- Что видно злоумышленнику, а что скрыто — Таблица
- Можно ли взломать HTTPS
- Перехват HTTPS-трафика
- Атака «человек посередине» — Пример
- Почему просто перехватить HTTPS-пакеты недостаточно
- Когда HTTPS не спасает
- Как связаны HTTPS, TLS, сертификат и ключи — Схема
- Как SSL и TLS работают при открытии сайта — Пример
- Как TLS связан с HTTP/1.1, HTTP/2 и HTTP/3
- HTTP/1.1 + TLS
- HTTP/2 + TLS
- HTTP/3 + QUIC
- HTTPS и HTTP/1.1, HTTP/2, HTTP/3 — Таблица
- Какие алгоритмы используются в TLS
- AES
- ChaCha20-Poly1305
- ECDHE
- RSA
- Современные алгоритмы TLS — Таблица
- Почему говорят «SSL-сертификат», если используется TLS
- Что означает «установить SSL-сертификат»
- Мифы про HTTPS, SSL и TLS — Таблица
- Как связаны HTTPS, TLS, сертификат и шифрование — Полная схема
- Как HTTPS защищает пароль при отправке формы — Пример
- Как узнать версию TLS и сертификат сайта — Пример
- Проверка в браузере
- Инструменты разработчика
- Командная строка — Пример
- Что можно узнать при проверке
- Частые вопросы про HTTPS, SSL и TLS
- HTTPS и SSL — это одно и то же?
- HTTPS использует SSL или TLS?
- Что лучше: SSL или TLS?
- Что такое TLS простыми словами?
- Что такое SSL-сертификат?
- Шифрует ли сертификат данные?
- Как HTTPS шифрует данные?
- Кто хранит закрытый ключ?
- Можно ли перехватить HTTPS?
- Можно ли расшифровать HTTPS-трафик?
- Какая версия TLS используется сегодня?
- Чем TLS 1.2 отличается от TLS 1.3?
- Безопасен ли сайт, если у него есть HTTPS?
- Почему браузер показывает предупреждение о сертификате?
- Почему HTTPS называют SSL?
- Работает ли HTTPS через TCP?
- Работает ли HTTPS через UDP?
- Заключение
Иерархия знаний по HTTPS
HTTPS связан сразу с несколькими темами: веб-протоколами, сетевым транспортом, DNS, сертификатами и криптографией. Эта статья занимает в общей системе знаний отдельное место: она подробно объясняет именно защитный слой, на котором строится 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: чем отличаются сетевые протоколы
Здесь подробно рассматриваются SSL, TLS, шифрование, сертификаты, ключи, криптография HTTPS, версии TLS и защитные свойства TLS. Подробная последовательность установления соединения описана отдельно в статье Как работает HTTPS: принцип работы, устройство и порядок соединения. В этой статье handshake будет разобран только настолько, насколько это необходимо для понимания шифрования и аутентификации.
HTTPS, SSL и TLS — что это такое простыми словами
Начнём с главного различия. HTTPS — это защищённый обмен данными HTTP поверх TLS. TLS — современный протокол, который создаёт защищённый канал. SSL — его старое историческое семейство, давно вытесненное TLS.
В бытовой аналогии HTTP — это разговор без защиты, HTTPS — разговор по защищённому каналу, а TLS — технология, которая этот канал создаёт.
Представьте письмо без конверта: почтальон и случайные прохожие могут увидеть текст. Это похоже на обычный HTTP. Запечатанный конверт уже ограничивает доступ к содержимому — аналогия с HTTPS. Но TLS делает больше: он не только скрывает сообщение, но и помогает понять, что письмо пришло от правильного адресата и не было подменено по дороге.
Другая аналогия — защищённый телефонный разговор. Сам разговор — это HTTP-данные: текст страницы, форма, JSON, cookies. Система установления защищённой линии — TLS. Сертификат похож на документ, помогающий убедиться, что вы связались именно с нужной организацией, хотя он не доказывает, что организация добросовестна.
Что означает HTTPS — расшифровка
HTTPS расшифровывается как HyperText Transfer Protocol Secure, то есть «защищённый протокол передачи гипертекста». Упрощённая формула выглядит так:
HTTP + TLS = HTTPS
HTTPS не является отдельной криптографической системой, существующей независимо от HTTP. HTTP по-прежнему описывает запросы и ответы, а TLS защищает их передачу. Например, в адресе https://cio-navigator.ru/ часть https:// указывает браузеру использовать защищённое соединение.
Что такое SSL
SSL — сокращение от Secure Sockets Layer, «уровень защищённых сокетов». Это историческое семейство протоколов, созданное для защиты сетевого обмена. SSL 2.0 и SSL 3.0 были важными этапами развития интернета, но сегодня считаются устаревшими и небезопасными.
В современном HTTPS SSL уже не должен использоваться. Термин «SSL-сертификат» сохранился в рекламе, интерфейсах хостинга и повседневной речи, но обычно речь идёт о сертификате, применяемом в соединении TLS.
Что такое TLS
TLS — Transport Layer Security, «защита транспортного уровня». Это преемник SSL. TLS помогает обеспечить три фундаментальных свойства:
- конфиденциальность — посторонний не должен просто прочитать передаваемые данные;
- целостность — изменение сообщения должно быть обнаружено;
- аутентификацию сервера — браузер проверяет, с каким доменом связан предъявленный сертификат.
Поэтому сегодня технически корректнее говорить: HTTPS работает поверх TLS. Фраза «HTTPS работает по SSL» обычно является исторически закрепившимся, но неточным упрощением.
HTTPS, SSL и TLS: кто за что отвечает — Таблица
Таблица помогает не смешивать название прикладного протокола, защитного протокола и конкретных версий.
| Технология | Что это | Задача | Используется сегодня? | Связь с HTTPS |
|---|---|---|---|---|
| HTTPS | HTTP, защищённый TLS | Передача веб-данных через защищённый канал | Да | Итоговая схема работы сайта |
| HTTP | Прикладной протокол | Описание запросов и ответов | Да | Передаёт содержимое внутри TLS |
| SSL | Старое семейство защитных протоколов | Историческая защита соединений | Нет | Предшественник TLS |
| TLS | Современный защитный протокол | Шифрование, целостность и аутентификация | Да | Защищает HTTP |
| TLS 1.2 | Версия TLS | Защищённый обмен данными | Да, широко поддерживается | Один из вариантов защиты HTTPS |
| TLS 1.3 | Более новая версия TLS | Защита с упрощённым handshake | Да, предпочтительна | Современный вариант HTTPS |
Чем отличаются HTTP, HTTPS, SSL и TLS — Таблица
Теперь сравним понятия по одинаковым критериям. Это полезно, потому что слова «протокол», «сертификат» и «шифрование» часто оказываются в одном рекламном предложении и начинают выглядеть как одно и то же.
| Название | Назначение | Шифрование | Аутентификация | Целостность | Актуальность | Типичный сценарий |
|---|---|---|---|---|---|---|
| HTTP | Передача веб-запросов и ответов | Нет встроенного шифрования | Нет криптографической проверки сервера | Не гарантируется | Используется, но без защиты | Открытые или тестовые соединения |
| HTTPS | Защищённая передача HTTP | Да, через TLS | Обычно сервер аутентифицируется сертификатом | Да | Основной вариант для сайтов | Сайты, API, формы, личные кабинеты |
| SSL | Историческая защита соединений | Да, в старых реализациях | Да, по старым правилам | Да, но с известными проблемами | Устарел | Исторические системы |
| TLS | Современная защита канала | Да | Да | Да | Актуален | HTTPS и другие защищённые протоколы |
| TLS 1.2 | Версия TLS | Современные наборы алгоритмов | Да | Да | Поддерживается | Совместимость со старыми клиентами |
| TLS 1.3 | Новая версия TLS | Более ограниченный набор современных механизмов | Да | Да | Предпочтителен | Новые браузеры, серверы и приложения |
HTTPS — это не просто «SSL-сертификат»
HTTPS — режим защищённого обмена HTTP. TLS — протокол, который обеспечивает этот режим. Сертификат связывает доменное имя с открытым ключом и помогает проверить цепочку доверия. Ключ — криптографический параметр, используемый алгоритмами. Шифрование — преобразование данных в форму, которую нельзя нормально прочитать без нужных секретов.
HTTPS ├── HTTP — содержание обмена ├── TLS — защита соединения ├── сертификат — связь домена и открытого ключа └── ключи — параметры криптографических операций
SSL-сертификат и TLS-сертификат — почему названия путают
Термин «SSL certificate» появился раньше, когда SSL действительно был названием технологии защиты. После перехода на TLS название осталось по инерции. Поэтому пользователь может увидеть в панели хостинга надпись «SSL certificate», а браузер фактически установит соединение по TLS 1.2 или TLS 1.3.
Технически точнее говорить сертификат для TLS/HTTPS, но выражение «SSL-сертификат» настолько распространено, что полностью исчезать из быта оно пока не собирается.
Зачем HTTPS использует TLS
Защищённое подключение по протоколу HTTPS нужно не ради декоративного замка в адресной строке. TLS решает три разные задачи, и каждая важна отдельно.
Шифрование скрывает содержание, проверка целостности обнаруживает подмену, а аутентификация помогает понять, с каким сервером установлен канал.
Конфиденциальность — данные нельзя просто прочитать
Если пользователь вводит пароль на https://cio-navigator.ru/, HTTP-запрос передаётся внутри TLS-канала. Перехватчик может увидеть факт сетевого обмена, но не должен получить возможность просто прочитать пароль, cookies или содержимое формы.
Форма пользователя ↓ HTTP-запрос ↓ TLS-шифрование ↓ зашифрованный сетевой трафик ↓ сервер
Целостность — данные нельзя незаметно изменить
Представим, что пользователь запрашивает страницу, а злоумышленник пытается заменить ответ сервера. TLS использует механизмы аутентифицированного шифрования и проверки целостности. Если защищённое сообщение изменено, проверка не сходится, и получатель должен отвергнуть его.
Сервер отправил: «Покажи страницу» Злоумышленник: изменил часть сообщения Клиент: обнаружил ошибку целостности Результат: сообщение не принимается как корректное
Аутентификация — браузер понимает, с каким сервером устанавливает соединение
Сертификат помогает браузеру проверить, что открытый ключ связан с нужным доменом и подписан доверенной цепочкой удостоверяющих центров. Это не означает, что владелец сайта честен, а опубликованные материалы качественны. Сертификат подтверждает прежде всего криптографическую связь домена и ключа.
| Свойство TLS | Что защищает | Чего не гарантирует |
|---|---|---|
| Конфиденциальность | Содержимое HTTP-обмена | Безопасность устройства пользователя |
| Целостность | Защищённые сообщения от незаметной подмены | Отсутствие ошибок в приложении |
| Аутентификация | Связь домена с открытым ключом | Честность и добросовестность владельца |
Как TLS шифрует данные
Современный TLS использует гибридную криптографию: разные механизмы выполняют разные задачи. Асимметричные алгоритмы и обмен ключами помогают начать защищённое соединение, а симметричный алгоритм быстро шифрует основной поток данных.
Что такое открытый и зашифрованный текст — Пример
Открытый текст может выглядеть так:
Пароль пользователя: 123456
После шифрования это уже не осмысленная фраза, а набор байтов, зависящий от алгоритма, ключа и дополнительных параметров.
Открытый текст: Пароль пользователя: 123456 После шифрования: [набор зашифрованных байтов, непохожий на исходную фразу]
Это демонстрация принципа, а не реальный формат TLS-пакета. В настоящем соединении к данным добавляются служебные поля, счётчики и сведения, необходимые для проверки целостности.
Симметричное шифрование
При симметричном шифровании один секретный ключ используется как часть операций шифрования и расшифровки. Такой подход очень быстр, поэтому именно он подходит для передачи больших страниц, изображений, видео, JSON-ответов и файлов.
Асимметричная криптография
Асимметричная криптография использует пару: открытый ключ можно распространять, а закрытый ключ должен оставаться секретным. Бытовая аналогия — замок с открытой дужкой: любой может закрыть им коробку, но открыть её должен только обладатель ключа.
Закрытый ключ не передают по сети. Если злоумышленник получит его, он может серьёзно нарушить безопасность сервера, особенно если настройки и используемые механизмы не обеспечивают защиту прошлых сессий.
Почему HTTPS использует сразу несколько криптографических механизмов
Асимметричная криптография удобна для установления доверия и согласования секретов, но обычно значительно тяжелее симметричной. Поэтому TLS не пытается шифровать ею каждую картинку и каждый байт HTML.
- сертификат помогает связать домен с открытым ключом;
- механизм обмена ключами позволяет сторонам получить общий секрет;
- из этого секрета выводятся ключи конкретной сессии;
- симметричный AEAD-алгоритм защищает основную передачу данных.
Симметричное и асимметричное шифрование в HTTPS — Таблица
| Характеристика | Симметричное шифрование | Асимметричная криптография |
|---|---|---|
| Количество ключей | Один общий секретный ключ или набор связанных секретов | Пара: открытый и закрытый ключ |
| Скорость | Высокая | Обычно ниже |
| Для чего используется | Основной поток данных | Обмен ключами, подписи, аутентификация |
| Роль в TLS | Защита HTTP после установления канала | Помощь в установлении доверия и общего секрета |
| Пример | AES-GCM, ChaCha20-Poly1305 | RSA, ECDSA, ECDHE |
Почему нельзя шифровать весь трафик только асимметричным шифрованием
Это было бы похоже на отправку каждой страницы в отдельном тяжёлом сейфе, который нужно открывать сложной процедурой. Для иллюстрации можно представить: симметричный механизм обрабатывает условные 100 условных единиц данных за 1 операцию времени, а асимметричный — лишь 1–5. Это не реальные характеристики конкретных алгоритмов, а объяснение разницы подходов.
Что такое ключ шифрования в HTTPS
Ключ — это не обычный пароль и не файл с текстом «секрет». Это значение, которое алгоритм использует для преобразования данных. Без подходящего ключа расшифровка должна быть вычислительно практически невозможной.
Открытый ключ
Открытый ключ можно передавать клиентам и включать в сертификат. Он нужен для проверки подписей или других операций, предусмотренных конкретной криптографической схемой. Сам по себе открытый ключ не даёт возможности восстановить закрытый ключ.
Закрытый ключ
Закрытый ключ хранится на сервере и защищается от чтения посторонними. Он связан с открытым ключом, но не должен передаваться браузеру. Компрометация закрытого ключа — серьёзный инцидент, требующий замены сертификата и анализа конфигурации.
Сессионные ключи
Для каждого соединения используются секретные параметры и ключевой материал, из которых создаются ключи конкретной сессии. Поэтому нельзя представлять HTTPS так, будто один постоянный ключ сайта напрямую шифрует весь трафик всех пользователей.
Как браузер и сервер приходят к общему секрету — Упрощённая схема
Схема ниже упрощает реальный TLS 1.3. Конкретные детали зависят от версии протокола, выбранных алгоритмов и наличия ранее установленной сессии.
Браузер создаёт параметры обмена
↓
Сервер отвечает своими параметрами
↓
Обе стороны вычисляют общий секрет
↓
Сервер подтверждает владение закрытым ключом
↓
Из общего секрета выводятся ключи сессии
↓
HTTP-данные защищаются симметричным шифрованием
Что такое сертификат HTTPS
Сертификат HTTPS — это цифровой документ, который связывает доменное имя с открытым ключом и содержит сведения, необходимые для проверки доверия. Сертификат не шифрует сайт и не является самим защищённым каналом.
Какие данные содержит сертификат — Таблица
| Поле | Что означает | Зачем нужно |
|---|---|---|
| Доменное имя | Имя, для которого выдан сертификат | Проверка соответствия адресу сайта |
| Открытый ключ | Публичная часть ключевой пары | Криптографические операции и проверка |
| Срок действия | Дата начала и окончания | Отсев просроченных документов |
| Издатель | Удостоверяющий центр | Понимание, кто подписал сертификат |
| Субъект | Владелец или идентификатор сертификата | Описание объекта сертификации |
| Подпись удостоверяющего центра | Криптографическая подпись | Проверка подлинности документа |
| Дополнительные домены | Имена в поле SAN | Поддержка нескольких адресов |
| Серийный номер | Уникальный идентификатор | Учёт и отзыв сертификата |
Зачем сайту нужен сертификат
Сертификат позволяет браузеру проверить: «Открытый ключ действительно связан с этим доменом и подписан цепочкой, которой я доверяю?» Если ответ положительный, браузер может продолжить установление защищённого соединения без предупреждения.
Что делает удостоверяющий центр
Certificate Authority, или удостоверяющий центр, подписывает сертификаты после выполнения предусмотренных процедур проверки. Упрощённая цепочка выглядит так:
Сайт ↓ сертификат сайта ↓ удостоверяющий центр ↓ корневой сертификат ↓ доверенное хранилище браузера или ОС
Как браузер проверяет сертификат — Порядок проверки
- получает сертификат от сервера;
- проверяет соответствие доменного имени;
- проверяет срок действия;
- проверяет криптографическую подпись;
- строит цепочку доверия;
- проверяет статус и другие необходимые параметры;
- при успехе продолжает установление TLS-соединения.
Что происходит, если сертификат недействителен — Пример
При открытии https://cio-navigator.ru/ браузер может показать предупреждение, если сертификат просрочен, не соответствует домену, выдан неизвестным центром, содержит неполную цепочку или нарушены другие условия проверки.
Возможная причина предупреждения: домен → cio-navigator.ru сертификат → выдан для другого имени Результат: браузер не может подтвердить ожидаемую связь домена и сертификата.
Как TLS подтверждает подлинность сервера
Механизм доверия сертификатам обычно называют PKI — инфраструктурой открытых ключей. Она включает сертификаты, цифровые подписи, удостоверяющие центры и доверенные хранилища.
Что такое цепочка сертификатов
Сертификат сайта
↓
Промежуточный сертификат
↓
Корневой сертификат
↓
Доверенное хранилище браузера или ОС
Зачем нужны промежуточные сертификаты
Корневой сертификат обычно хранится в доверенном хранилище операционной системы или браузера. Удостоверяющий центр выпускает промежуточные сертификаты, которые подписывают сертификаты сайтов. Такая иерархия позволяет не использовать корневой ключ для каждой отдельной операции и при необходимости отзывать промежуточный уровень.
Что происходит, если цепочка доверия нарушена
Браузер может сообщить, что сертификат неизвестен, цепочка неполна или не удалось подтвердить доверие. Иногда причина находится на сервере: администратор установил сертификат сайта, но не настроил передачу промежуточного сертификата.
Почему значок замка не означает «этому сайту можно доверять»
Мошеннический сайт тоже может получить настоящий сертификат для своего домена. Фишинговая страница может работать по HTTPS и при этом обманывать посетителя. HTTPS защищает соединение с указанным доменом, но не проверяет качество контента, мотивы владельца и отсутствие вредоносных сценариев.
Версии SSL и TLS — Таблица
Версия протокола напрямую влияет на доступные механизмы защиты. Старое название «SSL» не означает, что старый протокол следует включать ради совместимости.
| Версия | Название | Статус | Использование сегодня | Комментарий |
|---|---|---|---|---|
| SSL 2.0 | Secure Sockets Layer 2.0 | Устарела и небезопасна | Не использовать | Имеет серьёзные конструктивные недостатки |
| SSL 3.0 | Secure Sockets Layer 3.0 | Устарела и небезопасна | Не использовать | В том числе связана с атакой POODLE |
| TLS 1.0 | Transport Layer Security 1.0 | Устарела | Отключать | Слабые исторические алгоритмы и режимы |
| TLS 1.1 | Transport Layer Security 1.1 | Устарела | Отключать | Недостаточна для современного контекста |
| TLS 1.2 | Transport Layer Security 1.2 | Актуальна | Используется | Широкая совместимость |
| TLS 1.3 | Transport Layer Security 1.3 | Актуальна и предпочтительна | Используется | Меньше устаревших механизмов и быстрее handshake |
Почему SSL 3.0 больше нельзя использовать
SSL 3.0 содержит серьёзные уязвимости и устаревшие криптографические решения. Известная атака POODLE показала, что откат к SSL 3.0 может позволить раскрывать защищённые данные при определённых условиях. Современные серверы и браузеры должны его отключать.
Почему TLS 1.0 и TLS 1.1 устарели
Эти версии создавались для другой эпохи. Они поддерживают устаревшие наборы алгоритмов и режимы, не соответствующие современным требованиям. Новые сайты должны ориентироваться на TLS 1.2 и TLS 1.3.
TLS 1.2 — почему он до сих пор используется
TLS 1.2 получил широкую поддержку в браузерах, операционных системах, библиотеках, мобильных устройствах и корпоративном оборудовании. Он остаётся важным вариантом совместимости, хотя конфигурация должна исключать слабые алгоритмы.
TLS 1.3 — что изменилось
TLS 1.3 упростил handshake, убрал ряд устаревших криптографических механизмов и сократил число обменов до начала защищённой передачи. Это повышает безопасность и часто уменьшает задержку. При этом TLS 1.3 не превращает HTTPS в магию: ошибки приложения, фишинг и вредоносные программы остаются отдельными проблемами.
TLS 1.2 и TLS 1.3: в чем разница — Таблица
Обе версии относятся к современному TLS, но TLS 1.3 строже ограничивает наборы механизмов и оптимизирует установление соединения.
| Критерий | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Безопасность | Высокая при современной конфигурации | Выше за счёт удаления устаревших вариантов |
| Handshake | Более сложный и длинный | Упрощённый |
| Количество обменов | Обычно больше | Обычно меньше |
| Криптографические механизмы | Широкий набор, включая исторические варианты | Более ограниченный современный набор |
| Производительность | Хорошая | Часто лучше при установлении соединения |
| Forward Secrecy | Зависит от выбранного обмена ключами | Предусматривается современными механизмами обмена |
| Совместимость | Очень широкая | Требует более новых клиентов |
| Актуальность | Сохраняет роль совместимости | Предпочтительный вариант |
Почему TLS 1.3 быстрее TLS 1.2
Упрощённо можно представить последовательность так:
TLS 1.2: клиент → сервер сервер → клиент клиент → сервер начало защищённого обмена TLS 1.3: клиент → сервер сервер → клиент начало защищённого обмена
Это упрощённая схема: реальное число сообщений зависит от сценария, повторного подключения, наличия ранее сохранённой сессии и других условий. Главное — TLS 1.3 старается быстрее перейти к защищённой передаче.
Что такое Perfect Forward Secrecy и зачем она нужна
Perfect Forward Secrecy, или прямая секретность, защищает прошлые сессии от автоматической расшифровки после компрометации долговременного ключа сервера.
Что произойдёт, если закрытый ключ сервера украдут
Представим, что злоумышленник заранее записал большой объём HTTPS-трафика, а через месяц получил закрытый ключ сервера. При старых схемах это могло создать риск расшифровки записанных сессий. Современный обмен ключами строится так, чтобы закрытый ключ сервера не был единственным секретом, необходимым для восстановления прошлых сеансовых ключей.
| Событие | Возможное последствие |
|---|---|
| Украден закрытый ключ сервера | Риск подделки аутентификации будущих соединений и необходимость перевыпуска |
| Украдены данные конкретной сессии | Может быть раскрыта именно эта сессия |
| Перехвачен старый трафик при PFS | Компрометация ключа сервера не должна автоматически раскрыть прошлый трафик |
Forward Secrecy — Пример
1. Злоумышленник записал HTTPS-трафик. 2. Прошло время. 3. Он получил закрытый ключ сервера. 4. В современных схемах TLS с PFS старые сессионные секреты не выводятся из одного только закрытого ключа. 5. Старые записи не должны автоматически расшифроваться.
Что именно шифруется при работе HTTPS
TLS защищает содержимое HTTP-обмена: запросы, заголовки, тело запроса и ответы сервера. Внутри этого обмена могут находиться cookies, данные формы, HTML, JSON, CSS, JavaScript и изображения.
Что видно злоумышленнику, а что скрыто — Таблица
| Данные | Обычно защищены TLS | Что может быть видно на сетевом уровне |
|---|---|---|
| Содержимое HTTP-запроса | Да | Размер и время передачи |
| Пароль | Да, внутри запроса | Факт соединения |
| Cookies | Да, если передаются по HTTPS | Метаданные трафика |
| URL path | Обычно да, он внутри HTTP-запроса | Не обязательно виден наблюдателю |
| Query string | Обычно да, внутри HTTP-запроса | Не следует путать с DNS |
| IP-адрес | Нет | Обычно виден участникам маршрутизации |
| Порт | Нет | Может быть виден |
| Факт соединения | Нет | Обычно виден |
| Объём и время трафика | Нет | Могут быть видны |
| DNS-запрос | Не защищается автоматически обычным TLS сайта | Может быть виден DNS-провайдеру |
Имя домена и путь URL — не одно и то же. Путь и параметры передаются внутри HTTP и обычно защищаются TLS. DNS является отдельным механизмом поиска IP-адреса, поэтому обычный DNS-запрос может раскрывать имя домена. Исторически имя сервера также передавалось в SNI открыто; существуют механизмы вроде ECH, уменьшающие такую утечку, но их поддержка зависит от инфраструктуры.
Можно ли взломать HTTPS
HTTPS не является абсолютным щитом от всех угроз. Он защищает определённый участок пути — передачу данных между клиентом и сервером. Если проблема находится на устройстве, внутри приложения или на самом сайте, один TLS её не исправит.
Перехват HTTPS-трафика
В публичной Wi-Fi-сети злоумышленник может видеть сетевые пакеты, пытаться направить трафик через себя или собирать метаданные. Но корректно настроенный TLS не должен позволить просто прочитать содержимое пакетов.
Атака «человек посередине» — Пример
Пользователь
↓
Злоумышленник
↓
Настоящий сайт
Чтобы незаметно подменить сервер, злоумышленнику нужно убедить браузер принять его сертификат. Проверка домена, подписи и цепочки доверия как раз мешает такой подмене. Если пользователь игнорирует предупреждение браузера или на устройстве установлен вредоносный доверенный сертификат, защита может быть ослаблена.
Почему просто перехватить HTTPS-пакеты недостаточно
Перехваченный зашифрованный трафик не равен готовому паролю или HTML-коду. Без сессионных секретов наблюдатель видит набор защищённых данных и метаданные, а не нормальный текст запроса.
Когда HTTPS не спасает
- на компьютере установлено вредоносное ПО;
- украдены cookies уже после расшифровки в браузере;
- пользователь открыл фишинговый сайт;
- сам сайт скомпрометирован;
- TLS настроен неправильно;
- пользователь доверил вредоносному корневому сертификату;
- в веб-приложении есть уязвимость;
- данные утекли до шифрования или после расшифровки.
Как связаны HTTPS, TLS, сертификат и ключи — Схема
Большая схема ниже показывает, где находится каждый элемент и почему сертификат не следует путать с самим шифрованием.
HTTPS
│
├── HTTP
│ └── данные приложения
│
└── TLS
├── аутентификация сервера
│ └── сертификат
│ └── открытый ключ
│
├── согласование параметров
│
└── защищённая передача данных
└── симметричное шифрование
HTTP формирует запросы и ответы. TLS защищает их передачу. Сертификат сообщает домен и открытый ключ, а также содержит подпись удостоверяющего центра. Закрытый ключ хранится на сервере. Сессионные ключи используются для текущего соединения. Основной объём данных шифруется быстрым симметричным алгоритмом.
Как SSL и TLS работают при открытии сайта — Пример
Рассмотрим упрощённую последовательность для адреса https://cio-navigator.ru/. Это не полный разбор handshake, а карта происходящего.
- пользователь вводит адрес;
- определяется домен;
- выполняется DNS-разрешение;
- устанавливается сетевое соединение;
- начинается TLS;
- сервер предъявляет сертификат;
- браузер проверяет сертификат;
- стороны согласуют криптографические параметры;
- формируется защищённый канал;
- внутри него передаётся HTTP;
- сервер отвечает;
- браузер получает и отображает данные.
Адрес сайта ↓ DNS ↓ сетевой транспорт ↓ TLS и проверка сертификата ↓ защищённый HTTP ↓ страница в браузере
Подробная механика установления соединения рассматривается в статье Как работает HTTPS: принцип работы, устройство и порядок соединения.
Как TLS связан с HTTP/1.1, HTTP/2 и HTTP/3
Нельзя утверждать, что HTTPS всегда работает поверх TCP. Это зависит от версии HTTP и выбранного транспорта.
HTTP/1.1 + TLS
HTTP/1.1 → TLS → TCP → IP
Это классическая схема: HTTP-обмен защищается TLS, TLS работает поверх TCP, а TCP — поверх IP.
HTTP/2 + TLS
HTTP/2 → TLS → TCP → IP
HTTP/2 обычно использует TLS и TCP. Он эффективнее организует множество запросов внутри одного соединения, но не меняет базовую роль TLS.
HTTP/3 + QUIC
HTTP/3 → QUIC → UDP → IP
HTTP/3 не работает поверх TCP. Он использует QUIC, который работает поверх UDP и включает современные механизмы защиты, основанные на TLS 1.3. Поэтому фраза «HTTPS всегда использует TCP» технически неверна.
HTTPS и HTTP/1.1, HTTP/2, HTTP/3 — Таблица
| Вариант | Прикладной протокол | Защитный слой | Транспорт | Особенность |
|---|---|---|---|---|
| HTTPS с HTTP/1.1 | HTTP/1.1 | TLS | TCP | Классическая схема |
| HTTPS с HTTP/2 | HTTP/2 | TLS | TCP | Мультиплексирование потоков |
| HTTPS с HTTP/3 | HTTP/3 | TLS 1.3 внутри QUIC | UDP | Меньше зависимости от TCP |
Подробнее о связи HTTPS, TCP/IP и других протоколов можно узнать в статье HTTPS, TCP/IP, HTTP и FTP: как связаны сетевые протоколы. Порт HTTPS часто обозначается как 443, но порт — это отдельная тема, описанная в материале Порт HTTPS — 443: какой порт использует протокол и зачем он нужен.
Какие алгоритмы используются в TLS
TLS не является одним алгоритмом шифрования. Это протокол, который объединяет обмен ключами, цифровые подписи, получение ключевого материала, симметричное шифрование и проверку целостности.
AES
AES — симметричный блочный шифр. В TLS он часто используется в составе AEAD-режимов, например AES-GCM, которые одновременно защищают конфиденциальность и целостность.
ChaCha20-Poly1305
ChaCha20 — быстрый потоковый шифр, а Poly1305 — механизм аутентификации данных. Связка особенно полезна на устройствах, где аппаратное ускорение AES работает хуже.
ECDHE
ECDHE — механизм обмена ключами на эллиптических кривых. Он позволяет сторонам получить общий секрет и обычно поддерживает Perfect Forward Secrecy.
RSA
RSA исторически применялся для аутентификации и обмена ключами. Но неверно говорить, что «HTTPS шифрует всё RSA». В современных соединениях RSA чаще связан с цифровыми подписями старых конфигураций, а основной поток данных защищается симметричными алгоритмами.
Современные алгоритмы TLS — Таблица
| Механизм | Для чего используется | Где встречается в TLS | Комментарий |
|---|---|---|---|
| AES-GCM | Шифрование и проверка целостности | Защита данных сессии | AEAD-режим |
| ChaCha20-Poly1305 | Шифрование и аутентификация | Защита данных сессии | Хорош на разных типах устройств |
| ECDHE | Обмен ключами | Установление общего секрета | Поддерживает PFS |
| RSA | Подписи и исторический обмен ключами | Сертификаты и старые конфигурации | Не означает шифрование всего трафика |
| ECDSA | Цифровая подпись | Сертификаты и аутентификация | Работает с эллиптическими кривыми |
| HKDF | Получение ключевого материала | Производные ключи TLS | Особенно важен в TLS 1.3 |
Почему говорят «SSL-сертификат», если используется TLS
Выражения «SSL certificate», «TLS certificate», «HTTPS certificate» и «сертификат сайта» в повседневной речи часто обозначают один и тот же практический объект — сертификат, применяемый веб-сервером для TLS-соединения.
Историческая причина проста: SSL был известным названием технологии, поэтому рынок закрепил выражение «SSL-сертификат». Технически сегодня точнее говорить «сертификат для TLS/HTTPS».
Что означает «установить SSL-сертификат»
Обычно под этим понимается целый набор действий:
- получить сертификат;
- хранить закрытый ключ на сервере;
- установить сертификат и промежуточную цепочку;
- настроить веб-сервер;
- включить HTTPS;
- проверить домены, сроки и наборы алгоритмов;
- перенаправить HTTP на HTTPS при необходимости.
Практическая последовательность настройки описана в статье Как подключить HTTPS к сайту: установка, настройка и переход с HTTP.
Мифы про HTTPS, SSL и TLS — Таблица
Ошибочные формулировки опасны не только для экзамена по сетям: они могут привести к неверной настройке сайта или ложному чувству безопасности.
| Миф | Как правильно |
|---|---|
| «HTTPS — это SSL» | HTTPS — HTTP поверх защитного протокола, сегодня обычно TLS. |
| «SSL и TLS — одно и то же» | TLS — преемник SSL, а старые версии SSL устарели. |
| «SSL-сертификат шифрует сайт» | Сертификат связывает домен и открытый ключ; шифрование выполняют механизмы TLS. |
| «HTTPS делает сайт безопасным» | Он защищает передачу, но не гарантирует безопасность сайта и приложения. |
| «Если есть замок, сайту можно доверять» | Замок показывает защищённое соединение и успешную проверку домена, а не честность владельца. |
| «HTTPS шифрует абсолютно всё» | Содержимое HTTP защищено, но IP, время, объём и часть DNS-метаданных могут быть видны. |
| «HTTPS всегда работает через TCP» | HTTP/1.1 и HTTP/2 обычно используют TCP, HTTP/3 — QUIC поверх UDP. |
| «TLS — это алгоритм шифрования» | TLS — протокол, объединяющий несколько криптографических механизмов. |
| «Сертификат содержит пароль от сайта» | Сертификат содержит открытый ключ и сведения о домене, но не пароль пользователя. |
| «Для HTTPS нужен только один ключ» | Участвуют ключевая пара, сессионные секреты и производные ключи. |
| «Чем длиннее сертификат, тем безопаснее сайт» | Безопасность зависит от версии TLS, алгоритмов, настроек и приложения. |
| «HTTPS невозможно перехватить» | Пакеты можно перехватить, но корректный TLS скрывает их содержимое. |
| «Перехваченный трафик сразу читается» | Перехват зашифрованных пакетов не равен расшифровке. |
| «SSL 3.0 — современный SSL» | SSL 3.0 устарел и небезопасен. |
| «TLS 1.0 и TLS 1.1 подходят новым сайтам» | Для современных систем ориентируются на TLS 1.2 и TLS 1.3. |
Как связаны HTTPS, TLS, сертификат и шифрование — Полная схема
Эта схема собирает все уровни в одну картину — от браузера до сервера.
Браузер ↓ HTTPS ↓ HTTP + TLS ├── сертификат ├── проверка домена ├── аутентификация сервера ├── согласование криптографических параметров ├── создание ключевого материала ├── симметричное шифрование └── проверка целостности ↓ Сетевой транспорт ├── TCP для HTTP/1.1 и HTTP/2 └── QUIC/UDP для HTTP/3 ↓ Сервер
Браузер запускает HTTPS, HTTP формирует содержимое, TLS защищает обмен, сертификат помогает аутентифицировать сервер, ключевой материал задаёт параметры конкретной сессии, а транспорт доставляет пакеты. Нельзя заменить один элемент другим: сертификат не является TLS, TLS не является HTTP, а HTTP не является TCP.
Как HTTPS защищает пароль при отправке формы — Пример
Рассмотрим условную форму на https://cio-navigator.ru/. Сам сайт может иметь любую конкретную структуру формы; схема ниже показывает общий принцип.
Пользователь вводит: Логин: user Пароль: ******** Форма ↓ HTTP-запрос ↓ TLS ↓ зашифрованные данные ↓ Интернет ↓ сервер ↓ TLS расшифровывает данные ↓ веб-приложение получает HTTP-запрос
HTTPS защищает пароль при передаче между клиентом и сервером. Но он не защищает пароль от вредоносной программы на компьютере пользователя, не исправляет небезопасное хранение паролей на сервере и не спасает от фишинговой страницы, которой пользователь сам сообщил секрет.
Как узнать версию TLS и сертификат сайта — Пример
Проверять TLS можно несколькими способами. Конкретные результаты для cio-navigator.ru зависят от текущей настройки сервера и момента проверки, поэтому их нельзя заранее объявлять без непосредственного тестирования.
Проверка в браузере
Обычно можно открыть сведения о соединении через значок рядом с адресом, перейти к сертификату и посмотреть издателя, срок действия, домены и цепочку доверия.
Инструменты разработчика
Во вкладках Network или Security браузер может показать протокол TLS, сертификат, HTTP/2 или HTTP/3, а также предупреждения о смешанном содержимом.
Командная строка — Пример
openssl s_client -connect cio-navigator.ru:443 -servername cio-navigator.ru
Команда помогает изучить сертификат и параметры TLS, но вывод зависит от установленной версии OpenSSL и конфигурации сервера.
Что можно узнать при проверке
| Параметр | Что показывает |
|---|---|
| TLS version | Используемую версию протокола |
| Сертификат | Домен, издателя, срок действия и открытый ключ |
| Цепочка | Промежуточные и корневые связи доверия |
| Алгоритм | Выбранный набор криптографических механизмов |
| HTTP version | HTTP/1.1, HTTP/2 или HTTP/3 при поддержке |
Для комплексной диагностики можно использовать материал Проверка HTTPS: как протестировать протокол и исправить ошибки. DNS и защищённый DNS — отдельная тема; о DNS over HTTPS рассказано в статье DNS over HTTPS (DoH): что это такое, как работает и как настроить.
Частые вопросы про HTTPS, SSL и TLS
Короткие ответы помогут закрепить основные различия и не потеряться среди похожих сокращений.
HTTPS и SSL — это одно и то же?
Нет. HTTPS — защищённый HTTP, а SSL — устаревшее семейство протоколов. Современный HTTPS использует TLS.
HTTPS использует SSL или TLS?
В современных системах — TLS, обычно TLS 1.2 или TLS 1.3. Выражение «SSL» часто сохраняется только как бытовое название.
Что лучше: SSL или TLS?
TLS. SSL 2.0 и SSL 3.0 устарели и небезопасны.
Что такое TLS простыми словами?
Это протокол, который создаёт защищённый канал, шифрует данные, проверяет их целостность и помогает аутентифицировать сервер.
Что такое SSL-сертификат?
Обычно так называют сертификат сайта, используемый для TLS-соединения. Технически точнее — сертификат для TLS/HTTPS.
Шифрует ли сертификат данные?
Нет. Сертификат содержит открытый ключ и сведения о домене. Шифрование выполняют криптографические механизмы TLS.
Как HTTPS шифрует данные?
Сначала стороны согласуют секретные параметры, затем основной поток защищается быстрым симметричным шифрованием.
Кто хранит закрытый ключ?
Обычно сервер или защищённая инфраструктура, обслуживающая сервер. Браузер не должен получать закрытый ключ сайта.
Можно ли перехватить HTTPS?
Пакеты можно перехватить на сетевом уровне, но при корректной настройке TLS их содержимое не должно быть доступно наблюдателю.
Можно ли расшифровать HTTPS-трафик?
Иногда — при компрометации устройства, ошибках конфигурации, установке вредоносного доверенного сертификата или других условиях. Простого перехвата пакетов обычно недостаточно.
Какая версия TLS используется сегодня?
Основной современный контекст — TLS 1.2 и TLS 1.3. TLS 1.3 предпочтителен, TLS 1.2 сохраняет значение совместимости.
Чем TLS 1.2 отличается от TLS 1.3?
TLS 1.3 удаляет устаревшие варианты, упрощает handshake и обычно быстрее начинает защищённый обмен.
Безопасен ли сайт, если у него есть HTTPS?
Защищено соединение с доменом, но сайт может быть мошенническим, уязвимым или содержать вредоносный контент.
Почему браузер показывает предупреждение о сертификате?
Возможны просрочка, несовпадение домена, неизвестный издатель, неполная цепочка или другая ошибка проверки.
Почему HTTPS называют SSL?
Это исторически закрепившийся термин. Раньше применялся SSL, но современные соединения используют TLS.
Работает ли HTTPS через TCP?
HTTP/1.1 и HTTP/2 обычно работают через TLS поверх TCP. Но HTTPS с HTTP/3 использует QUIC поверх UDP.
Работает ли HTTPS через UDP?
Да, в случае HTTP/3: HTTP/3 работает поверх QUIC, а QUIC использует UDP.
Заключение
HTTP передаёт данные приложения: запросы, заголовки, формы, HTML и JSON. HTTPS — это защищённый способ передавать HTTP через TLS. TLS — современный протокол защиты соединения, а SSL — его устаревший предшественник.
Сертификат помогает аутентифицировать сервер и связывает доменное имя с открытым ключом, но сам по себе не шифрует данные и не делает сайт честным. Криптографические ключи участвуют в создании защищённого канала и защите конкретной сессии. Асимметричные механизмы помогают установить доверие и общий секрет, а симметричное шифрование эффективно защищает основной поток данных.
Главный современный ориентир — TLS 1.2 и TLS 1.3, причём TLS 1.3 предлагает более строгий набор механизмов и более быстрый процесс установления соединения. Поэтому корректная цепочка рассуждений выглядит так:
HTTP → данные приложения HTTPS → HTTP, защищённый TLS TLS → конфиденциальность, целостность и аутентификация сертификат → связь домена с открытым ключом ключи → параметры криптографической защиты симметричное шифрование → эффективная защита основного трафика TLS 1.3 → современная версия с акцентом на безопасность и производительность
Понимание этой схемы помогает не путать протокол, сертификат, ключ и алгоритм — и не считать значок замка универсальным пропуском в мир абсолютной безопасности.
