# Установка соединения TLS в Wireshark | Компьютерные сети - 46

## Метаданные

- **Канал:** Andrey Sozykin
- **YouTube:** https://www.youtube.com/watch?v=7TK5x7nJ2q4
- **Дата:** 03.05.2026
- **Длительность:** 18:57
- **Просмотры:** 1,835

## Описание

Практика по разбору процесса установки соединения TLS с помощью Wireshark.

Как поддержать курс: 
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!

Сайт курса - https://www.asozykin.ru/courses/networks_online
Сайт для практических занятий - https://networkscourse.ru
RFC TLS 1.3 - https://datatracker.ietf.org/doc/html/rfc8446
Let’s Encrypt - https://letsencrypt.org/

Мой канал в telegram - https://t.me/a_sozykin
VK - https://vk.com/sozykin_it
Дзен - https://dzen.ru/asozykin

Если YouTube работает плохо, то видео можно смотреть на других площадках:
- Дзен - https://dzen.ru/video/watch/69f6457b66544869fb362d51
- VK - https://vkvideo.ru/video-211221104_456239089

00:00 - Установка соединения TLS 1.3 в Wireshark
02:26 - Сообщение Client Hello
07:35 - Сообщение Server Hello
15:09 - Ticket сессии
16:10 - Сообщение Client Finished
17:34 - Просматриваем механизмы защиты соединения в браузере
18:42 - Итоги

Рекомендуемые книги:
1. Д.Ф.Куроуз, К.В.Росс. Компьютерные сети. Нисходящий подход.
2. Э.Таненбаум, Д.Уэзеролл. Компьютерные сети.
3. В.Г.Олифер, Н.А.Олифер. Компьютерные сети. Принципы, технологии, протоколы.

Мой канал с краткими и понятными объяснениями сложных тем в ИТ и компьютерных науках - @AndreySozykin​

## Содержание

### [0:00](https://www.youtube.com/watch?v=7TK5x7nJ2q4) Установка соединения TLS 1.3 в Wireshark

Привет, я Андрей Сазыкин. Это курс Компьютерные сети. В этом видео мы на практике с помощью Wшаar рассмотрим, как устанавливается соединение в протоколе TLS. Чтобы это сделать, давайте откроем наш сайт с практическими заданиями по курсам. И в этом случае используем протокол https. Чтобы в Wшаark найти нужное нам подключение, установим фильтр по IP-адресу. Ну, напомню, что networkcurs. ru работает на четырёх IP-адресах. Давайте попробуем все. В этот раз подключение осуществляется к вот этому IP-адресу. И первый пакет, с которого выполняется установка соединения TLS - это Client Hello. Вот он. И здесь у нас Wirkвает подсказку. SNI server Network identifier. Имя сервера networkscurse. ru, то есть соединение TLS, которое создано для подключения к нашему сайту. Для того, чтобы проще было работать, давайте включим фильтр именно по этому соединению. Нажимаем на правую кнопку, отслеживать TLS поток. Ну, закроем сам TLS поток, оставим только пакеты. И здесь мы видим, каким образом устанавливается соединение. Сначала клиент отправляет к серверу запрос client Hello. Затем сервер отправляет ответ сервер Hello. Туда включает зашифрованную информацию, в том числе сертификат, сообщение certificate verify и finished. После этого сервер пересылает клиенту тикет CC, который можно будет использовать в дальнейшем, если клиент захочет возобновить эту сессию и использовать те же самые ключи, которые были сгенерированы в этом соединении. И в конце клиент отправляет сообщение Finished. После этого соединение установлено, и по нему передаются данные протокола HTTP. Ну вот здесь видно, что это протокол HTTP версии 2. Давайте более подробно разбираться, как выполняется соединение.

### [2:26](https://www.youtube.com/watch?v=7TK5x7nJ2q4&t=146s) Сообщение Client Hello

