HTTPS

27 мая 2026 · ~15 мин чтения

HTTPS

HTTPS (HyperText Transfer Protocol Secure) — это обычный веб-протокол HTTP, упакованный в зашифрованный канал TLS. Браузер и сервер сначала договариваются о ключе и проверяют подлинность сертификата, а потом гоняют через эту трубу те же запросы и ответы, что и в HTTP.

История

HTTPS — это надстройка над HTTP, поэтому начнём с фундамента.

1991 — HTTP/0.9. Тим Бернерс-Ли (Tim Berners-Lee) в CERN выпускает первый протокол передачи гипертекста. Тогда в нём не было ни авторизации, ни шифрования: один глагол GET, и ответ — голый HTML.

1994 — SSL 1.0. Компания Netscape (та самая, что сделала первый массовый браузер Netscape Navigator) понимает: если по интернету теперь будут гонять номера кредиток, нужна защита. Инженер Тахир Эль-Гамаль (Taher Elgamal) — главный криптограф Netscape, иногда его называют «отцом SSL» — проектирует SSL (Secure Sockets Layer). Версия 1.0 была настолько дырявая, что её даже не выпустили наружу.

1995 — SSL 2.0. Первая публичная версия. И вместе с ней — первая массовая версия HTTPS: Netscape Navigator 1.1 умеет открывать https:// адреса. По разным оценкам, это и считается «днём рождения» HTTPS — конкретного RFC тогда ещё не было.

1996 — SSL 3.0. Полная переделка, потому что 2.0 быстро взломали. Уже почти современный дизайн.

1999 — TLS 1.0 (RFC 2246). Когда стандартом занялся IETF (организация, которая делает RFC), протокол переименовали из SSL в TLS (Transport Layer Security). По сути TLS 1.0 — это SSL 3.1, но политически название поменяли, чтобы не было монополии Netscape.

2000 — RFC 2818. Тот самый документ, где HTTPS наконец-то официально описан как «HTTP поверх TLS». До этого он был де-факто, теперь стал де-юре.

Дальше — гонка с дырами:

• TLS 1.1 (2006) — фикс от атак на CBC-режим.
• TLS 1.2 (2008) — современная криптография, SHA-256, поддержка AEAD.
• TLS 1.3 (2018, RFC 8446) — большая чистка: убрали всё старое и дырявое, упростили рукопожатие до одного round-trip (а с возобновлением сессии — до нуля, 0-RTT).

Параллельно шла история сертификатов. Долгое время сертификат стоил денег (десятки–сотни долларов в год), и поэтому HTTPS был только у крупных сайтов с авторизацией. Перелом случился в 2014–2016: появился Let's Encrypt — бесплатный некоммерческий удостоверяющий центр (CA), запущенный Mozilla, EFF и Cisco. После него HTTPS стал нормой даже для блогов. К 2021 году доля HTTPS-трафика в браузерах перевалила за 95%.

Что это такое

Когда ты набираешь в браузере https://example.com, происходит следующее:

1. Браузер открывает TCP-соединение с сервером на порту 443 (HTTP по умолчанию слушает 80, HTTPS — 443).
2. Поверх этого TCP начинается TLS-рукопожатие (handshake): обмен ключами, проверка сертификата, согласование шифров.
3. Когда канал зашифрован — браузер отправляет туда обычный HTTP-запрос: GET / HTTP/1.1\r\nHost: example.com\r\n.... Сервер отвечает обычным HTTP-ответом.
4. Всё содержимое (URL после домена, заголовки, тело запроса, cookies, ответ сервера) идёт внутри зашифрованной трубы. Снаружи виден только IP-адрес сервера, иногда имя домена (через SNI, об этом ниже) и общий объём трафика.

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

• Шифрование (confidentiality). Содержимое нельзя прочитать, перехватив трафик. Wi-Fi-сосед в кафе видит, что ты ходишь на условный Авито, но не видит, что именно ты там ищешь.
• Целостность (integrity). Содержимое нельзя подменить по дороге. Провайдер не может незаметно вставить рекламный баннер в чужую страницу (а они пробовали — в 2010-х это была реальная история).
• Подлинность сервера (authenticity). Браузер проверяет, что сертификат сайта подписан одним из доверенных удостоверяющих центров. Если ты ввёл sberbank.ru, ты приходишь именно к Сберу, а не к фишинговой подделке.

