Один сценарий интернет-измерений и поле 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/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 4

  • 1. 30th April 2023, 10:38 // Читатель void написал:

    а можно же wildcard сертификат *.example.net использовать

  • 2. 30th April 2023, 11:21 // Александр Венедюхин:

    Это хорошее замечание, спасибо. Как раз про wildcard я забыл уточнить. В соответствующей задаче такой сертификат не подходит. Прежде всего потому, что тут требуется использовать имена с несколькими уровнями вложенности – *.*.example.net, как минимум. Соответственно, wildcard-имя *.example.net тут не подходит (работает только на одном уровне подстановки), а *.*.example.com – и не выпустят, и работать всё равно не будет по другим причинам.

  • 3. 1st May 2023, 15:10 // Читатель void написал:

    а почему кодируюшее имя непременно должно содержать точку и порождать субдомен?
    можно же любые уровни закодировать в base36, заполнения ‘=’ заменить на ‘-‘, и получится валидное dns имя
    извиняюсь за настойчивость и непонятливость

  • 4. 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, которая мне показалась достаточно оригинальной.

Написать комментарий

Ваш комментарий:

Введите ключевое слово "6843W" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.