Мы начнём с первого пакета. Клиент отправляет запрос на сервер сообщение client Hello. Из чего оно состоит? Ну, во-первых, давайте посмотрим на уровень TLS Record Layer. Протокол записей. Это базовый протокол TLS, в котором передаются все типы сообщений. В нём есть три поля. Первый тип - это content type, тип протокола, который используется внутри, Record Layer, Handshake, протокол установки соединения, версия TLS 1. 0. Но здесь всегда указывается версия 1. 0, потому что о том, какая реальная версия будет использоваться, клиент и сервер как раз договариваются в процессе установки соединения. И затем указывается длина сообщения. Вот это уже сообщение Handshake Protocol протокола установки соединения и тип сообщения client Hello. Дальше ещё раз указывается версия TLS 1,2, но здесь Shark нам подсказывает, что это устаревшее поле, его нужно игнорировать, потому что в разделе extension есть заголовки Supported version. Это более новый вариант выбрать версию TLS, которая будет использоваться для соединения. Что важного есть в запросе Client Hello? Cher switch. Наборы шифров TLS. Здесь клиент показывает достаточно большой набор шифров, которые он поддерживает, и сервер выбирает один из этих шифров для защиты соединения. Что означают эти названия в наборе шифров? Это можно посмотреть, например, в RFC TLS версия 1. 3. В конце есть раздел наборы шифров CER suites. И здесь, во-первых, есть относительно небольшой набор шифров, который поддерживается в TLS 1. 3, их всего пять. И также расписана структура, из чего состоит название набора шифров в TLS 1. 3. Начинается с TLS. Затем название шифра AID. Напомню, что это такие шифры, которые используются и для шифрования, и для обеспечения целостности. Вот это префикс, это название шифра. Это тоже название такого шифра. И в конце указывается значение, которое используется для генерации хэша. Вот эти функции. И если мы вернёмся в Wi Shark, то увидим, что здесь есть не только наборы шифров, которые применяются в TLS 13. И давайте посмотрим в раздел поддерживаемых версий. Вот это раздел supported version. И клиент здесь говорит, что он поддерживает версию TLS1. 3, а также и TLS 1. 2. Ну, TLS 1. 3 - это современная версия и TLS 1. 2 предыдущая версия. Её всё ещё можно использовать. Она обеспечивает безопасность, поэтому клиент предлагает две версии. Сервер должен выбрать ту, которую он поддерживает, а также один из наборов шифров. Что ещё есть в заголовке Client Hello? Важная информация - это сервер, имя сервера, к которому подключаемся. Здесь имя сервера networks. ru. А зачем это нужно? Потому что на одном и том же IP-адресе может работать несколько веб-серверов. И мы рассматриваем именно такой случай. Сайт практических занятий для курсов размещается на сервере GitHub Pages. Там, кроме этого сервера, размещается большое количество и других веб-сайтов. Поэтому, когда мы подключаемся по TLS, непонятно, какой же из сайтов нужен. Именно поэтому в Client Hello добавляется такое расширение с именем сайта, к которому мы хотим подключиться. И сервер GitHub Pages подключает нас именно к этому сайту, а не к какому-то другому. И ещё важная информация client Keys Share. Вот она. Это информация, которая необходима для обмена ключами. И здесь клиент передаёт два варианта. Вот это вариант для алгоритма Дифи Хелмана на эллиптических кривых. А вот это более сложный вариант для гибридного алгоритма, который состоит из двух частей. А первая часть - это опять же алгоритм Дифи Хелмана на эллиптических криевых, а второй MLC 768. сервер выбирает какой-то из этих вариантов, генерирует свою информацию Qhaare, и с её помощью можно получить ключ для симметричного шифрования. Мы

### [7:35](https://www.youtube.com/watch?v=7TK5x7nJ2q4&t=455s) Сообщение Server Hello

