Когда вы открываете сайт по обычному HTTP, всё, что летит между браузером и сервером, — открытый текст. Любой, кто оказался на пути (владелец Wi-Fi в кафе, провайдер, взломанный роутер), может это прочитать и даже подменить: увидеть пароль, подставить свою страницу вместо настоящей, вырезать кусок ответа. HTTPS закрывает эту дыру: буква «S» на конце — это тот же HTTP, но упакованный в защищённый слой TLS. Разберёмся простыми словами, что делает TLS, как две стороны договариваются о ключах и почему браузер вообще верит, что на том конце именно тот сайт, за который он себя выдаёт.

Зачем нужно шифрование

У защиты трафика две отдельные задачи, и их полезно не путать.

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

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

То есть TLS даёт три вещи сразу: конфиденциальность (никто не прочитал), целостность (никто не изменил) и аутентификацию (это точно тот сервер). Обычный HTTP не даёт ни одной.

Симметричное и асимметричное шифрование на пальцах

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

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

Асимметричное шифрование решает именно эту проблему. У стороны есть пара ключей: открытый (публичный) и закрытый (приватный). Открытый ключ можно раздавать всем — представьте открытый навесной замок, который вы разослали по почте. Кто угодно может защёлкнуть им коробку, но открыть её сможете только вы своим закрытым ключом, который никому не отдаёте. Работает это медленно, зато не требует заранее иметь общий секрет.

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

TLS handshake: как договариваются о ключах

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

  1. Привет от клиента. Браузер сообщает: «хочу защищённое соединение, вот версии TLS и наборы шифров, которые я понимаю».
  2. Привет от сервера + сертификат. Сервер выбирает подходящий шифр и присылает свой сертификат — в нём его имя (домен) и открытый ключ.
  3. Проверка сертификата. Браузер убеждается, что сертификат настоящий, выдан кому надо и не просрочен (об этом ниже). Если что-то не так — та самая страшная красная страница «ваше соединение не защищено».
  4. Выработка общего ключа. Используя асимметрию, стороны безопасно договариваются об общем секрете, из которого рождается симметричный ключ сессии. Даже если кто-то записал весь обмен, вычислить этот ключ со стороны он не может.
  5. Переключение на симметрику. С этого момента весь HTTP-трафик шифруется быстрым симметричным ключом. Handshake закончен, полетели настоящие запросы.

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

Сертификаты и центры сертификации

Остаётся главный вопрос из шага 3: браузер получил сертификат с открытым ключом, но откуда ему знать, что это сертификат настоящего банка, а не самозванца, который тоже умеет генерировать ключи? Ключи-то может создать кто угодно.

Ответ — центры сертификации (Certificate Authority, CA). Это организации, которым браузеры и операционные системы доверяют «из коробки»: список их корневых сертификатов зашит в систему. CA проверяет, что вы действительно владеете доменом, и подписывает ваш сертификат своей подписью. Браузер, получив сертификат сайта, проверяет эту подпись: «подписано доверенным CA, домен совпадает, срок не вышел — верю».

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

Раньше сертификаты стоили денег и выдавались вручную. Сейчас есть Let's Encrypt — бесплатный CA, который выдаёт сертификаты автоматически. Важная особенность: его сертификаты живут всего 90 дней, поэтому их обновляют по расписанию специальным клиентом. Идея в том, что автопродление надёжнее, чем «выпустили на два года и забыли».

TLS termination: где расшифровывается трафик

В реальной системе TLS почти никогда не расшифровывается на самом приложении. Между интернетом и вашим сервисом обычно стоит балансировщик или обратный прокси, и именно он расшифровывает входящий HTTPS. Это называется TLS termination — «точка, где TLS заканчивается».

Схема типичная: снаружи всё идёт по HTTPS до балансировщика (nginx, облачный load balancer, ingress). Балансировщик держит сертификат, расшифровывает трафик и передаёт дальше — до вашего сервиса — уже как обычный HTTP по внутренней сети. Ваш код при этом работает с простым HTTP и вообще не думает про сертификаты.

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

mTLS: взаимная проверка

В обычном TLS личность проверяет только клиент: браузер убеждается, что сервер настоящий, а сам серверу не предъявляет никакого сертификата (пользователь доказывает, кто он, уже потом — паролем или токеном).

mTLS (mutual TLS, взаимный TLS) добавляет проверку в обе стороны: не только клиент проверяет сервер, но и сервер требует сертификат от клиента. Обе стороны предъявляют документы. Для сайтов это избыточно, но между сервисами внутри системы удобно: сервис A принимает запрос, только если сервис B предъявил валидный клиентский сертификат. Так соседний сервис доказывает, что он свой, ещё до всякой бизнес-логики. Это одна из основ безопасности внутренних коммуникаций, к которой стоит вернуться, когда дойдёте до защиты сервисов.

Где это применяется

Для backend-разработчика TLS — это не абстрактная криптография, а несколько очень практичных вещей.

  • Где терминируется TLS. В типовой схеме — на балансировщике или ingress перед приложением; внутри кластера сервисы часто общаются по обычному HTTP в доверенной сети. Знать эту границу нужно, чтобы понимать, откуда взялся заголовок X-Forwarded-Proto и почему приложение «видит» http, хотя пользователь пришёл по https.
  • Истёкший сертификат — частый инцидент. Сертификаты имеют срок годности, и забытое продление роняет сайт целиком: браузеры отказываются открывать страницу. Отсюда практика автопродления и мониторинга даты истечения — это одна из самых обидных и предотвратимых аварий.
  • Самоподписанные сертификаты в тестах. Локально и в тестовых окружениях часто используют сертификат, который вы подписали сами, без CA. Браузер такому не верит и ругается — это нормально для разработки. Главное не тащить привычку «отключить проверку сертификата» в production-код.

Где спотыкаются начинающие:

  • Путают HTTPS и отдельный протокол. HTTPS — это не замена HTTP, а тот же HTTP внутри защищённого TLS-конверта. Все методы, статусы и заголовки те же.
  • Думают, что TLS шифрует всё подряд. Домен, к которому вы подключаетесь, на этапе установки соединения ещё виден со стороны; шифруется содержимое запросов и ответов, а не сам факт «вы зашли на такой-то сайт».
  • Считают, что шифрование = подлинность. Можно зашифровать канал с самозванцем. Именно сертификат и CA отвечают за то, что на том конце нужный сервер, а не просто «кто-то с ключами».
  • Отключают проверку сертификата, чтобы «заработало». Быстро убирает ошибку в тесте и тихо убивает всю защиту, если уедет в production.

Что учить дальше

TLS стоит поверх транспортного слоя, поэтому полезно понимать, что под ним. Начните с моделей OSI и TCP/IP, чтобы видеть, на каком слое живёт шифрование, и с TCP и UDP — TLS работает поверх надёжного TCP-соединения. Дальше — как устроены соединения и почему handshake добавляет задержку к каждому новому подключению. Вернитесь к HTTP, чтобы окончательно закрепить, что HTTPS — это он же в защищённом конверте. А общую картину защиты сервисов — сертификаты, секреты, доступы — собирает раздел про безопасность backend.