Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Полностью зашифрованные протоколы в Интернете
В качестве развития технологии ESNI, которая так и не вышла из статуса черновика (draft), сейчас разрабатывается вариант с передачей полного дополнительного сообщения ClientHello, но в зашифрованном виде. Предлагаемая сейчас схема выглядит чрезмерно сложной, в основном, из-за того, что логические составляющие вложены одна в другую, при этом есть ссылки из внутреннего сообщения на элементы внешнего. Вряд ли это удастся реализовать без множества ошибок, порождающих уязвимости. Тем не менее, само направление интересное. Вообще, в теории, большинство прикладных протоколов современной Сети можно сделать полностью зашифрованными, включая этап установления соединения. Конечно, на практике такое если и возможно, то не скоро, однако можно рассмотреть гипотетическую картину, которая возникнет, если схему всё же воплотить. Сейчас, в TLS 1.3, зашифрованы не все сообщения, но, если сравнить с предыдущими версиями, то на защищённый обмен стороны переходят гораздо раньше. Например, в случае развития TLS в выбранном направлении, первое же сообщение клиента будет передаваться полностью в зашифрованном виде.
Возникает традиционная проблема: где клиенту взять ключи? Ключи для такой схемы публикуются в DNS. При этом, использование DNSSEC – позволяет защитить данные от подмены, а доставка запросов и ответов DNS через TLS – защищает от прослушивания трафика.
То есть, опять же, на примере TLS, – клиент извлекает серверные криптографические параметры для установления соединения из DNS, генерирует нужные ключи и зашифровывает первое же сообщение, которое направляет серверу. Это сообщение может вообще не содержать фиксированных заголовков в открытом виде (кроме, понятно, относящихся к TCP/IP или UDP). Третья сторона видит только факт обмена узлов псевдослучайными данными. Более того, даже на уровне DNS – тоже видны только псевдослучайные данные, поскольку обмен защищён TLS, в том числе, на пути между рекурсивным резолвером и авторитативным сервером.
Основных проблем у такой схемы, если она внедрена повсеместно, несколько. Во-первых, сервер должен принимать и пытаться расшифровать любые входящие пакеты. Это очень затратно в вычислительном плане. Конечно, криптография сейчас довольно быстрая, но нагрузки всё равно возрастут в тысячи раз (и более). Нужно учитывать, что быстрые решения по фильтрации пакетов на уровне протоколов, доступные сейчас и работающие с данными в открытом виде, работать перестанут: для фильтрации в таком режиме окажутся доступны только параметры уровня номера порта и IP-адреса (ну, ещё ряд параметров TCP), а для обработки протоколов – придётся выгружать ключи на узлы балансировки и фильтрации. (Это можно сделать, но потребует очень больших затрат; которым, впрочем, наверняка будут рады крупнейшие производители сетевого оборудования.)
Во-вторых, каждому клиенту нужна будет некоторая точка старта – источник актуальных ключей, необходимых для того, чтобы сделать первый защищённый запрос. В принципе, эта проблема попроще: ключи могут быть встроены в дистрибутив, а для проверки целостности дистрибутива – годится уже имеющаяся сейчас инфраструктура.
В-третьих, полностью исчезнут современные возможности по приоритизации разных типов трафика силами DPI: никаких сигнатур отдельных протоколов не останется, кроме самых базовых – номеров портов и IP-адресов (ну, ещё количество потоков можно как-то измерить).
Кроме того, гораздо сложнее станет отлаживать работу сетевого ПО и обнаруживать ошибки, поскольку типы прикладного трафика полностью потеряют “различимость”. Недоступным окажется пассивное блокирование ресурсов на уровне протокола (опять же, с использованием DPI).
И тем не менее, переход на такой уровень – вполне возможен в ближайшие годы.
Адрес записки: https://dxdt.ru/2020/06/25/8907/
Похожие записки:
- Теги ключей DNSSEC: продолжение
- Chrome и УЦ Entrust
- Twitter за стеной регистрации
- Реплика: перенос доменных имён и GoDaddy
- ML-KEM на тестовом сервере TLS
- Техническое: занимательный пример из практики DNS в Интернете
- Трижды Spectre в процессорах
- Open Source и добавление "вредоносного кода"
- Австралийские постквантовые криптографические рекомендации
- Падения Facebook.com
- Обновление темы dxdt.ru
Комментарии читателей блога: 4
1 <t> // 25th June 2020, 16:17 // Читатель dmt-obds написал:
А чем мотивируются предложения шифровать ClientHello? Соразмерна ли выгода от внедрения подобной технологии затратам на ее внедрение?
2 <t> // 25th June 2020, 20:51 // Александр Венедюхин:
Мотивируется так же, как и ESNI: предотвращение утечки имени ресурса, с которым устанавливается соединение (это имя утекает через поле SNI, которое передаётся в открытом виде). Насчёт выгоды – тут сложнее, пока что не очень понятно. То есть, с одной стороны, крупные провайдеры и браузеры получают ещё одну “услугу безопасности”, которую могут предложить пользователям, с другой стороны – не ясно, когда и как оно всё будет реализовано.
3 <t> // 25th June 2020, 21:58 // Читатель beldmit написал:
Собственно, быстро или медленно – зависит от того, нужны ли асимметричные операции в процессе. Но как без них обойтись, я не представляю.
4 <t> // 25th June 2020, 22:02 // Читатель beldmit написал:
Кстати, на кривой 25519 на не самой быстрой машине получается порядка 10000 операций в секунду на ядро, так что тоже недорого…
Написать комментарий