Опубликована 16 октября 2026, 11:17Виталий Лещенко

Сети для самых маленьких. Часть 23: TLS и сертификаты

Двадцать две части подряд мы говорили «TLS» одной фразой: «шифрование поверх TCP, на котором работает HTTPS». Пора разобрать его как протокол. IPsec защищал пакеты на сетевом уровне, и приложения о нём не знали; TLS, Transport Layer Security, делает обратное: он живёт внутри одного TCP-соединения (десятая часть), и приложение само решает им пользоваться. Зато ему не нужны ни шлюзы, ни туннели, ни права администратора: библиотека в браузере и библиотека на сервере — и всё. Поэтому именно TLS защищает подавляющую часть трафика в интернете: HTTPS, почту между серверами, DNS в DoT и DoH из двенадцатой части, OpenVPN из двадцатой.

Половина этой части — не о шифровании, а о доверии: откуда браузер знает, что разговаривает именно с www.example.com, а не с тем, кто встал посередине. Шифрование без этого бесполезно, и ответ на этот вопрос — сертификаты.

Что обещает TLS

Три вещи для одного соединения между клиентом и сервером:

конфиденциальность — никто между ними не прочитает данные;
целостность — никто не изменит их незаметно;
подлинность сервера — клиент убеждается, что сервер тот, за кого себя выдаёт; при желании и сервер проверяет клиента.

История версий короткая: SSL 2.0 и 3.0 (1995–1996, Netscape) сломаны и запрещены; TLS 1.0 и 1.1 выведены из эксплуатации в 2021 году; TLS 1.2 (2008) по-прежнему повсюду; TLS 1.3 (2018, RFC 8446) — умолчание в современных браузерах и серверах, и его мы разберём как основной, отметив, что в 1.2 иначе.

Записи

TLS делит поток TCP на записи (records) — свой уровень оформления с заголовком в 5 байт:

 байты:   1       2         2        ≤ 16 384
        ┌──────┬────────┬────────┬────────────────────────┐
        │ Type │ Version│ Length │ содержимое             │
        └──────┴────────┴────────┴────────────────────────┘

Четыре типа: 22 handshake — сообщения рукопожатия, 23 application data — данные приложения, 21 alert — ошибки и закрытие, 20 change_cipher_spec — рудимент из 1.2, в 1.3 оставлен для совместимости. Version в 1.3 всегда 0x0303 (то есть «1.2») — ради тех же старых промежуточных устройств, которые ломались от незнакомых версий; настоящая версия договаривается внутри расширений.

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

Рукопожатие TLS 1.3

Один круг до сервера и обратно — и данные пошли:

   клиент                                                             сервер
     │                                                                   │
     ├── ClientHello ───────────────────────────────────────────────────►│
     │   версии, случайное число, набор шифров,                          │
     │   key_share: мой открытый ключ DH (x25519),                       │
     │   server_name: www.example.com, ALPN: h2, http/1.1                │
     │                                                                   │
     │◄── ServerHello ───────────────────────────────────────────────────┤  открыто
     │   выбранный шифр, случайное число, key_share: ключ DH сервера     │
     │                                                                   │
     │   ═══ обе стороны вычислили общий секрет, дальше зашифровано ═══  │
     │                                                                   │
     │◄── EncryptedExtensions ───────────────────────────────────────────┤  ALPN: h2
     │◄── Certificate ───────────────────────────────────────────────────┤  цепочка сертификатов
     │◄── CertificateVerify ─────────────────────────────────────────────┤  подпись закрытым ключом
     │◄── Finished ──────────────────────────────────────────────────────┤  HMAC по всему рукопожатию
     │                                                                   │
     │  проверить цепочку, имя, подпись, Finished                        │
     ├── Finished ──────────────────────────────────────────────────────►│
     ├── данные приложения (GET / HTTP/2) ──────────────────────────────►│
     │◄── данные приложения ─────────────────────────────────────────────┤

ClientHello — единственное, что в TLS 1.3 видно открыто целиком, и в нём есть на что посмотреть:

