Как скрыть свои запросы от провайдера с помощью этой штуки?
Достаточно указать внешний, относительно провайдера, рекурсивный резолвер, включить для этого резолвера DoH и убедиться, что защищаемые DNS-запросы действительно ходят через DoH на этот резолвер. Если прошивка роутера позволяет, то можно настроить на роутере локальный резолвер в качестве "форвардера", указав в качестве вышестоящего рекурсивный резолвер с DoH или DoT и выбрав один из этих протоколов для доступа. Соответственно, на всех устройствах в LAN тогда нужно настроить в качестве DNS-сервера IP-адрес роутера (или роутерного резолвера). Это настраивается через DHCP или вручную на устроствах (в настройках DNS). Тогда локальная работа с DNS будет в открытом виде, но за пределы LAN DNS-трафик будет ходить через DoH/DoT, которые настроены на роутере для "форвардера". То есть, устройства в локальной сети используют в качестве резолвера роутер, а внутри роутера запросы оборачиваются в DoH/DoT (на этот момент нужно обратить внимание) и передаются на внешний, относительно провайдера, рекурсивный резолвер в защищённом виде.
Почему указание резолвера на роутере не даёт эффекта?
Точно сказать сложно, зависит от сетевой конфигурации. Скорее всего, потому, что устройства обращаются к внешнему DNS-резолверу напрямую, без всяких DoH/DoT, например, получив такой адрес резолвера по DHCP. Кроме того, сам по себе адрес - не говорит о том, по какому протоколу нужно подключаться. Если по умолчанию, то всё будет ходить в открытом виде, даже если указать IP-адрес сервиса резолвера, который, потенциально, поддерживает тот же DoH. То есть, нужно не только настроить защищённый DNS-доступ на DNS-подключении роутера, но ещё и устройствам в локальной сети рассказать, что нужно использовать именно защищённую точку входа для DNS, особенно, если эти устройства не поддерживают DoH/DoT (см. про "форвардер" выше).
Преимущество DNSSEC как раз в том, что администратор DNS-зоны подписывает конкретные сведения в этой зоне. Администратор является первоисточником сведений о настройках зоны, так или иначе. Поэтому, если мы принимаем, что подпись работает и подписывающие ключи сохраняются администратором в секрете, то для стороны, валидирующей DNS-записи, вообще становится без разницы, откуда и как эти записи были получены - главное, чтобы сходились подписи и все ключи в цепочке были доверенными. То есть, DNSSEC как раз делает DNS-данные независимыми от транспорта. Конечно, это не защищает от того, что записи всё же кто-то испортит на транзите, но подменить содержание, скрыв факт подмены, не получится, так что порчу можно будет обнаружить.
и никак не может помешать отправке любой белиберды
Это так. Администратор волен написать в DNS-зоне что угодно, в том числе, может корректно подписать "кривые" записи или наделать "кривых" ключей, может ещё что-то сломать под своими именами, подтвердив все поломки DNSSEC-записями. Однако в случае, когда DNSSEC нет, всё это может проделать не только администратор, которому по статусу положено, но и всякий транзитный узел.
А главный недостаток DNSSEC в том, что это слишком хрупкая, по нынешним временам, технология, требующая, к тому же, специальных знаний и понимания принципов работы для поддержки уже настроенных процессов. И когда хрупкость DNSSEC даёт о себе знать, тогда отламываются сразу целые национальные зоны.
Атаковать валидатор УЦ необязательно. Чтобы клиент мог поверить подписи в сертификате - этот клиент должен верить в ключи УЦ, которым сертификат выпущен. Соответственно, ключи откуда-то нужно взять. Если же у клиента таких доверенных ключей нет и в сертификате подпись он проверяет просто, "чтобы сходилось", то перехватывающий узел может выпустить и подписать свой сертификат, который будет предназанчен именно для конкретной сессии (это нетрудно - сертификат выпускается за какие-то десятки миллисекунд).
Если клиент дополнительно сверяет имя в сертификате с именем, которое заранее известно клиенту, то перехватывающему узлу нужно подходящее имя вписать в подставной сертификат, а для этого имя нужно как-то выяснить. Это не всегда просто сделать: то есть, можно ожидать, что какое-то имя есть в поле SNI начального сообщения TLS, но, во-первых, для DoT тут есть оговорки; во-вторых, придётся парсить TLS-сессию и сообщения. Для IP-адреса - всё проще: он заранее известен, так что и сертификат можно заранее заготовить.
В отличии от корневых DNS, маршруты до которых хорошо защищены
У корневых DNS-серверов очень много локальных узлов, которые расставлены по разным местам Интернета. Какие-то исключительные особо эффективные методы защиты для маршрутов там не применяются, да их и не получится применять для всех локальных узлов. Всё в общем порядке. Да, собственно, BGP везде примерно одинаково "защищён" сейчас.
Но тут важно другое: с точки зрения обычного клиентского подключения (а не межсетевого взаимодействия на уровне AS), в IP-сетях всякий промежуточный узел может ответить вместо "оконечного", соответственно, для активной атаки лишь нужно "встать в разрыв"; ну и вот разные "угоны маршрутов" - лишь служат для того, чтобы петлёй закинуть к себе "хопы", которые в штатном режиме - "чужие" (то есть, должны были бы быть в других сетях). С DNS тут даже хуже, потому что распространённый доступ тут по UDP. Так что для защиты протоколов, работающих выше IP, в принципе нужны какие-то дополнительные меры, типа проверки ключей/подписей.
Можно пытаться распределять сертификаты сверху вниз через механизм похожий
Или просто использовать отпечатки ключей. Или, например, проверять отпечатки ключей и цепочки с валидацией DNSSEC. А исключительно TLS-cертификаты, да ещё и с привычной иерархией, для DoT вообще не очень подходят, на мой взгляд.
Чисто технически - ничто не мешает: вписать IP-адрес в сертификат несложно, это предусмотрено форматом. Но, если говорить про имеющиеся "хорошо известные УЦ", то сертификаты для IP-адресов выпускают неохотно, так как есть трудности с надёжной проверкой права управления адресом, а также с сопровождением. Впрочем, Let's Encrypt вот обещают для всех в этом году сделать автоматические короткоживущие TLS-сертификаты на IP-адреса. Поскольку там есть механизм подтверждения чисто по TLS, то можно будет в прозрачном режиме привестить ACME-проверку к DoT, не поднимая ненужного веб-сервера.
Однако, если про использование УЦ, то есть другие особенности. Проверка соответствия IP-адресов потребует ввести доверие инфраструктуре УЦ ещё и для DNS, что создаст очень нехорошую зависимость от работы и политик этих УЦ; а DNS, всё же, фундамент Интернета. Если же доверие УЦ не предусматривать, то, при активной атаке, подменить сертификат, выпущенный для IP-адреса, даже проще, чем сертификат для DNS-имён: имена нужно как-то узнать для конкретной сессии, до подмены, а IP-адрес сервера - заранее известен.
Только тут получилось, что в итоговую формулу π входит и в правую часть тоже, в составе L и т.д. Поэтому нужно что-то с буквами сделать, а то π используется для вычисления π.
С одной стороны, утверждение про "100% кода через год" - рискованное: кто-то из выживших человеков может же из принципа продолжать кодить без ИИ - либо чтобы не было 100%, либо по причине отсутствия доступа к интернетам. С другой стороны, сделать вот 99.9% ИИ-кода - не так уж и сложно: пусть этот ИИ генерит больше и больше кода, тогда доля будет расти. Вот, скажем, в "параллельной ветке" этого интеллектуального развлечения прямо утверждается, что искусственный суперинтеллект "будет писать триллионы строк кода", который код "человек не сможет понять, даже если ИИ будет годами его объяснять". Что там нагенерировано - не понятно, но зато непонятно на 100% (почти).
Программирую "микро-микроконтроллеры" на ассемблере, для "толстых" микроконтроллеров - вполне подходит C. Многое зависит от компилятора, у Rust тут, с точки зрения компиляции (не производительности), конечно, есть существенные преимущества, но, в общем случае - компилятор "не видит" алгоритма, и для микроконтроллеров (которые "микро") этот эффект максимален. Есть неплохой пример с "обратным разворачиванием" циклов: https://dxdt.ru/2024/07/29/13493/
Тут речь вот о чём: сломав RSA, конечно, можно извлечь ключи, можно подделать подписи сервера; однако на уже случившуюся двадцать лет назад успешную аутентификацию TLS-сервера клиентом это же не повлияет - завершившаяся аутентификация не перестанет быть успешной, если таковой была.
Любопытно взглянуть на сравнение производительности
По браузерам сказать сложно, нужно измерять. Но ML-KEM, благодаря NTT-умножению, быстрый. В примере из реализации OQS (выше) ML-KEM существенно быстрее X25519, соответственно, падение производительности будет небольшим, так или иначе (даже если учитывать прирост размера ключей).
Предполагается, что число 21 "вводят" путём создания сложной (даже для такого небольшого числа) "квантовой схемы", которая, теоретически, должна физически реализовать заданную функцию (некоторую экспоненту, в случае факторизации). Как именно реализовать, какие должны быть "физические элементы", сколько их нужно (потому что "помехи") - тут, так сказать, мнения расходятся. Поэтому чёткого, конкретного ответа, что называется, "на проводах", пока и нет. Как нет ответа и относительно физической реализации квантового преобразования Фурье, тем более, для большого количества разрядов (кубитов). Популярные статьи обычно строятся вокруг подсчёта "количества кубитов" и "суперпозиции", а не вокруг обсуждения методов задания состояний (например).
Что касается разрядности, предположим, порядка 2^300, то тут непонятно, в какой момент и по какой шкале должен наступать переход от "квантового" к "классическому". То есть, в книжках нередко пишут, что "с ростом количества частиц начинается статистика и классическая физика". Однако, когда именно это начинается в случае гипотетического квантового компьютера? Как измерять порог: по количеству ли кубитов, по количеству ли состояний, должен ли наступать означенный переход вообще - мнения, опять же, разнятся, и среди физиков, и среди философов. Конкретно к реализации алгоритма Шора это имееет, кроме прочего, и такое отношение, что ошибки в представлении результата преобразования Фурье, вообще-то, тоже могут "квантоваться", а это, предположим, не позволит факторизовать большие полупростые числа в принципе (почему аксиома непрерывности должна прямо транслироваться в физику измерительного оборудования?).
Достаточно указать внешний, относительно провайдера, рекурсивный резолвер, включить для этого резолвера DoH и убедиться, что защищаемые DNS-запросы действительно ходят через DoH на этот резолвер. Если прошивка роутера позволяет, то можно настроить на роутере локальный резолвер в качестве "форвардера", указав в качестве вышестоящего рекурсивный резолвер с DoH или DoT и выбрав один из этих протоколов для доступа. Соответственно, на всех устройствах в LAN тогда нужно настроить в качестве DNS-сервера IP-адрес роутера (или роутерного резолвера). Это настраивается через DHCP или вручную на устроствах (в настройках DNS). Тогда локальная работа с DNS будет в открытом виде, но за пределы LAN DNS-трафик будет ходить через DoH/DoT, которые настроены на роутере для "форвардера". То есть, устройства в локальной сети используют в качестве резолвера роутер, а внутри роутера запросы оборачиваются в DoH/DoT (на этот момент нужно обратить внимание) и передаются на внешний, относительно провайдера, рекурсивный резолвер в защищённом виде.
Точно сказать сложно, зависит от сетевой конфигурации. Скорее всего, потому, что устройства обращаются к внешнему DNS-резолверу напрямую, без всяких DoH/DoT, например, получив такой адрес резолвера по DHCP. Кроме того, сам по себе адрес - не говорит о том, по какому протоколу нужно подключаться. Если по умолчанию, то всё будет ходить в открытом виде, даже если указать IP-адрес сервиса резолвера, который, потенциально, поддерживает тот же DoH. То есть, нужно не только настроить защищённый DNS-доступ на DNS-подключении роутера, но ещё и устройствам в локальной сети рассказать, что нужно использовать именно защищённую точку входа для DNS, особенно, если эти устройства не поддерживают DoH/DoT (см. про "форвардер" выше).
Преимущество DNSSEC как раз в том, что администратор DNS-зоны подписывает конкретные сведения в этой зоне. Администратор является первоисточником сведений о настройках зоны, так или иначе. Поэтому, если мы принимаем, что подпись работает и подписывающие ключи сохраняются администратором в секрете, то для стороны, валидирующей DNS-записи, вообще становится без разницы, откуда и как эти записи были получены - главное, чтобы сходились подписи и все ключи в цепочке были доверенными. То есть, DNSSEC как раз делает DNS-данные независимыми от транспорта. Конечно, это не защищает от того, что записи всё же кто-то испортит на транзите, но подменить содержание, скрыв факт подмены, не получится, так что порчу можно будет обнаружить.
Это так. Администратор волен написать в DNS-зоне что угодно, в том числе, может корректно подписать "кривые" записи или наделать "кривых" ключей, может ещё что-то сломать под своими именами, подтвердив все поломки DNSSEC-записями. Однако в случае, когда DNSSEC нет, всё это может проделать не только администратор, которому по статусу положено, но и всякий транзитный узел.
А главный недостаток DNSSEC в том, что это слишком хрупкая, по нынешним временам, технология, требующая, к тому же, специальных знаний и понимания принципов работы для поддержки уже настроенных процессов. И когда хрупкость DNSSEC даёт о себе знать, тогда отламываются сразу целые национальные зоны.
Атаковать валидатор УЦ необязательно. Чтобы клиент мог поверить подписи в сертификате - этот клиент должен верить в ключи УЦ, которым сертификат выпущен. Соответственно, ключи откуда-то нужно взять. Если же у клиента таких доверенных ключей нет и в сертификате подпись он проверяет просто, "чтобы сходилось", то перехватывающий узел может выпустить и подписать свой сертификат, который будет предназанчен именно для конкретной сессии (это нетрудно - сертификат выпускается за какие-то десятки миллисекунд).
Если клиент дополнительно сверяет имя в сертификате с именем, которое заранее известно клиенту, то перехватывающему узлу нужно подходящее имя вписать в подставной сертификат, а для этого имя нужно как-то выяснить. Это не всегда просто сделать: то есть, можно ожидать, что какое-то имя есть в поле SNI начального сообщения TLS, но, во-первых, для DoT тут есть оговорки; во-вторых, придётся парсить TLS-сессию и сообщения. Для IP-адреса - всё проще: он заранее известен, так что и сертификат можно заранее заготовить.
У корневых DNS-серверов очень много локальных узлов, которые расставлены по разным местам Интернета. Какие-то исключительные особо эффективные методы защиты для маршрутов там не применяются, да их и не получится применять для всех локальных узлов. Всё в общем порядке. Да, собственно, BGP везде примерно одинаково "защищён" сейчас.
Но тут важно другое: с точки зрения обычного клиентского подключения (а не межсетевого взаимодействия на уровне AS), в IP-сетях всякий промежуточный узел может ответить вместо "оконечного", соответственно, для активной атаки лишь нужно "встать в разрыв"; ну и вот разные "угоны маршрутов" - лишь служат для того, чтобы петлёй закинуть к себе "хопы", которые в штатном режиме - "чужие" (то есть, должны были бы быть в других сетях). С DNS тут даже хуже, потому что распространённый доступ тут по UDP. Так что для защиты протоколов, работающих выше IP, в принципе нужны какие-то дополнительные меры, типа проверки ключей/подписей.
Или просто использовать отпечатки ключей. Или, например, проверять отпечатки ключей и цепочки с валидацией DNSSEC. А исключительно TLS-cертификаты, да ещё и с привычной иерархией, для DoT вообще не очень подходят, на мой взгляд.
Чисто технически - ничто не мешает: вписать IP-адрес в сертификат несложно, это предусмотрено форматом. Но, если говорить про имеющиеся "хорошо известные УЦ", то сертификаты для IP-адресов выпускают неохотно, так как есть трудности с надёжной проверкой права управления адресом, а также с сопровождением. Впрочем, Let's Encrypt вот обещают для всех в этом году сделать автоматические короткоживущие TLS-сертификаты на IP-адреса. Поскольку там есть механизм подтверждения чисто по TLS, то можно будет в прозрачном режиме привестить ACME-проверку к DoT, не поднимая ненужного веб-сервера.
Однако, если про использование УЦ, то есть другие особенности. Проверка соответствия IP-адресов потребует ввести доверие инфраструктуре УЦ ещё и для DNS, что создаст очень нехорошую зависимость от работы и политик этих УЦ; а DNS, всё же, фундамент Интернета. Если же доверие УЦ не предусматривать, то, при активной атаке, подменить сертификат, выпущенный для IP-адреса, даже проще, чем сертификат для DNS-имён: имена нужно как-то узнать для конкретной сессии, до подмены, а IP-адрес сервера - заранее известен.
Поправил. Спасибо.
Только тут получилось, что в итоговую формулу π входит и в правую часть тоже, в составе L и т.д. Поэтому нужно что-то с буквами сделать, а то π используется для вычисления π.
С одной стороны, утверждение про "100% кода через год" - рискованное: кто-то из выживших человеков может же из принципа продолжать кодить без ИИ - либо чтобы не было 100%, либо по причине отсутствия доступа к интернетам. С другой стороны, сделать вот 99.9% ИИ-кода - не так уж и сложно: пусть этот ИИ генерит больше и больше кода, тогда доля будет расти. Вот, скажем, в "параллельной ветке" этого интеллектуального развлечения прямо утверждается, что искусственный суперинтеллект "будет писать триллионы строк кода", который код "человек не сможет понять, даже если ИИ будет годами его объяснять". Что там нагенерировано - не понятно, но зато непонятно на 100% (почти).
Программирую "микро-микроконтроллеры" на ассемблере, для "толстых" микроконтроллеров - вполне подходит C. Многое зависит от компилятора, у Rust тут, с точки зрения компиляции (не производительности), конечно, есть существенные преимущества, но, в общем случае - компилятор "не видит" алгоритма, и для микроконтроллеров (которые "микро") этот эффект максимален. Есть неплохой пример с "обратным разворачиванием" циклов: https://dxdt.ru/2024/07/29/13493/
Записанный трафик вполне можно будет прочитать, да.
Тут речь вот о чём: сломав RSA, конечно, можно извлечь ключи, можно подделать подписи сервера; однако на уже случившуюся двадцать лет назад успешную аутентификацию TLS-сервера клиентом это же не повлияет - завершившаяся аутентификация не перестанет быть успешной, если таковой была.
По браузерам сказать сложно, нужно измерять. Но ML-KEM, благодаря NTT-умножению, быстрый. В примере из реализации OQS (выше) ML-KEM существенно быстрее X25519, соответственно, падение производительности будет небольшим, так или иначе (даже если учитывать прирост размера ключей).
Предполагается, что число 21 "вводят" путём создания сложной (даже для такого небольшого числа) "квантовой схемы", которая, теоретически, должна физически реализовать заданную функцию (некоторую экспоненту, в случае факторизации). Как именно реализовать, какие должны быть "физические элементы", сколько их нужно (потому что "помехи") - тут, так сказать, мнения расходятся. Поэтому чёткого, конкретного ответа, что называется, "на проводах", пока и нет. Как нет ответа и относительно физической реализации квантового преобразования Фурье, тем более, для большого количества разрядов (кубитов). Популярные статьи обычно строятся вокруг подсчёта "количества кубитов" и "суперпозиции", а не вокруг обсуждения методов задания состояний (например).
Что касается разрядности, предположим, порядка 2^300, то тут непонятно, в какой момент и по какой шкале должен наступать переход от "квантового" к "классическому". То есть, в книжках нередко пишут, что "с ростом количества частиц начинается статистика и классическая физика". Однако, когда именно это начинается в случае гипотетического квантового компьютера? Как измерять порог: по количеству ли кубитов, по количеству ли состояний, должен ли наступать означенный переход вообще - мнения, опять же, разнятся, и среди физиков, и среди философов. Конкретно к реализации алгоритма Шора это имееет, кроме прочего, и такое отношение, что ошибки в представлении результата преобразования Фурье, вообще-то, тоже могут "квантоваться", а это, предположим, не позволит факторизовать большие полупростые числа в принципе (почему аксиома непрерывности должна прямо транслироваться в физику измерительного оборудования?).