рассмотрели всю важную информацию, которая есть в Client Hello. Давайте теперь перейдём к сообщению сервера. Сообщение сервера начинается также с сервер Hello, но кроме этого в нём есть достаточно много дополнительной информации. Опять же в TLS всё начинается с протокола записей Record Layer и тип протокола, который находится внутри Record layer Handshake Protocol протокол установки соединения. Версия TLS указана 1,2, но мы помним, что на неё можно не обращать внимания. Давайте пока свернём и увидим, что внутри одного сообщения TLS есть много внутренних сообщений. Server Hello Change Cher spec зашифрованное расширение сертификат сообщение для проверки сертификата и сообщение finished. Давайте начнём с сообщение сервер Hello. В нём опять же указывается версия TLS 1. 2. И Vark снова нам подсказывает, что на эту версию можно не обращать внимания. Нужно смотреть на то, что находится в поле supported version расширений. Давайте посмотрим. И мы видим, что в расширении supported version указана версия TLS 1. 3. То есть клиент предложил на выбор использовать две версии TLS 1 2 и 1. 3, и сервер выбирает современную версию TLS 1. 3. Затем QSAR, информация, которая нужна для генерации ключей симметричного шифрования. Мы опять же помним, что клиент предложил нам два варианта, и сервер выбрал гибридный алгоритм Дифи Хелмана на эллиптических кривых и MLC 768. Вот информация, которая нужна для генерации ключа симметричного шифрования. Также сервер указывает набор шифров, который он предпочитает использовать. Вот такой набор шифров. Дальше идёт сообщение Change Cher spec. Protocol. Это означает, что всё, что находится дальше, зашифровано. Почему можно зашифровать всю информацию, которая пересылается дальше? Потому что сервер уже получил от клиента необходимую информацию для генерации ключа симметричного шифрования. Клиенту он эту информацию отправил в сообщение сервер Hello. Вот она. И после получения вот этой информации клиент тоже может сгенерировать ключ симметричного шифрования и расшифровать всё, что находится дальше. Поэтому всё, что идёт дальше, зашифровано. Encrypted extension. Зашифрованы расширения. Ну, нас в первую очередь интересует сертификат сервера. Сертификат тоже зашифрован. Здесь мы можем видеть, что у нас два сертификата. Первый - это сертификат сервера. Он выдан организации Ledscript, который выдаёт бесплатные сертификаты для сайтов. А второй - это сертификат организации Leds Encrypt. И этот сертификат подписан доверенным удостоверяющим центром, сертификат которого установлен в моей операционной системе. Давайте посмотрим, как всё это устроено. Начнём с сертификата сайта Poле Isure. Кто выдал сертификат? Организация Let's encrypt. Ну, обозначение R13. Валидный этот сертификат. Дата начала действия сертификата и дата конца действия сертификата. Но в настоящее время сертификат действует. Кому выдан сертификат? Сайтуcourse. ru. Ну, важно проверять, что сертификат, который нам прислали, выдан именно тому сайту, к которому мы обращаемся. В противном случае может оказаться так, что злоумышленник возьмёт реальный действующий сертификат, ну, и просто будет его использовать для своего сайта, хотя на самом деле сайт у него другой. Ну и есть дополнительные расширения. И самая важная информация находится в разделе Subject Public Info. Это, собственно, и есть внешний ключ сервера, тип ключа RSA. Ну вот этот внешний ключ. Проблема этого сертификата в том, что он выдан организации Let'ss Encrypt. Про эту организацию мы ничего не знаем, поэтому не можем оценить. Можем мы доверять такому сертификату или нет. Именно поэтому в сообщение вложен сертификат Let's Encrypt. Давайте посмотрим. Да, сертификат Let's Encrypt. Кем выдан этот сертификат? Удостоверяющим центром ESRG root X1. И теперь, если мы зайдём в список доверенных корневых удостоверяющих центров, ну, напомню, что это список сертификатов корневых удостоверяющих центров, которые установлены в моей операционной системе Windows. Обычно их устанавливает производитель. Здесь есть сертификат этого удостоверяющего центра. Таким образом, моя операционная система доверяет этому корневому удостоверяющему центру. Соответственно, она доверяет организации Encrypt, которая выдала сертификат сайту Networks Course. Следующее сообщение Certificate Verify. Ну, напомню, зачем оно нужно. В предыдущем сообщении мы получили сертификат и открытый ключ, но эта информация доступна в интернете. Я могу подключиться к серверу Network CS, скачать сертификат и потом отдавать другим пользователям именно этот сертификат. Но при этом у меня нет закрытого ключа сервера Network CS для того, чтобы клиент был уверен в том, что сервер владеет закрытым ключом, сервер шифрует небольшое сообщение с закрытым ключом сертификата и передаёт это зашифрованное сообщение как раз в сообщение certificate verify. То есть в данном случае закрытый ключ используется для реализации алгоритма цифровой подписи. И вот эта подпись. Последнее сообщение со стороны сервера для установки соединения финиш. Напомню, зачем нужно сообщение finished. Оно нужно для обеспечения целостности всего процесса соединения. Что делает сервер? Он берёт сообщение клиента, все свои сообщения, считает от них хэш функцию и вставляет вот сюда в сообщение finished. Клиент, когда получит от сервера сообщение финиш, выполняет ту же самую операцию и сравнивает полученные результаты с тем, что есть в сообщении finished. Если результаты совпадают, значит, в процессе установки соединения не было нарушена целостность, сообщения не были изменены. Давайте перейдём

