Чуть не до конца дочитал, бывает)
А так да, такие штуки довольно хороши, хотя уже крайняя мера, когда давно не будет работать goodbyedpi и заблочат обычные прокси и vpn
Где-то видел, что блокировали торренты по коомбинации размера пакета и первым пару байтам. С ESNI да, эффективное решение для его вычисления найти сложнее
Так все-таки зачем? Какой смысл в блокировке DoH?
Меня всегда такой факт забавлял. В РФ есть статя за порнографию, поэтому все ресурсы с ней блокируют. Вроде как в законе нет исключений, чтобы можно было разрешить ее распространять. Но, видимо, порнуха на порнхабе недостаточно порнушная в сравнении с другими ресурсами, чтобы его блокировать. Насколько я помню, у нас нет такого, что можно поставить фильтр на 18+ и создавать порносайт, но чудеса бывают, как в случае с разблоком порнхаба)
C полпинка очень трудно ответить на этот вопрос…
DNS у большинства пользователей - физических лиц и так настроен по простому протоколу без шифрования, любой провайдер, если захочет, развернет его себе. У кого-то это часть блокировок, кто-то желает анализировать, куда клиент ходит. DoH и DoT мало кто использует, но все стремительно меняется - стоит, например, Google включить это по умолчанию в новых версиях Андроида…
Есть надежда, что дадут задний ход, хотя бы немного проанализировав бессмысленность того, что делают.
Все просто. Раньше я мог зайти на рутрекер и скачать фильм. Потом мне пришлось использовать анонимайзер, потом vpn, потом пришлось пользоваться goodbyedpi (и написать свою dpitunnel-cli). Как видишь, с каждым разом приходится шевелиться все больше и больше, причем как пользователю, так и разработчикам/администраторам. Обычный юзер теперь пять раз подумает, а нужен ли ему этот фильм или, что актуально в последнее время, сайт УГ или нет. Отрицать то, что посещаемость УГ или рутрекера после блокировок, да еще сложнообходимых, упадет, просто глупо
Про одно из предназанчений тех же dpi - анализ трафика клиента, какую рекламу подсунуть и прочая маркетология, тоже звучит хорошо. Но ркн от этого выгоды мало
Уже нет. СМИ писали, что Ревизоры давно научились такое проверять и провайдеру прилетит огромный штраф в случае если блокировки выполняются только по DNS.
Мне тоже так кажется. В прошлом году видел презентацию одной DPI системы для провайдеров, в которой одной из фич как раз был анализ DNS и построение профиля каждого абонента на основе этих данных.
Самое забавное, что та система умела анализировать через DNS и SNI зашел ли абонент на сайт провайдера-конкурента, что трактуется как желание сменить провайдера, а значит нужно ему позвонить и предложить скидку и т.п.
I, too, have not found a domain that works for fronting with dns.google. There were many that worked with dns.google.com, but not dns.google, if I remember correctly.
Hmm, but the goal is not to hide the Host header, but to hide the SNI and DNS query. Connecting to dns.google and sending a Host of whatever.google.com may work, but it is still blockable because the censor sees a connection to dns.google. You need the opposite: connecting to whatever.google.com and sending a Host of dns.google. In my tests, the latter technique does not work.
I believe this is what you are describing. It “works” in the sense of returning a response, but the censor still sees a DNS query and SNI for dns.google, which means it can be blocked.
$ curl -H 'Host: docs.google.com' 'https://dns.google/resolve?name=example.com&type=A'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"example.com.","type":1}],"Answer":[{"name":"example.com.","type":1,"TTL":13490,"data":"93.184.216.34"}]}
What you really want is the following, but in my tests it does not work:
$ curl -H 'Host: dns.google' 'https://docs.google.com/resolve?name=example.com&type=A'
<!DOCTYPE html>
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 404 (Not Found)!!1</title>
...
<a href=//www.google.com/><span id=logo aria-label=Google></span></a>
<p><b>404.</b> <ins>That’s an error.</ins>
<p>The requested URL <code>/resolve</code> was not found on this server. <ins>That’s all we know.</ins>
Note, in these examples I used the JSON /resolve endpoint, not the RFC 8484 /dns-query endpoint, but I believe the result is the same in terms of domain fronting.
Sending request to 8.8.8.8 or 8.8.4.4 with google.com SNI works for DNS resolving, but not for other (regular) IP addresses.
$ curl --resolve *:443:8.8.4.4 -k 'https://google.com/resolve?name=example.com&type=A'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"example.com.","type":1}],"Answer":[{"name":"example.com.","type":1,"TTL":4786,"data":"93.184.216.34"}]}
Тот пример, что привели вы — не domain fronting. Domain Fronting заключается в подмене SNI (это то, что видит DPI), а вы наоборот подменяете Host.
Ни мне, ни @tango не удаётся найти такой домен, при нормальном обращении к которому (на оригинальные IP-адреса и с оригинальным SNI) можно бы было отправить DNS-запрос внутри установленной TLS-сессии — а именно в этом суть domain fronting.
Есть ненулевая вероятность, что весь этот цирк с конями начали ровно за 10 дней до выборов только из-за одной проги Навальный, чтобы ко дню голосования максимально затруднить получение информаци по кандидатам про УмГ.
Хм, а что, у кого-то есть другие предположения? По-моему, это довольно очевидно.
Сторонники Навального рекламировали SDK NewNode, которое использует DHT, а в Android-приложении вбиты dns.google и doh.opendns.com, но не dns.google.com (поэтому он работает).
Тогда флаг им в руки блокировать или замедлять YouTube. Вроде бы там обещали зачитывать список кандидатов.
Да, но он отсутствует в Android-приложении Навального, поэтому его не блокируют.
Однако, удалось протестировать dns.google.com в качестве приватного DNS в Андроиде (если я правильно понимаю, там может быть только резолвер с DoT). Хотя точно не знаю. Но оно работает.
А вот сделать запрос формата https://dns.google.com/dns-query не вышло.