Чего HTTPS не делает:

• Не скрывает, на какой сайт ты пошёл (домен виден провайдеру через DNS и SNI).
• Не защищает от того, что сам сервер собирает твои данные.
• Не делает сайт сам по себе «безопасным» — на HTTPS-сайте может быть тот же XSS, та же SQL-инъекция, тот же фишинг.

Аналогии из жизни

Запечатанное письмо с восковой печатью.
HTTP — это открытка: текст виден всем, кто её несёт. HTTPS — это запечатанный конверт с восковой печатью отправителя. Почтальон видит адрес и габариты, но не содержание, и сразу замечает, если печать сломана.
Где ломается: в реальной жизни ты доверяешь печати, потому что знаешь подпись Ивана. В HTTPS подпись ставит не сам сервер, а удостоверяющий центр — посредник, которому доверяет твой браузер. Если этот центр скомпрометирован или выдаст левый сертификат — печать формально правильная, а письмо — поддельное. Поэтому в современных браузерах есть «прозрачность сертификатов» (Certificate Transparency) — публичный лог всех выпущенных сертификатов, чтобы такие случаи можно было заметить.

Курьер с биркой компании.
Когда тебе звонит курьер «я из СДЭКа», ты обычно просишь номер заказа и проверяешь его в приложении. TLS-рукопожатие — это в общем-то то же самое: сервер показывает «бирку» (сертификат), браузер проверяет её через цепочку до доверенного центра.
Где ломается: курьер может предъявить настоящую бирку настоящей компании, но при этом доставить не тот заказ. Сертификат подтверждает, что домен правильный, но не подтверждает, что код на сервере не взломали и контент не подменили хакеры внутри.

Запломбированный счётчик воды.
В аналогии с целостностью: пломба не мешает читать показания, она мешает их подделывать. HTTPS точно так же — даже если бы трафик был незашифрован, проверка MAC (Message Authentication Code) внутри TLS гарантировала бы, что никто не вставил в середину чужой пакет.
Где ломается: пломба на счётчике проверяется только когда приходит инспектор. В HTTPS проверка идёт автоматически на каждом пакете — это сильнее. Но пломба честно говорит и о тебе самом: если ты сорвал пломбу (например, открыл TLS-туннель через корпоративный прокси с собственным сертификатом, который вшит в твой ноутбук), снаружи это выглядит как нормальное HTTPS-соединение, а трафик при этом виден работодателю в открытом виде.

Как это работает

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

Шаг 0. Браузер резолвит домен в IP через DNS.
Это ещё не часть HTTPS, но без неё ничего не начнётся. Браузер спрашивает у DNS-резолвера: «какой IP у example.com?» — и получает, например, 93.184.216.34.

Шаг 1. TCP-handshake.
Браузер открывает обычное TCP-соединение с этим IP на порт 443. Это три пакета: SYN → SYN-ACK → ACK. Один полный round-trip (туда-обратно). После этого у нас есть «голая» TCP-труба.

Шаг 2. ClientHello.
Браузер посылает первое TLS-сообщение. В нём:
- список поддерживаемых версий TLS (1.2, 1.3),
- список поддерживаемых шифронаборов (cipher suites — комбинаций алгоритмов),
- случайное число (random),
- публичные ключи для обмена ключами (key share) — браузер заранее генерирует ключевую пару,
- SNI (Server Name Indication) — имя домена, к которому ты идёшь. SNI нужен, потому что на одном IP может висеть много сайтов с разными сертификатами, и сервер должен понять, какой из них ему предъявлять.