### [15:09](https://www.youtube.com/watch?v=7TK5x7nJ2q4&t=909s) Ticket сессии

[откашливается] к следующему сообщению. New session ticket. А что это такое? После того, как со стороны сервера установка соединения завершена, сервер передаёт клиенту так называемый session ticket, билет сессии. Он выглядит вот таким образом. большой номер, который можно использовать для того, чтобы восстановить соединение. Session Ticket действует 1 день, и клиент, если захочет, при подключении в течение 1ного дня может не проходить заново весь процесс установки соединения, а использовать более короткий вариант Zero RTT. прямо в сообщение client Hello вставить данные, которые зашифрованы ключами, которые были созданы вот для этой сессии. Ну и как мы с вами уже обсуждали в лекции, к сожалению, это негативно влияет на безопасность.

### [16:10](https://www.youtube.com/watch?v=7TK5x7nJ2q4&t=970s) Сообщение Client Finished

Последнее сообщение в процессе установки соединения сообщение клиента. Оно содержит две части. Первая change spec говорит о том, что дальше клиент тоже шифрует все передаваемые данные. Ну, напомню, что клиент уже получил от сервера сообщения QR, сгенерировал ключи для симметричного шифрования и теперь спокойно может шифровать данные. Важная часть со стороны клиента - это сообщение финиш. Оно нужно точно так же, как и сообщение финишит со стороны сервера для того, чтобы подтвердить целостность всего процесса установки соединения. Клиент также считает хэш функцию от всех сообщений, которые были в процессе установки соединения. передаёт серверу. Сервер проверяет, сравнивает с теми сообщениями, которые он получил самостоятельно рассчитывая значение этой хэш функции. И если значение совпадает, то целостность процесса установки соединения подтверждена. И дальше передаются данные. Ну вот здесь видно, что данные передаются по протоколу HTP версия 2. Ну как устроен этот протокол, мы рассмотрим более подробно. Далее в курсе. Какие именно механизмы

### [17:34](https://www.youtube.com/watch?v=7TK5x7nJ2q4&t=1054s) Просматриваем механизмы защиты соединения в браузере

используются для защиты соединения, можно также посмотреть в браузере. Если мы нажмём F12, инструменты разработчика, перейдём в раздел конфиденциальность и безопасность. И вот здесь видим, что это безопасная страница. Подключение к сайту зашифровано и выполнена аутентификация. Протокол TLS1. 3. Алгоритм обмена ключами DIFY Helman на основе эллиптических кривых и MLCM 768. Для шифрования и проверки целостности используется шифр A128 GCM. Давайте ещё раз посмотрим, что сервер выбрал именно этот тип шифрования. Да, именно этот тип. Ну и также здесь мы можем посмотреть сертификат. Сертификат выданs encript, дата выдачи, срок действия, сам сертификат и открытый ключ. То, что мы сейчас смотрели в Shark. Более подробно можно посмотреть вот на этой вкладке.

### [18:42](https://www.youtube.com/watch?v=7TK5x7nJ2q4&t=1122s) Итоги

Итак, теперь вы знаете, как устанавливается соединение в TLS 1. 3. На этом практическое занятие закончилось. Спасибо, что смотрели. До свидания. Yeah.

---
*Источник: https://ekstraktznaniy.ru/video/51465*