![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
waqurС июня 2018 года в браузере Mozilla Firefox существует возможность включить шифрование DNS-запросов, т.е. резолвинг доменных имён по протоколу https (DNS-over-HTTPS, DoH). Для этого нужно задать network.trr.mode=2 в about:config.
Эту фичу уже включили вручную (opt-in) 70 тысяч юзеров, у них всё работает нормально, поэтому в ближайшее время Mozilla планирует включить эту фичу по умолчанию, сначала для пользователей из США, а затем для всего мира, не считая Британии.
DoH-резолвинг доменных имён по умолчанию идёт через CloudFlare, что вызвало критику и оправдания со стороны Mozilla.
Учитывая этот опыт, компания Google, которая тоже планирует внедрить DoH в своём браузере, решила реализовать поддержку нескольких DoH-провайдеров (нужный будет выбираться автоматически, в зависимости от IP-адреса классического DNS-резолвера, который сейчас задан в системных настройках или был получен через DHCP; таким образом, насколько это возможно, DNS-провайдер не изменится, только добавится шифрование). Впрочем, у всех этих компаний privacy policy не лучше, чем у CloudFlare.
Крупным интернет-провайдерам затея с DoH не нравится, т.к. они теряют возможность составлять списки посещаемых пользователями сайтов, и далее продавать эти данные маркетинговым агентствам и другим заинтересованным лицам. Так, например, американский провайдер Comcast недавно активизировал своих лоббистов в Конгрессе с целью противодействия усилиям компаний Mozilla и Google по внедрению в их браузеры функции DoH-клиента.
Владельцы роутеров с прошивкой на основе OpenWRT уже сейчас могут установить прокси-сервер DNS-to-DoH, который будет обрабатывать DNS-запросы на LAN-интерфейсе и делать DoH-запросы через WAN-интерфейс. Таким образом, можно уже сейчас добавить DoH для всех legacy-устройств в локальной сети, выполняющихся на них программ и операционных систем.
В популярный блокировщик рекламы PiHole тоже недавно была добавлена поддержка DoH на бэкэнде. Кстати, чтобы PiHole и ей подобные могли по-прежнему видеть DNS-запросы на фронтэнде, даже после перехода на DoH по умолчанию, в Firefox добавлен workaround: так называемый canary domain "use-application-dns.net", при возврате ответа NXDOMAIN на который происходит отключение браузерного DoH-клиента (хотя Mozilla обещает это убрать, если заметит злоупотребления со стороны интернет-провайдеров). Google Chrome не планирует делать поддержку этого или любого другого canary domain, т.к. PiHole и прочие блокировщики рекламы вредят основному бизнесу корпорации.
А ещё недавно поддержка DoH была добавлена в curl, популярную библиотеку и консольный HTTP-клиент.
Почему победил DoH, а не DoT? Потому что враждебно настроенным провайдерам тривиально просто фильтровать исходящий трафик на 853-й TCP-порт.
Но провайдеры могут так же тривиально просто фильтровать IP-адреса 1.1.1.1 и 1.0.0.1? Могут, но компании CloudFlare технически ничего не мешает включить DoH-резолвер на всех своих IP-адресах.
А как же DNSSEC? Подписи в DNS-ответах прекрасны, но их наличие никак не мешает провайдеру по-прежнему подглядывать за пользователями (вести логи DNS-запросов и DNS-ответов); а когда провайдеру понадобится что-то заспуфить, он может запросто начать блокировать DNSSEC и тем самым форсировать downgrade клиентов на обычный нешифрованный DNS. На принцип Net Neutrality многие провайдеры давно забили, а вот https они уже не смогут, просто так, взять и отключить (слишком поздно, на него приходится 90% трафика), поэтому инкапсуляция DNS-трафика в https — как раз то, что нужно.
Но доменные имена посещаемых сайтов провайдеры по-прежнему могут извлекать из поля SNI, которое передаётся открытым текстом в начале любой https-сессии? Могут, но DPI-оборудование для stateful-анализа https встречается реже и стоит дороже, чем оборудование для простого анализа UDP-трафика на 53-м порту, а стандарт eSNI, предусматривающий шифрование этого поля, уже на подходе. В Firefox'е уже сейчас можно включить экспериментальную поддержку eSNI. Поле eSNI на клиентской стороне шифруется ключами, получаемыми через DNS, поэтому фича eSNI зависит от фичи DoH (во избежание MitM-атак на эти ключи, их подмены путём перехвата DNS на стороне провайдера). В компании Google пока думают: они хотят передавать ключ для eSNI-шифрования не через TXT-запись для поддомена "_esni", а через ESNI-запись (запись нового типа) в апексе, т.е. для всего домена. Из-за разногласий вокруг этих технических деталей между Google и Mozilla/CloudFlare стандартизация eSNI в IETF пока притормозилась, а вместе с ней и реализация поддержки eSNI в SSL-библиотеках и HTTP-серверах. Скорее всего, владельцам доменов первое время нужно будет делать и TXT-запись в _esni-поддомене, и ESNI-запись в апексе.
Как может быть решена "проблема курицы и яйца" для поля eSNI в https-сессиях к DoH-резолверам? ESNI-ключи для DoH-резолверов станут ещё одной квази-константой интернета, так же как IP-адреса DoH-резолверов, IP-адреса корневых DNS-серверов или TLS Trusted Root.
После массового внедрения eSNI и DoH, провайдеры смогут по-прежнему осуществлять фильтрацию сайтов по IP-адресам? Смогут, но со стороны крупных облачных сервисов, таких как CloudFlare, AWS, GCP, Azure и Akamai может последовать ответ в виде domain fronting.
А что, если особо упоротые провайдеры начнут блокировать полные блоки IP-адресов облачных сервисов? Об этом ещё рано думать, но недавно в Нумерационном Совете NRO RIR обсуждалась идея отозвать ранее распределённые номера автономных систем (AS) у крупных российских провайдеров (по причине нарушения связности интернета). Пока эту идею отложили, но в случае таких вопиющих нарушений к ней могут вернуться. Для любого провайдера, отзыв AS-номера влечёт невозможность BGP-маршрутизации, т.е. фактически означает принудительное отключение провайдера и всех его пользователей от всего остального интернета.
Вообще, весь этот движ за privacy заметно активизировался после попытки Казахстана пошалить с TLS Trusted Root. Очевидная цель в краткосрочной перспективе — прикрыть слишком явные дыры в безопасности, которыми пока что активно пользуются различные бантустаны; а долгосрочная цель — поставить бантустаны перед выбором: или вы играете по нашим правилам, или убираетесь вон из нашего интернета к чёртовой бабушке и создаёте свои отдельные недо-интернеты с известными достоинствами, если у вас на это хватит денег и мозгов. Особенно весело будет наблюдать за этими потугами в условиях работающего Starlink.
UPD (2020-09-22): В России планируют запретить DNS over TLS на законодательном уровне.
Эту фичу уже включили вручную (opt-in) 70 тысяч юзеров, у них всё работает нормально, поэтому в ближайшее время Mozilla планирует включить эту фичу по умолчанию, сначала для пользователей из США, а затем для всего мира, не считая Британии.
DoH-резолвинг доменных имён по умолчанию идёт через CloudFlare, что вызвало критику и оправдания со стороны Mozilla.
Учитывая этот опыт, компания Google, которая тоже планирует внедрить DoH в своём браузере, решила реализовать поддержку нескольких DoH-провайдеров (нужный будет выбираться автоматически, в зависимости от IP-адреса классического DNS-резолвера, который сейчас задан в системных настройках или был получен через DHCP; таким образом, насколько это возможно, DNS-провайдер не изменится, только добавится шифрование). Впрочем, у всех этих компаний privacy policy не лучше, чем у CloudFlare.
Крупным интернет-провайдерам затея с DoH не нравится, т.к. они теряют возможность составлять списки посещаемых пользователями сайтов, и далее продавать эти данные маркетинговым агентствам и другим заинтересованным лицам. Так, например, американский провайдер Comcast недавно активизировал своих лоббистов в Конгрессе с целью противодействия усилиям компаний Mozilla и Google по внедрению в их браузеры функции DoH-клиента.
Владельцы роутеров с прошивкой на основе OpenWRT уже сейчас могут установить прокси-сервер DNS-to-DoH, который будет обрабатывать DNS-запросы на LAN-интерфейсе и делать DoH-запросы через WAN-интерфейс. Таким образом, можно уже сейчас добавить DoH для всех legacy-устройств в локальной сети, выполняющихся на них программ и операционных систем.
В популярный блокировщик рекламы PiHole тоже недавно была добавлена поддержка DoH на бэкэнде. Кстати, чтобы PiHole и ей подобные могли по-прежнему видеть DNS-запросы на фронтэнде, даже после перехода на DoH по умолчанию, в Firefox добавлен workaround: так называемый canary domain "use-application-dns.net", при возврате ответа NXDOMAIN на который происходит отключение браузерного DoH-клиента (хотя Mozilla обещает это убрать, если заметит злоупотребления со стороны интернет-провайдеров). Google Chrome не планирует делать поддержку этого или любого другого canary domain, т.к. PiHole и прочие блокировщики рекламы вредят основному бизнесу корпорации.
А ещё недавно поддержка DoH была добавлена в curl, популярную библиотеку и консольный HTTP-клиент.
Почему победил DoH, а не DoT? Потому что враждебно настроенным провайдерам тривиально просто фильтровать исходящий трафик на 853-й TCP-порт.
Но провайдеры могут так же тривиально просто фильтровать IP-адреса 1.1.1.1 и 1.0.0.1? Могут, но компании CloudFlare технически ничего не мешает включить DoH-резолвер на всех своих IP-адресах.
А как же DNSSEC? Подписи в DNS-ответах прекрасны, но их наличие никак не мешает провайдеру по-прежнему подглядывать за пользователями (вести логи DNS-запросов и DNS-ответов); а когда провайдеру понадобится что-то заспуфить, он может запросто начать блокировать DNSSEC и тем самым форсировать downgrade клиентов на обычный нешифрованный DNS. На принцип Net Neutrality многие провайдеры давно забили, а вот https они уже не смогут, просто так, взять и отключить (слишком поздно, на него приходится 90% трафика), поэтому инкапсуляция DNS-трафика в https — как раз то, что нужно.
Но доменные имена посещаемых сайтов провайдеры по-прежнему могут извлекать из поля SNI, которое передаётся открытым текстом в начале любой https-сессии? Могут, но DPI-оборудование для stateful-анализа https встречается реже и стоит дороже, чем оборудование для простого анализа UDP-трафика на 53-м порту, а стандарт eSNI, предусматривающий шифрование этого поля, уже на подходе. В Firefox'е уже сейчас можно включить экспериментальную поддержку eSNI. Поле eSNI на клиентской стороне шифруется ключами, получаемыми через DNS, поэтому фича eSNI зависит от фичи DoH (во избежание MitM-атак на эти ключи, их подмены путём перехвата DNS на стороне провайдера). В компании Google пока думают: они хотят передавать ключ для eSNI-шифрования не через TXT-запись для поддомена "_esni", а через ESNI-запись (запись нового типа) в апексе, т.е. для всего домена. Из-за разногласий вокруг этих технических деталей между Google и Mozilla/CloudFlare стандартизация eSNI в IETF пока притормозилась, а вместе с ней и реализация поддержки eSNI в SSL-библиотеках и HTTP-серверах. Скорее всего, владельцам доменов первое время нужно будет делать и TXT-запись в _esni-поддомене, и ESNI-запись в апексе.
Как может быть решена "проблема курицы и яйца" для поля eSNI в https-сессиях к DoH-резолверам? ESNI-ключи для DoH-резолверов станут ещё одной квази-константой интернета, так же как IP-адреса DoH-резолверов, IP-адреса корневых DNS-серверов или TLS Trusted Root.
После массового внедрения eSNI и DoH, провайдеры смогут по-прежнему осуществлять фильтрацию сайтов по IP-адресам? Смогут, но со стороны крупных облачных сервисов, таких как CloudFlare, AWS, GCP, Azure и Akamai может последовать ответ в виде domain fronting.
А что, если особо упоротые провайдеры начнут блокировать полные блоки IP-адресов облачных сервисов? Об этом ещё рано думать, но недавно в Нумерационном Совете NRO RIR обсуждалась идея отозвать ранее распределённые номера автономных систем (AS) у крупных российских провайдеров (по причине нарушения связности интернета). Пока эту идею отложили, но в случае таких вопиющих нарушений к ней могут вернуться. Для любого провайдера, отзыв AS-номера влечёт невозможность BGP-маршрутизации, т.е. фактически означает принудительное отключение провайдера и всех его пользователей от всего остального интернета.
Вообще, весь этот движ за privacy заметно активизировался после попытки Казахстана пошалить с TLS Trusted Root. Очевидная цель в краткосрочной перспективе — прикрыть слишком явные дыры в безопасности, которыми пока что активно пользуются различные бантустаны; а долгосрочная цель — поставить бантустаны перед выбором: или вы играете по нашим правилам, или убираетесь вон из нашего интернета к чёртовой бабушке и создаёте свои отдельные недо-интернеты с известными достоинствами, если у вас на это хватит денег и мозгов. Особенно весело будет наблюдать за этими потугами в условиях работающего Starlink.
UPD (2020-09-22): В России планируют запретить DNS over TLS на законодательном уровне.