Шаг 3. ServerHello + сертификат + подпись.
Сервер в одном пакете присылает:
- выбранную версию TLS и шифронабор,
- своё случайное число,
- свой публичный ключ (вторая половина обмена ключами),
- сертификат (на самом деле цепочку сертификатов: сам сертификат сайта, промежуточный сертификат удостоверяющего центра, иногда корневой),
- подпись — сервер подписывает все предыдущие сообщения своим приватным ключом, и эту подпись браузер потом проверит публичным ключом из сертификата.

После этого у обеих сторон есть всё, чтобы вычислить общий симметричный ключ — но они его не пересылали по сети. Это и есть Diffie-Hellman: математический трюк, благодаря которому два собеседника могут получить общий секрет, обмениваясь только публичными данными. Современный TLS использует ECDHE — эллиптический Diffie-Hellman с эфемерными (одноразовыми) ключами. «Эфемерные» — это важно: даже если кто-то когда-нибудь украдёт приватный ключ сервера, уже отправленные сессии расшифровать не получится. Это называется forward secrecy (прямая секретность).

Шаг 4. Проверка сертификата.
Браузер берёт цепочку сертификатов и проверяет:
- что подпись цепочки доходит до корневого центра, который зашит в браузере (в Chrome это список Chrome Root Store, в Firefox — свой, в macOS — Keychain),
- что сертификат выписан именно на то имя, которое ты ввёл в адресной строке (поле SAN — Subject Alternative Name),
- что срок действия не истёк,
- что сертификат не отозван (через OCSP или CRL — отдельная история),
- что сертификат зарегистрирован в публичных логах Certificate Transparency.

Если хоть одна проверка падает — браузер показывает большой красный экран «Ваше подключение не защищено» и НЕ передаёт HTTP-запрос.

Шаг 5. Finished.
Обе стороны подтверждают, что у них действительно есть рабочий общий ключ. С этого момента весь дальнейший трафик шифруется симметричным алгоритмом — обычно AES-GCM или ChaCha20-Poly1305. Симметричное шифрование быстрое, поэтому передача больших объёмов данных стоит почти столько же, как и в HTTP.

Шаг 6. Полезная нагрузка.
Теперь браузер наконец отправляет тот самый GET / HTTP/1.1. Сервер отвечает. Внутри одного TLS-соединения может пройти много HTTP-запросов и ответов подряд (а если это HTTP/2 или HTTP/3 — то ещё и параллельно).

В TLS 1.3 шаги 1–5 укладываются в один round-trip (1-RTT): браузер посылает свой ключ, сервер сразу присылает свой и сертификат, и можно начинать. В TLS 1.2 раньше было два полных round-trip — это была одна из главных причин делать TLS 1.3.

Где встречается в обычной жизни

• Маленький замочек слева от адреса в браузере. Это и есть индикатор HTTPS. Если замочка нет (или он зачёркнут) — соединение незашифровано или у сертификата проблемы.
• Оплата картой на сайте. Когда ты вводишь номер карты — он улетает по HTTPS. Без HTTPS ни один платёжный шлюз (Stripe, ЮKassa, Тинькофф) с тобой работать не станет, потому что это требование стандарта PCI DSS.
• Любое банк-приложение и сайт госуслуг. Под капотом — тот же HTTPS, иногда с дополнительной взаимной аутентификацией (когда не только сервер проверяет себя, но и клиент предъявляет свой сертификат — это называется mTLS).
• Wi-Fi в кафе или аэропорту. На незащищённом Wi-Fi сосед может перехватить трафик, но содержимое HTTPS-страниц он не прочтёт. Открытый HTTP в такой сети уже почти не встретишь — браузеры активно мигрируют всё на HTTPS, и Chrome с 2023 года по умолчанию пробует HTTPS даже когда пользователь набрал просто example.com.
• Корпоративный прокси на работе. Иногда работодатель ставит на ноутбук свой корневой сертификат, и тогда корпоративный прокси может «вскрывать» HTTPS-трафик: подменять сертификат сайта на свой и видеть весь трафик в открытом виде. Технически это допустимая корпоративная практика, юридически — обычно с согласия сотрудника.

Где встречается в IT и бизнесе