поддерживаемые версии в расширении supported_versions (в поле Version стоит фиктивное 1.2);
наборы шифров (cipher suites): в 1.3 их всего пять, и имя говорит только о симметричном шифре и хеше: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256. Обмен ключами и подпись в 1.3 договариваются отдельно;
supported_groups — какие группы Диффи-Хеллмана клиент умеет: x25519, secp256r1, и key_share — сразу готовый открытый ключ DH для самой вероятной группы. Это и экономит круг: в 1.2 клиент сначала узнавал, что умеет сервер, и только потом слал ключ;
server_name (SNI) — имя сервера, к которому клиент идёт. Нужно, потому что на одном IP-адресе живут сотни сайтов, и сервер должен выбрать, какой сертификат предъявить, до того, как что-либо зашифровано. Отсюда следствие: имя сайта видно всем по дороге;
ALPN — какой протокол приложения клиент хочет внутри: h2 (HTTP/2) или http/1.1. Договориться об этом внутри TLS дешевле, чем отдельным обменом;
signature_algorithms — какими подписями клиент умеет проверять сертификаты и CertificateVerify.

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

Certificate — сертификат сервера и промежуточные сертификаты до корня (о них ниже). CertificateVerify — подпись закрытым ключом, соответствующим сертификату, по хешу всего рукопожатия до этого момента. Это главный момент аутентификации: сертификат может скопировать кто угодно, он публичный; а вот подписать именно это рукопожатие может только владелец закрытого ключа. Finished — HMAC по всему рукопожатию ключом из общего секрета: доказательство, что обе стороны видели одно и то же и никто ничего не подменил по дороге.

Клиент проверяет три вещи: цепочку сертификатов до доверенного корня, что имя в сертификате совпадает с тем, куда он шёл, и подпись в CertificateVerify. Всё сошлось — шлёт свой Finished и данные.

Откуда ключи и зачем forward secrecy

Общий секрет — результат эфемерного Диффи-Хеллмана: каждая сторона сгенерировала одноразовую пару ключей, обменялась открытыми половинами, и из своей закрытой и чужой открытой получила одно и то же число, которое по сети не передавалось. Дальше функция HKDF (вывод ключей на основе HMAC) из этого числа и хеша рукопожатия выводит ключи рукопожатия, а затем — ключи для данных в каждую сторону.

Закрытый ключ сертификата при этом не шифрует ничего. Он только подписывает. Поэтому если его украдут через год, записанный сегодня трафик расшифровать не удастся: сеансовые ключи были одноразовыми и давно уничтожены. Это forward secrecy, и в 1.3 она обязательна. В 1.2 ещё допускался «RSA key exchange», где клиент шифровал секрет открытым ключом сервера из сертификата, и там кража ключа раскрывала всё записанное задним числом; этот режим из 1.3 убран.

Что иначе в TLS 1.2

Два круга вместо одного: ClientHello → ServerHello, Certificate, ServerKeyExchange (ключ DH с подписью), ServerHelloDone → ClientKeyExchange, ChangeCipherSpec, Finished → ChangeCipherSpec, Finished.
Сертификат идёт открытым текстом.
Наборы шифров с полным именем: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 читается как «обмен ключами ECDHE, подпись RSA, шифр AES-128-GCM, хеш SHA-256». Из таких имён и видно, есть ли forward secrecy: ECDHE или DHE — есть, просто RSA — нет.
Больше старых алгоритмов: CBC-режимы с отдельным HMAC, RC4, 3DES — всё, что в 1.3 вычищено.

Возобновление и 0-RTT

После рукопожатия сервер может прислать session ticket — зашифрованный своим ключом слепок состояния. При следующем подключении клиент предъявляет его как PSK, и рукопожатие обходится без сертификатов, а при желании — и без ожидания ответа: данные приложения идут прямо в первом пакете (0-RTT). Цена 0-RTT — такие данные можно повторить записью: защитить от повтора нечем. Поэтому в 0-RTT пускают только безопасные для повтора запросы (GET), и многие серверы его просто не включают.

Сертификат

Сертификат — это открытый ключ, имя его владельца и подпись того, кто это подтверждает, в формате X.509. Посмотреть можно на любой:

$ openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 04:a1:b2:c3:...
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = E6
        Validity
            Not Before: Sep 15 10:00:00 2026 GMT
            Not After : Dec 14 10:00:00 2026 GMT
        Subject: CN = www.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:www.example.com, DNS:example.com
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            Authority Information Access:
                OCSP - URI:http://e6.o.lencr.org
                CA Issuers - URI:http://e6.i.lencr.org/
            CT Precertificate SCTs: ...

