Вопросы безопасности сетевых протоколов

Безопасность: надёжность и секретность.

1. Ненадёжная природа всемирной сети и борьба с ней
   • Повышение связности
   • Резервирование ресурсов (например, IPv6) и оverprovisioning
   • Репликация и «приближение» сервисов
   • ЗБЧ
2. Секретность и Интернет ☺
   • Проблемы аутентичности данных
   • Проблемы скрытия данных

Чрезмерно упрощённая классификация видов атак:

• Порча канала и DOS
• Чтение / деанонимизация
• Модификация / полная подмена данных

История сетевых протоколов в свете защиты данных

0. «Просто» протоколы: TELNET, FTP, SMTP, POP, … (см. dsniff), Basic HTTP Auth

1. Security through obscurity и другие наивные методы шифрования (например, обмен ключами в начале сеанса): MIT-MAGIC-COOKIE-1 и т. п.

   • Проблема «прозрачного» обмена ключами. Например, MMC-1 предназначены для локальных клиентов: ключ записывается в файл (из которого его читает сервер), а подключение происходит по сети к тому же серверу

2. Введение алгоритмов шифрования:

   • в уровень представления согласно модели ISO/OSI (примерно работал SSL-1.0): сначала защищённый канал, потом — прикладной протокол

   • в прикладной протокол: HTTPS, STARTTLS в почтовых и некоторых других прикладных протоколах и т. п.

   • в «межъящичное пространство» TCP/IP TLS, более

3. Использование асимметричного шифрования
4. Как шифрованные тоннели победили шифрованный payload.
   • Пассивный анализ
   • Лёгкая дешифрация мелких/стандартных пакетов
   • Даже если шифровать только payload, перестаёт работать разумный контент-анализатор (например, NAT)

5. «Полицейские и воры» в современной криптографии (см. Возможные атаки на TLS, История атак на TLS/SSL)

Несекретность протоколов «первого поколения»

Давно нигде не применяются.

простейший сервер в BASIC HTTP auth

• tcpdump -X выдаст строку, которая в действительности base64("login:password")

Симметричное шифрование

Симметричное шифрование:

• Обмен ключами ⇒ вероятность засвечивания
• Мнение папаши Мюллера: «Что знают двое, знает и свинья»
• Нет аутентичности

Учётные данные: дайджест вместо пароля

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

• Сервер сообщает клиенту достаточно случайный одноразовый ключ (т. н. Nonce)

• Клиент формирует структуру из учётных данных и ключа и возвращает в качестве ответа хеш этой структуры
• Сервер формирует аналогичный хеш и сравнивает его с ответом
  • ⇒ Требуется хранить полный пароль на сервере

Пример: HTTP Digest Access Authentication

• Например, бессмысленно хранить вместо пароля константный хеш

Асимметричное шифрование

• Начало:
  • (Диффи, Хеллман, Меркль 1975) Использование различных, не выводимых друг из друга функций шифрования и дешифрования

  • (Ривест, Шамир, Адельман 1977) RSA

  • (неизвестные британские учёные ранних 70-х) «Мы это раньше открыли, но нас засекретили»
• Открытый (передаваемый) и закрытый (секретный) ключи:
  • запрет передачи секретного ключа

  • обеспечение секретности: A: О_Б(данные) → B: З_Б(данные)

  • обеспечение аутентичности: A: З_А(данные) → B: О_А(данные)

• Высокая вычислительная сложность:

  • Сеансовый ключ симметричного шифрования

Проблема надёжности первоначального обмена ключами

Если вся значимая информация доступна для перехвата (чтения и воспроизведения) стороннему наблюдателю (например, и открытый ключ, и шифруемые им данные передаются в одном сеансе), возможна т. н. «Атака посредника» (man-in-the-middle, MItM):

• наблюдатель подменяет передаваемый открытый ключ получателя своим

• отправитель шифрует сообщения этим подложным ключом
• наблюдатель их дешифрует, затем шифрует перехваченным ключом получателя
• получатель успешно дешифрует подсмотренный или изменённый контент

Пример MItM-атаки в классической литературе

Использование SSH

См. LecturesCMC/LinuxApplicationDevelopment2021/00_GitSsh

SSL-сертификаты и цепочка доверия

SSH редко требует передачи ключа, можно потратиться на сравнение хешей вручную.

Другое дело HTTPS:

• 443 порт
• Частичная передача заголовков (например, доменного имени)

  • Однако Encrypted Client Hello

