Один сценарий интернет-измерений и поле SNI HTTPS/TLS
Предположим, что некоторые интернет-измерения, проводимые с использованием веба, полностью основаны на уникальном имени хоста, которое генерируется под каждый запрос. Это очень удобный способ создания информативного маркера, переходящего между протоколами. Имя нетрудно встроить, например, в адрес источника файла изображения, ссылка на которое входит в состав кода веб-страницы. Почему подходит именно имя хоста? Потому что оно же будет использоваться клиентом и в DNS, и в HTTP. А вот часть URL, соответствующая адресу документа, уже в DNS не ходит. Другими словами: используем в браузере (условный) URL https://123dio.cba.example.net/an-img.gif, где полезные данные кодируются в части 123dio.cba. Строка 123dio.cba.example.net отправится и в DNS, где будет узнана специальным сервером, и в HTTP, а вот an-img.gif – в DNS не попадёт, а поступит только на веб-сервер, отвечающий под 123dio.cba.example.net. Соответственно, насыщение HTTP-запросов полезной информацией, которую мы хотим видеть и в DNS, должно происходить через имена хостов.
Однако возникает неприятная проблема с HTTPS: дело в том, что для установления соединения с браузером сервер под “странным” именем 123dio.cba.example.net должен предъявить TLS-сертификат, валидный для этого имени, но имя-то каждый раз разное, поэтому сертификатов не напасёшься (если их выпускать через тот или иной УЦ, признаваемый браузерами). Использование открытого HTTP тут не рассматриваем – такие условия: хотя бы потому, что страница-носитель загружается по HTTPS. Что можно сделать? А можно, например, совсем отказаться от установления TLS-соединения на стороне сервера и при этом не потерять полезных данных. Нам не требуется реально обрабатывать HTTP-запрос и возвращать файл изображения, нам нужно только зафиксировать на сервере имя хоста, а это имя в HTTPS/TLS передаётся клиентом в начальном сообщении, да ещё и в открытом виде (это как раз и есть SNI TLS). Так что серверный сертификат тут просто не нужен: сервер записывает имя хоста из SNI и – прерывает соединение с тем или иным кодом ошибки TLS.
(Дополнение – 30/04/2023: в комментариях справедливо указывают на wildcard-сертификат для имён вида *.example.net. Однако тут такой сертификат не сработает, поскольку для DNS-части измерений важны кодирующие имена минимум в двух уровнях, то есть, *.*.example.com, а wildcard-сертификат закрывает только один уровень. Несколько уровней – входят в качестве требования в изначальную задачу, оставшуюся здесь за скобками.)
Адрес записки: https://dxdt.ru/2023/04/29/9951/
Похожие записки:
- Форматы записи TLS-сертификатов
- Квантовая криптография и металлический контейнер
- Удаление аккаунтов GoDaddy
- Шумерские цифры и хитрости Unicode
- Бывшая "Яндекс.Почта"
- Предсказание погоды от Google AI
- Реплика: особенности DNSSEC
- "Случайные пакеты" как транспорт
- DNSSEC и DoS-атаки
- Реплика: интернет-названия
- Детектирование видеофрагментов, сгенерированных ИИ
Кратко этот сайт характеризуется так: здесь можно узнать про технологический прогресс, Интернет, математику, криптографию, авиацию, компьютеры, авиационные компьютеры, вооружения, роботов, вооружение роботов, армии мира, астрономию, космические исследования. И иногда о чём-то ещё (
Комментарии читателей блога: 4
1 <t> // 30th April 2023, 10:38 // Читатель void написал:
а можно же wildcard сертификат *.example.net использовать
2 <t> // 30th April 2023, 11:21 // Александр Венедюхин:
Это хорошее замечание, спасибо. Как раз про wildcard я забыл уточнить. В соответствующей задаче такой сертификат не подходит. Прежде всего потому, что тут требуется использовать имена с несколькими уровнями вложенности – *.*.example.net, как минимум. Соответственно, wildcard-имя *.example.net тут не подходит (работает только на одном уровне подстановки), а *.*.example.com – и не выпустят, и работать всё равно не будет по другим причинам.
3 <t> // 1st May 2023, 15:10 // Читатель void написал:
а почему кодируюшее имя непременно должно содержать точку и порождать субдомен?
можно же любые уровни закодировать в base36, заполнения ‘=’ заменить на ‘-‘, и получится валидное dns имя
извиняюсь за настойчивость и непонятливость
4 <t> // 1st May 2023, 16:04 // Александр Венедюхин:
Всё верно. Но в этом конкретном случае есть несколько дополнительных хитростей. Порождение поддоменов вызвано измерительной DNS-частью. Два уровня (минимум) тут нужны для того, чтобы получить “каскад” запросов в DNS – то есть, чтобы был делегирующий ответ и разные наборы серверов имён, при этом разделение по зонам должно быть корректным. Поэтому приходится делить точкой. Другими словами: нужно, чтобы DNS-резолвер сперва сделал запрос на контролируемый авторитативный сервер (NS) одной зоны (cba.example.net, например) и получил _логичный_ ответ, что про 123dio.cba.example.net нужно спросить другие NS-ы (имена этих “других NS-ов” – тоже генерируются особым образом, ну и нужен корректный, что называется, zone cut), а уже эти NS-ы вернут A-запись и зафиксируют запросы, в том числе, с собственными именами и с искомым именем хоста, ещё и время померят (заметьте, что имена NS нужно будет резолвить, соответственно, резолвер ещё несколько раз к нам придёт). Я вообще сперва хотел всё это описать в исходной заметке, но решил, что как-то очень много, оставил только часть про SNI в TLS, которая мне показалась достаточно оригинальной.
Написать комментарий