По полям:

Subject — кому выдан. Исторически — поле CN, сегодня имена смотрят только в Subject Alternative Name: список DNS-имён (и IP-адресов), для которых сертификат действителен. *.example.com — wildcard, покрывает один уровень: a.example.com, но не a.b.example.com и не сам example.com.
Issuer — кто подписал. Здесь промежуточный сертификат Let's Encrypt с именем E6.
Validity — срок. 90 дней у Let's Encrypt; у коммерческих — до 398 дней сейчас, и браузеры сокращают максимум до 47 дней к 2029 году: короткий срок ограничивает ущерб от утечки ключа и заставляет автоматизировать продление.
Public Key — открытый ключ сервера, пара к тому закрытому, которым подписан CertificateVerify.
Key Usage, Extended Key Usage — для чего ключ: подписывать рукопожатия, для TLS-сервера. Сертификат с CA:TRUE в Basic Constraints — сертификат удостоверяющего центра, им можно подписывать другие.
Authority Information Access — где взять сертификат издателя и где спросить об отзыве.
Signature — подпись всего содержимого закрытым ключом издателя.

Цепочка доверия

Клиент не может проверить сертификат сам: подпись сделана чужим ключом. Он проверяет цепочку:

 ISRG Root X1  ──подписал──►  E6 (промежуточный)  ──подписал──►  www.example.com
 (в хранилище доверенных      (сервер присылает                  (сервер присылает
  корней ОС и браузера,        в Certificate)                     в Certificate)
  самоподписанный)

Подпись сертификата www.example.com проверяется открытым ключом из сертификата E6.
Подпись E6 — открытым ключом ISRG Root X1.
ISRG Root X1 ни у кого не проверяется: он лежит в хранилище доверенных корней операционной системы или браузера. Это и есть основание доверия: производитель ОС решил, что этому центру можно верить, и положил его корень в систему. В хранилище около полутора сотен корней, и за каждым — организация, прошедшая аудит.

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

Отсюда первое правило настройки сервера: сервер обязан присылать промежуточные сертификаты. Клиент знает только корни; если в Certificate лежит один серверный сертификат, цепочка до корня не строится, и браузер покажет «издатель неизвестен», хотя сертификат настоящий. Половина ошибок «у меня работает, а у клиента нет» — отсутствующий промежуточный: у администратора он кеширован браузером, у клиента — нет.

Кто выдаёт

Удостоверяющий центр (CA, certificate authority) — организация, чьи корни лежат в хранилищах, и чья работа — проверить, что сертификат просит именно владелец имени, и подписать. Выпуск выглядит так:

Владелец сервера генерирует пару ключей у себя. Закрытый ключ никуда не уходит.
Создаёт CSR (certificate signing request): открытый ключ, желаемые имена, подпись собственным закрытым ключом — доказательство, что ключ у него.
CA проверяет владение именем и подписывает CSR своим промежуточным ключом. Готово.

Проверка бывает трёх уровней, и от уровня зависит цена, а не криптография:

DV (domain validation) — CA проверяет только, что проситель управляет доменом: может положить файл на сайт или запись в DNS. Автоматизируется полностью.
OV — плюс проверка организации по документам; в сертификате появляется её название.
EV — расширенная проверка; раньше браузеры показывали зелёную плашку с именем компании, с 2019 года перестали, и смысла в EV почти не осталось.

Замок в браузере означает ровно одно: соединение с тем, кто управляет этим доменом. Не «сайт честный», не «компания настоящая».

Let's Encrypt и ACME

До 2015 года сертификат стоил денег и выпускался руками: заполнить форму, получить письмо, скопировать файл на сервер, через год повторить. Let's Encrypt — некоммерческий CA, который выдаёт DV-сертификаты бесплатно и автоматически по протоколу ACME (RFC 8555), и за десять лет стал крупнейшим CA в мире: больше половины сайтов в интернете используют его сертификаты.