• Первоначальный обмен подписанными ключами

  • Организации, подписывающие вам ключи (обычно за деньги) — теряют популярность
  • Первоначальный обмен ключами? ☺

    • ⇒ список известных организаций (например, в пакете ca-certificates,

      • т. е. в файле /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit

  • https://letsencrypt.org

• Можно добавить собственный ключ в список доверенных
  • Так поступают некоторые «корпоративные межсетевые экраны», организуя «MITM-атаку на постоянке»

Пример для socat (чуть-чуть усложняя создание самоподписанного сертификата)

• (у администратора) Генерируем т. н. CA: закрытый ключ и открытый сертификат для проверки подписи:

  # openssl genrsa -out rootCA.key
  # openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt -batch

• (на сервере) Генерируем закрытый ключ и запрос на подпись открытого сертификата:

  # openssl genrsa -out srv.key
  # openssl req -new -key srv.key -out srv.csr -subj '/CN=server_name/'

  • В нашем случае в качестве server_name придётся взять адрес сервера

• Пересылаем запрос администратору. Администратор подписывает открытый сертификат сервера и отсылает его обратно:

  # openssl x509 -req -in srv.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out srv.crt -days 365 -sha256

Запустим сервер

# socat openssl-listen:1234,reuseaddr,fork,cert=srv.crt,key=srv.key,verify=0 EXEC:/usr/bin/cal

• verify= означает, что мы не проверяем сертификат клиента

Запустим клиент:

# socat openssl:server_name:1234,cafile=rootCA.crt -

Если указать не такой server_name, как в сертификате, поверка не пройдёт!

Вся эта цепочка также подвержена MItM — необходимо перехватить обычный канал связи и тот, по которому передаётся подписанный сертификат (помечено )

Д/З

1. Суть: настроить клиент и сервер с использованием SSL, но подменить по дороге сертификат
2. Преднастройка площадки:

   • Сеть: client - router - srv

   • router

     • Пересылка пакетов

     • Таблица с именем mitm правил nftables, которые перехватывают входящий трафик, адресованный srv по портам R и S, и перенаправляют их локально на соответствующие порты

       • nftables пока не запускаем

     • Простейший сценарий mitm.sh, который ходит по SSL к srv за датой (не проверяя сертификат), подменяет в ней 2026 год на 1337 и выводит на стандартный вывод

       • (нажмите «Комментарии» в шапке страницы, чтобы прочитать спойлер) Это socat … STDIO | sed 's/2026/1337/'

3. Отчёт

   1. report 12 srv

      • Генерируем CA — ключ, затем — сертификат rootCA.crt

      • Запускаем в фоне socat, который отдаёт rootCA.crt по сети на порту R без шифрования

      • Генерируем SSL-сертификат, подписанный этим rootCA.crt

      • ls

      • Запускаем socat, который отдаёт по SSL date по порту S с подписанным сертификатом

   2. На client

      • Получаем rootCA.crt с сервера, порт R

        • (нажмите «Комментарии» в шапке страницы, чтобы прочитать спойлер) Например, с помощью socat … FILE:…,create

      • ls

      • Получаем дату с сервера, порт S (с проверкой сертификата)

   3. На router

      • ip -br -4 a

      • sh mitm.sh

      • cat mitm.sh

      • Генерируем свой ключ и сертификат ArootCA.crt

        • (нажмите «Комментарии» в шапке страницы, чтобы прочитать спойлер) CN=адрес_сервера, а не router!

      • Генерируем и подписываем сертификат для сервиса подмены.

      • ls

      • Запускаем в фоне socat, который отдаёт ArootCA.crt по сети на порту R без шифрования

      • Запускаем в фоне socat, который принимает подключения по SSL с ключом, подписанным ArootCA.crt, а в качестве обработчика запускает mitm.sh

      • Запускаем nftables

      • nft list table ip mitm

   4. На client (продолжение)

      • Переименовываем rootCA.crt в OldrootCA.crt

      • Получаем rootCA.crt с сервера, порт R (это окажется ArootCA.crt)

      • diff -sq rootCA.crt OldrootCA.crt

      • Получаем ArootCA.crt с маршрутизатора, порт R

      • diff -sq rootCA.crt ArootCA.crt

      • Получаем дату с сервера, порт S (с проверкой сертификата)

        • Убеждаемся, что год теперь 1337 (начало Столетней войны между Англией и Францией)

4. Три отчёта (названия сохранить, должно быть: report.12.srv, report.12.router, eport.12.client) переслать одним письмом в качестве приложений на uneexlectures@cs.msu.ru

   • В теме письма должно встречаться слово LinuxNetwork2026