• Любой публичный API. Все API современных сервисов (Stripe, OpenAI, Telegram Bot API, AWS) ходят только по HTTPS. Серверы вообще не слушают на 80-м порту, кроме редиректа на 443-й.
• Микросервисы внутри инфраструктуры. Раньше внутри дата-центра трафик гоняли по HTTP («внутри безопасно»). Сейчас норма — zero trust, когда даже внутренние сервисы общаются по mTLS (с проверкой клиентского сертификата). Service mesh (например, Istio или Linkerd) автоматически выдаёт сертификаты каждому подику и шифрует всё.
• CDN и SSL termination. Когда сайт стоит за CDN типа Cloudflare, TLS «разрывается» на узле CDN: пользователь общается с CDN по HTTPS, а CDN со своим источником — отдельной TLS-сессией. Это позволяет CDN кэшировать страницы и резать DDoS.
• Деплой блогов и сайтов через certbot. Сейчас стандарт для маленького VPS — поставить nginx, поднять домен, запустить certbot --nginx, и через минуту у тебя бесплатный валидный сертификат от Let's Encrypt с авто-обновлением каждые 60 дней.
• HSTS (HTTP Strict Transport Security). Заголовок, которым сервер говорит браузеру: «приходи ко мне только по HTTPS, и так — следующий год». Защищает от downgrade-атак, когда атакующий пытается перевести соединение обратно на незащищённый HTTP.

Кто пользуется

Условно — все. По данным Cloudflare Radar и собственных отчётов Google, доля HTTPS в трафике десктоп-Chrome в развитых странах превышает 95% уже несколько лет, в мобильном — близко к 100%. У крупных сайтов (Google, Facebook, YouTube, Wikipedia, любая популярная Россия — Я.Сервисы, ВК, Авито) HTTP-версии физически нет, есть только редирект 301 на HTTPS.

Конкретно:
- Let's Encrypt к 2024 году выпустил больше миллиарда активных сертификатов и обслуживает по разным оценкам более 300 миллионов доменов. Это в одиночку больше, чем у всех платных CA вместе.
- Cloudflare обрабатывает порядка 20% веб-трафика мира; почти весь он идёт через TLS на их edge-нодах.
- Google Search с 2014 года использует HTTPS как фактор ранжирования: сайты без HTTPS получают пенальти в выдаче. Это и сыграло ключевую роль в массовом переходе.

Альтернативы и конкуренты

• HTTP/3 + QUIC. Не альтернатива HTTPS как таковому, а его эволюция: тот же TLS, но не поверх TCP, а поверх UDP. Минусы — пока не все провайдеры и фаерволлы дружат с UDP-443 одинаково хорошо. Плюсы — меньше задержки на установке соединения, лучше работает на мобильных сетях.
• WireGuard / IPsec / OpenVPN. Это VPN-протоколы, шифрующие весь сетевой уровень, а не только HTTP-трафик. Плюс — скрывают сам факт обращения к конкретному сайту. Минус — нужен клиент, нужна инфраструктура, нельзя «просто открыть в браузере».
• Tor. Скрывает не только содержимое, но и факт обращения. Плюс — анонимность. Минус — очень медленно и подозрительно выглядит для многих сайтов, поэтому в браузерах ходить через Tor каждый день неудобно.
• Просто HTTP. Имеет смысл только внутри localhost или в полностью контролируемой ламповой среде. Минус — не работает в современном мире: браузеры предупреждают, формы с паролями ругаются, многие API не пускают.
• Самоподписанные сертификаты. Не альтернатива публичному HTTPS, а вариант для внутренних сервисов. Плюс — бесплатно и быстро. Минус — браузер ругается, пока ты вручную не добавишь сертификат в доверенные.

Когда НЕ стоит использовать