ACME — это HTTPS-API, по которому программа на сервере (certbot, acme.sh, встроенные клиенты в Caddy, Traefik, cert-manager в Kubernetes) разговаривает с CA:

   клиент ACME на сервере                                       Let's Encrypt
     │                                                                │
     ├── регистрация: ключ учётной записи ───────────────────────────►│
     ├── заказ: хочу сертификат на www.example.com ──────────────────►│
     │◄── вот проверки на выбор: http-01, dns-01, tls-alpn-01 ────────┤
     │   и токен для каждой                                           │
     │                                                                │
     │  http-01: положить токен в                                     │
     │  http://www.example.com/.well-known/acme-challenge/<токен>     │
     │  dns-01:  TXT-запись _acme-challenge.www.example.com = хеш     │
     │                                                                │
     ├── готово, проверяй ───────────────────────────────────────────►│
     │                           CA запрашивает токен с нескольких    │
     │                           точек в интернете, сверяет           │
     │◄── проверка пройдена ──────────────────────────────────────────┤
     ├── CSR ────────────────────────────────────────────────────────►│
     │◄── сертификат + цепочка ───────────────────────────────────────┤

Две главные проверки:

HTTP-01: CA должен получить токен по HTTP на 80-м порту с публичного адреса, в который резолвится имя. Значит, сервер должен быть доступен из интернета, а wildcard так не выдать: нельзя проверить «все имена сразу».
DNS-01: токен кладётся в TXT-запись _acme-challenge.<имя> (двенадцатая часть). Серверу не нужно быть доступным извне, можно выдавать wildcard и сертификаты для внутренних хостов; нужен только API DNS-провайдера, чтобы клиент мог создать запись сам.

Сертификат на 90 дней; клиент по таймеру продлевает его через 60, повторяя ту же процедуру, и человек в ней не участвует. Если автоматика сломалась, об этом узнают по письму от Let's Encrypt за 20 дней до истечения, а не по падению сайта. Для защиты от злоупотреблений есть лимиты: 50 сертификатов на домен в неделю, пять дубликатов, и они же — причина, по которой тестируют против staging-окружения Let's Encrypt, а не боевого.

Цепочка у Let's Encrypt: серверный сертификат ← промежуточный (E5/E6 для ECDSA, R10/R11 для RSA) ← корень ISRG Root X1, который в хранилищах с 2016–2018 годов. Старый кросс-подписанный путь через корень DST Root CA X3 закончился в 2024 году, и устройства, у которых нет ISRG Root X1 (Android до 7.1 без обновлений), Let's Encrypt больше не доверяют.

Одна команда, которая делает всё перечисленное:

$ sudo certbot certonly --webroot -w /var/www/html -d www.example.com -d example.com

Свой удостоверяющий центр

Для внутренней сети публичный CA не нужен и не всегда возможен: имена вроде pg.internal в публичном DNS не существуют. Тогда поднимают свой CA (OpenSSL, step-ca, Active Directory Certificate Services, cert-manager с собственным issuer), его корень раскладывают по всем своим машинам в хранилище доверенных (групповой политикой, MDM, образом), и он выдаёт сертификаты для внутренних сервисов. Механика та же: корень, промежуточный, цепочка, только доверие ограничено своей организацией. Так же устроен EAP-TLS для Wi-Fi из третьей части и сертификаты IKEv2 из девятнадцатой.

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

Отзыв и прозрачность

Ключ утёк, домен сменил владельца, CA выдал сертификат по ошибке — сертификат нужно отозвать до истечения срока. Два механизма, оба несовершенны:

CRL — CA публикует список отозванных серийных номеров; клиент должен его скачать и держать свежим. Списки большие, качают редко.
OCSP — клиент спрашивает CA по HTTP про конкретный сертификат. Медленно (лишний запрос при каждом соединении), раскрывает CA, какие сайты вы посещаете, и ненадёжно: если OCSP-сервер недоступен, браузеры пропускают проверку (soft-fail), иначе интернет ложился бы вместе с CA. OCSP stapling — сервер сам прикладывает свежий ответ OCSP к рукопожатию; это убирает запрос и утечку, но не soft-fail. Let's Encrypt прекратил OCSP в 2025 году в пользу CRL.

Браузеры в итоге распространяют сводные списки отзывов сами (CRLSets в Chrome, CRLite в Firefox), а короткий срок сертификатов делает отзыв менее критичным: через 90 дней он истечёт сам.

