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

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

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

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

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

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

0. «Просто» протоколы: 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):

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

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

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

См. LecturesCMC/LinuxApplicationDevelopment2021/00_GitSsh

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

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

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

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

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

  • Однако Encrypted Client Hello

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

  • https://letsencrypt.org

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

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

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

• Можно добавить собственный ключ в список доверенных

Пример для 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, как в сертификате, поверка не пройдёт!

Д/З

TODO в идеале — сделать ssh-mitm (если это просто), если нет — повторить последний раздел лекции