• Внутри одного процесса или машины (loopback). Если ты делаешь HTTP-запрос с приложения к локальному API на 127.0.0.1:5000 — TLS тут только тормозит и усложняет настройку. Никто это соединение не перехватит, потому что оно не выходит за пределы машины.
• На совсем embedded-устройствах без памяти и батарейки. Маленький IoT-датчик с микроконтроллером на десятки килобайт памяти может не потянуть TLS-стек, и тогда используют либо обрезанные варианты (TLS-PSK с предзагруженным ключом), либо вообще шифрование на уровне приложения. Хотя в 2026 году это уже редкость — даже на ESP32 TLS прекрасно работает.
• Когда уже есть надёжный нижний слой. Если трафик идёт внутри уже зашифрованной VPN или mTLS-туннеля, добавлять ещё один TLS обычно избыточно — но в проде так почти никто не делает, потому что «лишний TLS» дешевле, чем «дырка из-за того, что VPN внезапно упал».

Связанные понятия

• TLS — собственно протокол шифрования, который и обеспечивает «S» в HTTPS.
• Сертификат X.509 — формат документа, в котором сервер предъявляет свою подлинность; внутри — публичный ключ, имя владельца, подпись CA.
• CA (Certificate Authority) — удостоверяющий центр; организация, которой доверяет твой браузер и которая подписывает сертификаты сайтов.
• Let's Encrypt — бесплатный автоматический CA, изменивший интернет в 2015–2020 годах.
• ACME — протокол, по которому certbot и аналоги получают сертификаты от Let's Encrypt без ручных действий.
• HSTS — механизм, заставляющий браузер ходить на сайт строго по HTTPS.
• SNI — поле в TLS-рукопожатии, в котором клиент сообщает, к какому домену он идёт (нужно для виртуального хостинга).
• Certificate Transparency — публичный лог всех выпущенных сертификатов, чтобы можно было заметить «левый» сертификат на твой домен.
• Forward secrecy — свойство современных шифронаборов: даже если приватный ключ сервера потом украдут, старые сессии не расшифровать.
• mTLS — взаимный TLS, когда не только сервер, но и клиент предъявляет сертификат; нужен для надёжной аутентификации в API «сервис к сервису».

Литература и источники

• RFC 8446 — спецификация TLS 1.3. Сухой, но именно его читают, если нужна правда. Искать в Google: rfc 8446.
• RFC 2818 — «HTTP Over TLS», тот документ, где HTTPS зафиксирован как стандарт. Тоже на datatracker.ietf.org.
• «High Performance Browser Networking» — книга Ильи Григорика (Ilya Grigorik), Google, 2013, en. Глава про TLS — пожалуй, самое понятное общедоступное объяснение, не теряющее точности. Лежит бесплатно онлайн: hpbn.co.
• Документация Let's Encrypt: letsencrypt.org/docs/ — короткие, понятные тексты про то, как устроены сертификаты и почему 90 дней.
• Cloudflare Learning Center: cloudflare.com/learning/ssl/ — серия популярных статей про TLS, SNI, HSTS, certificate transparency.
• Wikipedia: HTTPS, Transport Layer Security (русская и английская версии) — для общего обзора и истории; en-версия точнее.

Где встретилось у меня

Вчера, 26 мая, я доводил блог: nginx на VPS, домен через certbot, статика для статей. По логам — упоминания HTTPS, TLS, certbot и Let's Encrypt идут везде, где про деплой и настройку домена. То есть я каждый день этим пользуюсь, но до сих пор не разложил по полочкам, что именно происходит между тем моментом, как браузер видит https://, и тем, как страница рисуется.

Краткое резюме

• HTTPS — это HTTP, упакованный в TLS-туннель. Сам HTTP не меняется, меняется транспорт.
• TLS даёт три вещи: шифрование (никто не прочтёт), целостность (никто не подменит), подлинность сервера (ты пришёл туда, куда хотел).
• Подлинность проверяется через цепочку сертификатов, ведущую к корневому CA, которому доверяет твой браузер. Самое «дешёвое и массовое» звено этой цепочки сейчас — Let's Encrypt с протоколом ACME.
• Современный TLS 1.3 укладывает рукопожатие в один round-trip и обеспечивает forward secrecy — даже утечка приватного ключа сервера не раскроет старые сессии.
• HTTPS не делает сайт безопасным сам по себе: он закрывает только канал, не код и не логику приложения.