Certificate Transparency решает другую проблему: как узнать, что какой-то CA выдал сертификат на ваш домен без вашего ведома? Каждый выпущенный сертификат CA обязан записать в публичные журналы — дописываемые, криптографически проверяемые; Chrome и Safari не принимают сертификат без отметок (SCT) из журналов. Любой может следить за журналами по своему домену (crt.sh), и выдача «втихую» стала невозможной. Побочный эффект: все ваши внутренние имена, для которых вы взяли публичные сертификаты, видны в crt.sh всему миру.

Клиентские сертификаты

Сервер может потребовать сертификат и от клиента: в рукопожатии он шлёт CertificateRequest, клиент отвечает своими Certificate и CertificateVerify, и сервер проверяет их по своему CA. Это mTLS (mutual TLS), и так аутентифицируют не людей, а машины и сервисы: микросервисы друг перед другом, агентов перед сервером управления, устройства перед Wi-Fi (EAP-TLS) и VPN. Пароли при этом не нужны вовсе.

Типичные ошибки

Браузер говорит	Что на самом деле
`NET::ERR_CERT_DATE_INVALID`	срок истёк — автопродление сломалось; либо часы на клиенте сбиты
`ERR_CERT_COMMON_NAME_INVALID`	имени, по которому пришли, нет в SAN: взяли `example.com`, а сертификат на `www.example.com`
`ERR_CERT_AUTHORITY_INVALID`	цепочка не строится: сервер не прислал промежуточный, или корень неизвестен клиенту, или сертификат самоподписанный
сертификат другого сайта	клиент не прислал SNI (старый клиент, обращение по IP), и сервер отдал сертификат по умолчанию
`ERR_SSL_VERSION_OR_CIPHER_MISMATCH`	не сошлись версии или шифры: у сервера только TLS 1.0 или у клиента только 1.3
`SSL_ERROR_RX_RECORD_TOO_LONG`	на 443 порту отвечает не TLS: обычно HTTP без шифрования

Что TLS не скрывает

Имя сервера — SNI в ClientHello открыт. Расширение ECH (Encrypted Client Hello) шифрует его ключом, опубликованным в DNS, и постепенно появляется, но пока не везде.
IP-адрес сервера и факт соединения с ним.
DNS-запрос, если он ушёл обычным UDP (часть 12).
Размер и время записей: по ним иногда угадывают, какую страницу смотрят.
Содержимое — от самого сервера. TLS защищает канал, а не данные после него.

И одно место, где TLS намеренно ломают: корпоративные прокси для «инспекции». На все рабочие машины ставят корень компании, прокси на лету выпускает им сертификат на любое имя и встаёт посередине: от браузера до прокси один TLS, от прокси до сайта другой, и прокси читает всё. Технически это то, от чего TLS защищает; работает только потому, что корень доверенный. Видно по Issuer в сертификате любого сайта: если там имя вашей компании вместо Let's Encrypt — вас инспектируют.

Смотрим руками

Рукопожатие, цепочка и результат проверки одной командой:

$ openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E6
verify return:1
depth=0 CN = www.example.com
verify return:1
---
Certificate chain
 0 s:CN = www.example.com
   i:C = US, O = Let's Encrypt, CN = E6
 1 s:C = US, O = Let's Encrypt, CN = E6
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
SSL handshake has read 2843 bytes and written 393 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Peer signing digest: SHA256
Peer signature type: ECDSA
...

Читаем: цепочка из двух сертификатов (сервер прислал промежуточный, корень взят из хранилища), Verification: OK, TLS 1.3, шифр, подпись ECDSA. Если Verification не OK — там будет причина: unable to get local issuer certificate (нет промежуточного или корня), certificate has expired, и так далее. Ключ -servername обязателен: без SNI сервер отдаст сертификат по умолчанию.

Сроки, чтобы проверять истечение скриптом:

$ openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
notBefore=Sep 15 10:00:00 2026 GMT
notAfter=Dec 14 10:00:00 2026 GMT

curl -v https://www.example.com показывает то же короче: версию, шифр, Subject, Issuer, срок, SSL certificate verify ok. curl -k отключает проверку — для диагностики, не для жизни.

