12. Сертификаты в информационной безопасности¶
1. Введение¶
Пользователь открывает сайт банка:
Но злоумышленник может попытаться вмешаться в соединение:
В такой ситуации возникает важный вопрос: Как пользователь может понять, что сервер действительно является тем сервером, за который себя выдаёт?
Одного шифрования недостаточно. Можно зашифровать соединение с сервером злоумышленника, и данные всё равно будут защищены от посторонних наблюдателей, но сам злоумышленник будет получать их в расшифрованном виде на своей стороне.
Поэтому в защищённых соединениях необходимо решить две задачи: 1. установить защищённый канал связи; 2. убедиться в подлинности стороны, с которой устанавливается соединение.
Одним из основных механизмов решения этой задачи являются цифровые сертификаты.
Что такое цифровой сертификат¶
Цифровой сертификат — это электронный документ, который связывает определённые идентификационные данные с открытым ключом и подтверждает эту связь с помощью цифровой подписи удостоверяющего центра.
Упрощённо сертификат можно представить следующим образом:
Сертификат
│
├── Имя владельца
├── Доменное имя
├── Открытый ключ
├── Срок действия
├── Информация об издателе
├── Назначение сертификата
└── Цифровая подпись удостоверяющего центра
Например, веб-сервер может предоставить сертификат, в котором указано, что открытый ключ относится к определённому доменному имени.
Важно понимать: сертификат не является самим ключом.
Сертификат содержит открытый ключ и дополнительную информацию, которая позволяет проверить его принадлежность определённому владельцу.
Зачем нужны сертификаты¶
Цифровые сертификаты используются для решения нескольких задач.
Основные из них: - подтверждение подлинности сервера; - связывание доменного имени с открытым ключом; - безопасный обмен ключевой информацией; - построение доверенной инфраструктуры; - создание защищённых соединений; - подтверждение подлинности пользователей и организаций в некоторых системах; - использование электронной цифровой подписи.
В контексте веб-сайтов наиболее знакомым примером является HTTPS.
Когда браузер подключается к сайту по HTTPS, сервер предоставляет сертификат.
Упрощённая схема выглядит так:
Браузер
│
│ запрос HTTPS
▼
Сервер
│
│ сертификат
▼
Браузер проверяет сертификат
│
├── сертификат действителен → продолжаем соединение
│
└── проблема с сертификатом → предупреждение
Сертификат и открытый ключ¶
Чтобы понять назначение сертификата, необходимо вспомнить принцип асимметричной криптографии.
При использовании асимметричной криптографии создаётся пара ключей:
Открытый ключ¶
Открытый ключ можно передавать другим участникам.
Он не считается секретным.
Закрытый ключ¶
Закрытый ключ должен храниться в секрете.
Если злоумышленник получает закрытый ключ, безопасность соответствующей системы может быть серьёзно нарушена.
Почему недостаточно просто передать открытый ключ¶
Предположим, браузер подключается к серверу.
Сервер говорит:
Но злоумышленник может сделать то же самое:
Если браузер просто получает открытый ключ и никак не проверяет его происхождение, возникает проблема.
Злоумышленник может подменить открытый ключ своим.
Схема атаки:
Браузер
│
│ хочет подключиться к bank.example.ru
▼
Злоумышленник
│
│ представляет свой ключ
▼
Браузер
Поэтому необходимо не только получить открытый ключ, но и иметь возможность проверить: кому этот ключ принадлежит и можно ли доверять этой информации.
Именно здесь появляется сертификат.
Связь доменного имени и открытого ключа¶
Сертификат позволяет связать идентификатор сервера с открытым ключом.
Упрощённо:
Браузер получает сертификат и проверяет, соответствует ли указанное в нём имя тому адресу, к которому пользователь пытается подключиться.
Например:
Если имя соответствует требованиям сертификата, эта часть проверки пройдена.
Если же сертификат выдан для другого имени:
возникает проблема.Браузер должен предупредить пользователя о несоответствии.
Кто выдаёт сертификаты¶
Возникает следующий вопрос: Кто решает, каким сертификатам можно доверять?
Для этого существует инфраструктура открытых ключей и специальные организации — удостоверяющие центры.
На английском используется термин: CA — Certificate Authority.
На русском: УЦ — удостоверяющий центр.
Удостоверяющий центр выпускает сертификаты и подписывает их своим закрытым ключом.
Упрощённая схема:
Владелец сайта
│
│ запрос на сертификат
▼
Удостоверяющий центр
│
│ проверка необходимых данных
▼
Сертификат
│
│ подписан УЦ
▼
Веб-сервер
После этого сервер предоставляет сертификат клиенту.
Цифровая подпись сертификата¶
Одна из важнейших частей сертификата — цифровая подпись удостоверяющего центра.
Упрощённо процесс можно представить так:
Информация сертификата
│
▼
Хеширование
│
▼
Формирование подписи
с использованием закрытого ключа УЦ
│
▼
Цифровая подпись
Получатель сертификата может использовать открытый ключ удостоверяющего центра для проверки подписи.
Упрощённо:
Если данные сертификата были изменены после подписания, проверка цифровой подписи не пройдёт.
Таким образом, подпись помогает обнаружить подмену или изменение содержимого сертификата.
Корневые удостоверяющие центры¶
Но возникает новый вопрос:
Откуда браузер знает, что самому удостоверяющему центру можно доверять?
Для этого в операционной системе и браузерах существует хранилище доверенных сертификатов.
В нём находятся сертификаты доверенных корневых удостоверяющих центров.
Например:
Операционная система
│
▼
Хранилище доверенных сертификатов
│
├── Корневой УЦ №1
├── Корневой УЦ №2
├── Корневой УЦ №3
└── ...
Таким образом формируется цепочка доверия.
Цепочка доверия¶
На практике сертификат веб-сервера не обязательно подписывается непосредственно корневым удостоверяющим центром.
Между ними могут находиться промежуточные удостоверяющие центры.
Например:
Такая структура называется цепочкой сертификатов или цепочкой доверия.
Браузер проверяет эту цепочку.
Упрощённо:
Сертификат сервера
│
▼
Промежуточный сертификат
│
▼
Корневой сертификат
│
▼
Доверие операционной системы
Если цепочка корректна и заканчивается доверенным корневым сертификатом, сертификат сервера может считаться доверенным.
Почему корневой сертификат считается доверенным¶
Корневой сертификат является особым элементом инфраструктуры.
Его открытый ключ используется для проверки подписей, связанных с соответствующим удостоверяющим центром.
Корневые сертификаты заранее добавляются в доверенное хранилище операционной системы или браузера.
Получается модель:
Если конечный сертификат связан с доверенным корневым центром через корректную цепочку, клиент может ему доверять.
Что содержится в сертификате¶
Цифровой сертификат содержит множество полей.
Среди наиболее важных:
| Поле | Назначение |
|---|---|
| Subject | информация о владельце сертификата |
| Issuer | удостоверяющий центр, выдавший сертификат |
| Public Key | открытый ключ владельца |
| Valid From | начало срока действия |
| Valid To | окончание срока действия |
| Serial Number | уникальный номер сертификата |
| Signature Algorithm | алгоритм цифровой подписи |
| Key Usage | назначение ключа |
| Extended Key Usage | расширенное назначение |
| Subject Alternative Name | имена, для которых действует сертификат |
| Signature | цифровая подпись удостоверяющего центра |
Subject и Issuer¶
Два важных поля:
Subject — кому принадлежит сертификат.
Issuer — кто выдал сертификат.
Например:
Это означает, что сертификат предназначен для указанного объекта и был выдан определённым удостоверяющим центром.
Subject Alternative Name¶
Современные сертификаты могут содержать поле: Subject Alternative Name — SAN.
Оно используется для указания имён и других идентификаторов, для которых действителен сертификат.
Например:
Это позволяет одному сертификату использоваться для нескольких доменных имён.
При проверке HTTPS браузер учитывает соответствующие имена из SAN.
Срок действия сертификата¶
Сертификат имеет срок действия.
Например:
После окончания срока действия сертификат считается недействительным.
Это необходимо учитывать администраторам.
Если сертификат сайта закончился, пользователи могут получить предупреждение:
Поэтому срок действия сертификатов необходимо контролировать заранее.
Почему сертификат нельзя просто скопировать¶
Предположим, сертификат принадлежит серверу:
Злоумышленник может получить сам сертификат.
Это не обязательно является проблемой.
Причина в том, что сертификат содержит открытый, а не закрытый ключ.
Главный секрет находится в закрытом ключе.
Упрощённо:
Сертификат
│
└── Открытый ключ → можно распространять
Закрытый ключ
│
└── должен храниться в секрете
Злоумышленник может скопировать сертификат, но без соответствующего закрытого ключа он не сможет полноценно выступать от имени владельца сертификата в тех механизмах, где требуется доказательство владения закрытым ключом.
Сертификат и HTTPS¶
Наиболее распространённый пример использования сертификатов — HTTPS.
HTTPS представляет собой защищённую работу HTTP поверх TLS.
Упрощённо:
При подключении к HTTPS-сайту сервер предоставляет сертификат.
Браузер выполняет проверки.
Упрощённо:
1. Сервер предоставляет сертификат
│
▼
2. Проверка срока действия
│
▼
3. Проверка имени сайта
│
▼
4. Проверка цифровой подписи
│
▼
5. Проверка цепочки доверия
│
▼
6. Проверка назначения сертификата
│
▼
7. Продолжение установки TLS-соединения
При успешной установке защищённого соединения данные передаются в зашифрованном виде.
Что происходит при открытии HTTPS-сайта¶
Рассмотрим упрощённый сценарий.
Пользователь вводит:
Браузер обращается к серверу.
Сервер предоставляет сертификат.
Браузер проверяет:
Имя подходит?
│
▼
Сертификат не просрочен?
│
▼
Подпись действительна?
│
▼
Цепочка доверия корректна?
│
▼
Назначение сертификата подходит?
│
▼
Да → продолжаем соединение
После этого устанавливается защищённый канал TLS.
Что означает значок замка в браузере¶
Рядом с HTTPS-адресом браузер обычно показывает информацию о защищённом соединении.
Важно понимать: замок не означает, что сайт обязательно является честным или безопасным во всех смыслах.
Он прежде всего показывает, что браузер смог установить защищённое соединение и успешно выполнил необходимые проверки сертификата и TLS.
Например, мошенники могут зарегистрировать собственный домен:
и получить для него действительный сертификат.
Браузер может показать корректное HTTPS-соединение.
Но это не превращает мошеннический сайт в настоящий сайт банка.
Поэтому необходимо различать:
Сертификат не защищает от всех видов мошенничества¶
Предположим, пользователь получил письмо:
На сайте действительно используется HTTPS.
Сертификат действителен.
Но домен принадлежит злоумышленнику.
Следовательно:
Пользователь должен самостоятельно проверить доменное имя.
Как сертификат помогает против Man-in-the-Middle¶
Рассмотрим атаку Man-in-the-Middle.
Злоумышленник пытается расположиться между клиентом и сервером:
Чтобы атака была успешной, злоумышленнику необходимо убедить клиента, что его сторона является настоящим сервером.
При использовании TLS клиент проверяет сертификат.
Если злоумышленник предоставляет сертификат:
но он не подписан доверенным удостоверяющим центром или не соответствует другим требованиям проверки, браузер обнаружит проблему.
Например:
Это значительно усложняет проведение MitM-атаки.
Что произойдёт при поддельном сертификате¶
Если злоумышленник создаёт собственный сертификат:
это ещё не означает, что браузер ему доверит.Браузер проверяет цепочку доверия.
Например:
В этом случае пользователь может увидеть предупреждение.
Почему злоумышленник не может просто подписать сертификат сам¶
Любой человек может создать собственный сертификат и самостоятельно подписать его.
Но такой сертификат не будет автоматически считаться доверенным.
Можно представить ситуацию:
Проблема заключается в том, что этот УЦ отсутствует среди доверенных корневых центров.
Поэтому:
Однако в корпоративных и учебных сетях собственные удостоверяющие центры могут использоваться намеренно.
Самоподписанный сертификат¶
Самоподписанный сертификат — сертификат, подписанный собственным закрытым ключом, а не доверенным внешним удостоверяющим центром.
Упрощённо:
Такой сертификат может использоваться: - в лабораториях; - на внутренних серверах; - в тестовых системах; - при разработке; - в некоторых закрытых корпоративных инфраструктурах.
Но если клиент заранее не доверяет этому сертификату или соответствующему УЦ, браузер обычно выдаст предупреждение.
Собственный удостоверяющий центр организации¶
Крупные организации могут использовать собственную инфраструктуру PKI.
Например:
Рабочие станции организации заранее получают корневой сертификат этого УЦ.
После этого внутренние сертификаты могут считаться доверенными.
Например:
может использовать сертификат, выданный внутренним удостоверяющим центром.
PKI¶
Инфраструктура, предназначенная для управления открытыми ключами и цифровыми сертификатами, называется: PKI — Public Key Infrastructure.
По-русски: инфраструктура открытых ключей.
PKI включает не только сертификаты.
В неё могут входить: - удостоверяющие центры; - сертификаты; - ключи; - процедуры выпуска сертификатов; - процедуры отзыва; - политики доверия; - хранилища сертификатов; - механизмы проверки статуса сертификатов.
Упрощённо:
Отзыв сертификата¶
Иногда сертификат необходимо сделать недействительным до окончания его срока.
Например, если: - был скомпрометирован закрытый ключ; - сертификат выдан ошибочно; - организация больше не владеет доменом; - сертификат использовался неправильно.
В таком случае сертификат может быть отозван.
Упрощённо:
Сертификат действителен
│
│ обнаружена проблема
▼
Отзыв
│
▼
Сертификат больше не должен использоваться
CRL¶
Одним из механизмов проверки отозванных сертификатов является: CRL — Certificate Revocation List.
По-русски: список отозванных сертификатов.
Удостоверяющий центр публикует список сертификатов, которые больше нельзя считать действительными.
Упрощённо:
Если серийный номер сертификата находится в списке, сертификат считается отозванным.
OCSP¶
Другой механизм проверки статуса сертификата: OCSP — Online Certificate Status Protocol.
Вместо получения большого списка клиент может запросить статус конкретного сертификата.
Упрощённо:
или:
Таким образом, CRL и OCSP решают схожую задачу — позволяют определить, не был ли сертификат отозван.
Сертификаты и электронная подпись¶
Сертификаты используются не только для HTTPS.
Они могут применяться для электронной подписи.
Упрощённая схема:
Сертификат помогает связать открытый ключ с определённым владельцем.
Получатель может проверить:
Таким образом сертификаты позволяют создавать инфраструктуру доверия вокруг электронных подписей.
Сертификат и идентификация¶
Важно различать несколько понятий.
Аутентификация¶
Определение того, кто именно является участником взаимодействия.
Авторизация¶
Определение того, что этому участнику разрешено делать.
Сертификат¶
Механизм, позволяющий связать открытый ключ с определённой идентификационной информацией и подтвердить эту связь цифровой подписью.
Например:
Но сам факт наличия сертификата не означает автоматически наличие каких-либо прав доступа.
Сертификаты пользователей¶
Сертификаты могут выдаваться не только серверам.
В некоторых системах сертификаты используются для идентификации пользователей или устройств.
Например:
Такой подход называется взаимной аутентификацией или mTLS — mutual TLS.
В обычном HTTPS чаще всего сервер доказывает свою подлинность клиенту.
В mTLS стороны могут аутентифицировать друг друга.
Обычный TLS и взаимная аутентификация¶
Обычный сценарий:
Клиент ─────────► Сервер
◄────── Сертификат сервера
Сервер подтверждает свою подлинность
перед клиентом.
При mTLS:
В результате сервер также может убедиться, что подключается доверенное устройство или пользователь.
mTLS применяется, например, в некоторых корпоративных системах и API.
Типичные ошибки при работе с сертификатами¶
Администраторы могут столкнуться с различными проблемами.
1. Сертификат просрочен¶
2. Неверное имя¶
Сертификат выдан для другого домена.
3. Нарушена цепочка доверия¶
Клиент не может построить цепочку до доверенного корневого сертификата.
4. Неизвестный удостоверяющий центр¶
Клиент не доверяет центру, который выдал сертификат.
5. Сертификат отозван¶
Сертификат больше не должен использоваться.
6. Неправильное назначение¶
Сертификат или ключ не предназначен для необходимого типа использования.
Что видит пользователь при ошибке сертификата¶
Например, пользователь открывает сайт, но браузер обнаруживает проблему.
Возможные причины:
Сертификат просрочен
или
Имя не соответствует
или
Не доверен удостоверяющий центр
или
Нарушена цепочка доверия
Браузер может показать предупреждение.
Для администратора это сигнал о необходимости выяснить причину.
Важно: не следует автоматически игнорировать предупреждения сертификата.
Особенно опасно делать это при работе с: - банковскими системами; - корпоративными порталами; - административными интерфейсами; - системами управления; - почтовыми серверами; - VPN; - API.
Почему нельзя бездумно нажимать «Продолжить»¶
Предупреждение сертификата может означать обычную административную ошибку.
Например:
Но оно также может означать попытку перехвата соединения.
Например:
Поэтому администратор должен сначала выяснить причину предупреждения.
Сертификаты и CIA¶
Рассмотрим сертификаты с точки зрения модели CIA.
Confidentiality — конфиденциальность¶
TLS использует криптографические механизмы для защиты передаваемых данных.
Сертификат участвует в установлении доверенного защищённого соединения.
Integrity — целостность¶
TLS обеспечивает защиту данных от незаметного изменения в процессе передачи.
Сертификаты и криптографические механизмы участвуют в формировании доверенного соединения.
Availability — доступность¶
Сертификаты напрямую не обеспечивают доступность.
Однако неправильная работа сертификатов может привести к недоступности сервиса для пользователей.
Например:
Сертификат истёк
↓
Браузер предупреждает
↓
Пользователь не может нормально работать
↓
Сервис фактически становится недоступным
Сертификаты и защита от MitM¶
При обычном MitM злоумышленник пытается занять положение между двумя сторонами:
TLS с проверкой сертификата создаёт дополнительный уровень защиты:
Клиент
│
│ проверяет сертификат
▼
Злоумышленник
│
└── поддельный сертификат
│
▼
Проверка доверия
│
▼
ОШИБКА
Поэтому сертификаты являются одним из важных элементов защиты от определённых вариантов MitM.
Что должен контролировать сетевой администратор¶
Сетевой администратор должен контролировать состояние сертификатов используемых сервисов.
В частности: - срок действия; - доменные имена; - цепочку доверия; - удостоверяющий центр; - алгоритмы и параметры ключей; - назначение сертификата; - состояние отзыва; - хранение закрытых ключей; - своевременное продление.
Для большого количества серверов полезно использовать централизованный мониторинг.
Например:
Сервер 1 ── сертификат ── 120 дней
Сервер 2 ── сертификат ── 45 дней
Сервер 3 ── сертификат ── 7 дней
Администратор должен заранее получить предупреждение:
Защита закрытого ключа¶
Одной из наиболее важных задач является защита закрытого ключа.
Сертификат можно сделать публично доступным.
Закрытый ключ — нет.
Упрощённо:
Если злоумышленник получает закрытый ключ сервера, последствия могут быть серьёзными.
Поэтому необходимо: - ограничивать доступ к ключу; - использовать защищённые хранилища; - устанавливать правильные права доступа; - не передавать ключ через незащищённые каналы; - своевременно менять ключи при компрометации; - отзывать соответствующие сертификаты.
Сертификат — не просто «шифровани延
Распространённая ошибка — считать:
«Сертификат нужен для шифрования сайта».
Это упрощённое представление.
Сертификат сам по себе не является механизмом шифрования всего трафика.
Он содержит открытый ключ и сведения, позволяющие подтвердить связь ключа с определённым субъектом.
В HTTPS сертификат является частью более сложного процесса установления TLS-соединения.
Упрощённо:
Сертификат
↓
Проверка подлинности
↓
Установление доверия
↓
TLS
↓
Согласование защищённого соединения
↓
Шифрование и защита трафика
Упрощённая общая схема работы¶
Весь процесс можно представить следующим образом:
Удостоверяющий центр
│
│ подписывает
▼
Сертификат сервера
│
▼
Клиент ───────────────► Сервер
│ │
│ Сертификат │
│◄───────────────────────│
│
│ Проверка:
│ ├─ срок действия
│ ├─ имя
│ ├─ подпись
│ ├─ цепочка доверия
│ └─ назначение
│
▼
Установка TLS
│
▼
Защищённое соединение
│
▼
Передача данных
Основные виды сертификатов по назначению¶
Сертификаты могут использоваться для различных целей.
Сертификаты серверов¶
Используются для идентификации серверов и установления защищённых соединений.
Пример:
Сертификаты клиентов¶
Используются для идентификации клиентов.
Пример:
Сертификаты электронной подписи¶
Используются для создания и проверки электронных подписей.
Сертификаты удостоверяющих центров¶
Используются для построения инфраструктуры доверия.
Сертификаты в сетевой инфраструктуре¶
Для сетевого администратора сертификаты могут встречаться практически во всех крупных сетевых системах.
Например:
Сетевая инфраструктура
│
┌───────────────┼───────────────┐
│ │ │
HTTPS VPN Почта
│ │ │
Сертификат Сертификат Сертификат
Также сертификаты могут использоваться в: - корпоративных порталах; - API; - прокси-серверах; - VPN; - системах удалённого доступа; - почтовых системах; - системах мониторинга; - сетевых устройствах; - системах аутентификации.
Практический пример¶
Предположим, организация имеет внутренний портал:
Сервер предоставляет сертификат.
В сертификате указано:
Цепочка:
Рабочие компьютеры организации доверяют:
Поэтому браузер может построить цепочку:
Соединение устанавливается без предупреждения.
Что произойдёт после компрометации закрытого ключа¶
Рассмотрим ситуацию:
Администратор не должен просто заменить файл сертификата и считать проблему решённой.
Необходимо: 1. прекратить использование скомпрометированного ключа; 2. создать новую ключевую пару; 3. получить новый сертификат; 4. при необходимости отозвать старый сертификат; 5. проверить системы, где использовался старый ключ; 6. проанализировать возможные последствия компрометации.
Это показывает, почему управление сертификатами является частью информационной безопасности, а не просто технической настройкой веб-сервера.
Типичные ошибки пользователей и администраторов¶
Ошибка 1. Игнорирование предупреждений¶
Пользователь нажимает:
не выясняя причину.Ошибка 2. Просроченные сертификаты¶
Администратор не контролирует сроки действия.
Ошибка 3. Неправильное доменное имя¶
Сертификат не соответствует адресу сервера.
Ошибка 4. Установка неизвестного корневого сертификата¶
Пользователь или администратор добавляет неизвестный сертификат в доверенное хранилище.
Ошибка 5. Небезопасное хранение закрытого ключа¶
Ключ доступен слишком большому числу пользователей или сервисов.
Ошибка 6. Использование одного ключа слишком долго¶
При необходимости ключ должен быть заменён в соответствии с политикой безопасности.
Основные понятия¶
| Термин | Значение |
|---|---|
| Цифровой сертификат | документ, связывающий идентификатор и открытый ключ |
| Public Key | открытый ключ |
| Private Key | закрытый ключ |
| CA | удостоверяющий центр |
| Root CA | корневой удостоверяющий центр |
| Intermediate CA | промежуточный удостоверяющий центр |
| PKI | инфраструктура открытых ключей |
| TLS | протокол защищённого сетевого взаимодействия |
| HTTPS | HTTP поверх TLS |
| CRL | список отозванных сертификатов |
| OCSP | механизм проверки статуса сертификата |
| SAN | альтернативные имена субъекта сертификата |
| mTLS | TLS с взаимной аутентификацией сторон |
Главное, что необходимо запомнить¶
Цифровой сертификат нужен прежде всего для формирования доверия к открытому ключу.
Главная идея:
При подключении по HTTPS клиент проверяет сертификат.
Основные проверки:
Сертификаты являются важным элементом защиты от определённых вариантов Man-in-the-Middle и используются в TLS, HTTPS, VPN, электронной подписи, корпоративных системах и других технологиях.
При этом сертификат не гарантирует, что сам сайт является добросовестным. Он подтверждает определённую криптографическую связь и принадлежность ключа указанному субъекту в рамках принятой модели доверия.
Заключение¶
Цифровые сертификаты являются одним из фундаментальных механизмов современной информационной безопасности.
Они позволяют решить важную проблему: как связать открытый ключ с определённым субъектом и убедиться, что этот ключ не был просто выдан неизвестным участником сети.
Основой доверия является инфраструктура открытых ключей:
Для сетевого администратора работа с сертификатами включает не только их установку. Необходимо контролировать сроки действия, цепочки доверия, назначение сертификатов, состояние отзыва и особенно безопасность закрытых ключей.
Таким образом, сертификаты связывают изученные ранее темы — криптографию, аутентификацию, HTTPS, защиту трафика и противодействие Man-in-the-Middle — в единую систему доверенного сетевого взаимодействия.