В Wireshark рукопожатие 1.3 выглядит как ClientHello с полным разбором (расширения, SNI, key_share), ServerHello — и дальше только Application Data: сертификат уже зашифрован. Чтобы увидеть всё, браузеру задают переменную окружения SSLKEYLOGFILE с путём к файлу: туда он пишет сеансовые ключи, а Wireshark, получив файл в настройках TLS, расшифровывает захват. Это и есть практическое доказательство, что ключи сеанса — не в сертификате.

История выдачи по домену — https://crt.sh/?q=example.com. Полная проверка сервера на слабые версии и шифры — testssl.sh www.example.com.

Что запомнить

TLS — защита одного TCP-соединения, которую выбирает приложение. Записи по 16 КБ, типы handshake, application data, alert.
Рукопожатие 1.3 — один круг: ClientHello (версии, шифры, key_share, SNI, ALPN) → ServerHello (выбор, key_share) → всё дальнейшее зашифровано: сертификат, CertificateVerify (подпись рукопожатия закрытым ключом), Finished. Ключи — из эфемерного DH, закрытый ключ сертификата только подписывает: forward secrecy.
Сертификат — открытый ключ, имена в SAN, срок, подпись издателя. Клиент строит цепочку до корня из своего хранилища; сервер обязан присылать промежуточные.
CA проверяет владение именем (DV) и подписывает CSR. Let's Encrypt делает это бесплатно и автоматически по ACME: HTTP-01 файлом на сайте, DNS-01 записью TXT (wildcard и внутренние имена); 90 дней, продление через 60.
Отзыв через CRL и OCSP работает плохо, короткий срок важнее; Certificate Transparency делает все выпуски публичными.
Открыты SNI, адрес, размеры. Корпоративная инспекция — узаконенный MITM через свой корень.

Серия целиком

На этом «Сети для самых маленьких» закончены: двадцать три части, снизу вверх по стеку и затем вширь.

Основа

Модели OSI и TCP/IP — зачем сетевой стек разбит на уровни и как данные обрастают заголовками по пути пакета.
Ethernet — кадр по байтам, MAC-адреса и как коммутатор решает, в какой порт отправить кадр.
Wi-Fi — чем радио отличается от кабеля, как клиент подключается к точке доступа и как защищается эфир.
PPPoE — как провайдер заворачивает сессию абонента в Ethernet и откуда берётся MTU 1492.

IPv4

IPv4: адреса, маски и подсети — как читать адрес и маску, делить сеть на подсети и решать, нужен ли шлюз.
IPv4: заголовок, маршрутизация и NAT — как роутер выбирает маршрут для пакета и как вся квартира выходит в интернет с одного адреса.
ARP — как по IP-адресу соседа узнать его MAC-адрес и почему соседа так легко подменить.
ICMP — служебные сообщения IP, как на самом деле работают ping и traceroute и что ломается, когда их режут.

Транспорт

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

Служебные протоколы

DHCPv4 — как машина без адреса получает адрес, маску, шлюз и DNS четырьмя сообщениями.
DNS — как имя превращается в адрес: дерево зон, рекурсивные серверы, записи и кеширование.

IPv6

IPv6: адреса и заголовок — как записываются 128-битные адреса, какие они бывают и чем заголовок IPv6 отличается от IPv4.
ICMPv6 и Neighbor Discovery — как в IPv6 без ARP и широковещания находят соседей и роутер.
SLAAC — как хост собирает себе адрес IPv6 из объявления роутера без всякого сервера.
DHCPv6 — зачем DHCP, если есть SLAAC, и как провайдер выдаёт домашнему роутеру целый блок сетей.

Сегментация и туннели

VLAN — как один коммутатор и один кабель несут несколько независимых сетей.
VXLAN — как растянуть сеть Ethernet через роутеры, завернув кадры в UDP.
IPsec и IKEv2 — как шифруют пакеты на сетевом уровне и договариваются о ключах.
VPN и прокси — куда уходит каждый пакет при включённом VPN и чем прокси отличается от VPN.

Маршрутизация и доверие

OSPF — как роутеры одной сети сами строят общую карту и считают по ней кратчайшие пути.
BGP — как десятки тысяч независимых сетей интернета договариваются о маршрутах.
TLS и сертификаты (эта статья) — как защищают одно TCP-соединение и откуда браузер знает, что сервер настоящий.

Если что-то в серии оказалось непонятным или неверным — комментарии под любой из частей открыты.