Comments 15
".. алгоритмы случайного леса и градиентного бустинга, k-ближайших соседей и логистической регрессии" - почему то мне кажется что РКН как раз его и использует, судя по наполнению реестра блокировок))..
Все-таки в итоге что? Блокировать DoH или нет? По итогу Ваше мнение так и осталось не высказанным.
С одной стороны РКН с его "алгоритмами", а с другой поволная зависимость от клаудфларного DoH - тоже так себе перспектива..
От блокировок РКН DoH практически не помогает. Ну да, вы обойдёте DNS-фильтрацию у провайдеров, которые перехватывают DNS-запросы. Но практически никакой провайдер уже не полагается исключительно на фильтрацию средствами DNS. Это лишь первая линия блокировок, снижающая нагрузку на DPI (отсекает пользователей, которые попробовали ломануться на домен, получили от DNS-сервера провайдера адрес заглушки вместо адреса домена, увидели её и успокоились).
После того, как DoH-сервер вернул вам IP-адрес запрошенного домена, на этом его работа окончена. Дальше клиентское приложение пытается соединиться с этим адресом и в бой вступает DPI.
Ситуацию могли бы поменять ESNI и ECH, но первый уже deprecated, а второй пока так и не получил распространения. А когда получит, ну что ж, DPI просто начнёт рубить все HTTPS-соединения, где SNI зашифрован, а пользователям будет предложен выбор: отключайте поддержку ECH в браузере или страдайте.
Моя рекомендация: если вы используете какие-то средства обхода блокировок, при которых ваше устройство общается с DNS-серверами по незашифрованному каналу и провайдер перехватывает DNS-запросы, то используйте DoT/DoH. Например, если трафик пущен через VPN-туннель, то использовать DoH смысла нет. А если, скажем, для обхода блокировок используется GoodbyeDPI и провайдер перехватывает DNS-запросы, то использовать DoH нужно.
второй пока так и не получил распространения
Пока? А номер rfc для ech не подскажете?
QUIC - там SNI тоже "почти зашифрован". По крайнемере не летит клеартекстом через DPI. Пока что РКН'овские DPI не парятся над дешифровкой QUIC и пропускают без блокировок. На той неделе проверял - если внутри QUIC какой-нить запрещенный домен - то блокировок пока что нет. Что будет далее - ХЗ
Блочить полностью TLS1.3 - тоже так себе решение.Можно положить ненароком много всякого .. Тем более, что на клаудфларе сейчас inner SNI можно сверху снабдить outer SNI. Т.е. идет себе такой вполне легитимный пакет через DPI. Внутри (шифрованый) будет navalny.com, а снаружи (тот. который виден DPI и никак не учитывается клаудфларой) - например kremlin.ru. Я писал отдельную статью на эту тему на хабре с подробностями и картинками ))
Например, если трафик пущен через VPN-туннель, то использовать DoH смысла нет.
VPN может не предоставлять DNS сервер внутри (коммерческие всегда предоставляют) или кэш DNS может быть заражен до подключения к VPN.
Кто не хочет Quad9, Cloudflare и другой мейнстрим, советую посмотреть на добровольческие сервера проекта OpenNIC, DNSCrypt. Некоторые поддерживают и то и другое, но большинство OpenNIC - это DNS-over-TLS/HTTPS.
Кстати, о пичках (о DoH). Его ведь тоже можно через ECH или QUIC пускать, он ведь https, все-таки..) Клаудфларовский DoH - через ECH, гугловский - через QUIC)) 
.
На самом деле, есть тенденция к росту количества dns провайдеров, поддерживающих doh. Не cloudflare едины=)
Я не понимаю, зачем нужен DNS-over-HTTPS. Все равно же все видно по IP-адресу. Или вы думаете, что ваш провайдер не знает, что вы сидите на 8.8.8.8? Лучше бы вы занимались чем-то полезным, например, изучали X.25 и Frame Relay. Это настоящие сетевые технологии, а не ваши шифрованные пакетики.
Попросил чатГПТ придумать смешной комментарий к статье
Удивительная статья.
Что ни абзац - то вопрос.
Тот засыпает целевой компьютер большим количеством ненужных пакетов, пока не парализует его работу. Провести такую атаку в контексте DoH проблематично, так как протокол требует TCP-соединение.
А что помешает злоумышленнику атаковать через старый DNS?
злоумышленники начнут использовать DNS-over-HTTPS для сокрытия вредоносного трафика от средств мониторинга.
А какой смысл скрывать трафик? Ведь искомый домен вычислят скорее путём анализа действий вредоноса, чем копания в трафике где-то на магистрали. Хотя если злоумышленнику это бесплатно, то почему бы и не внедрить.
На основе этих данных она успешно идентифицирует 99% трафика, пересылаемого по протоколу DNS-over-HTTPS. Специалистам даже удалось определить различия между данными браузеров.
Это может помочь разве что для блокировки протокола злонамеренным правительством. А для борьбы со злонамеренной программой как?
Также в феврале прошлого года инженеры из Китая разработали схему, которая позволяет определить случаи туннелирования через DNS-over-HTTPS и находить потенциально вредоносные подключения.
А, вот если брать Китай, то да, там у компартии имеются свои суверенные представления, какие подключения считать вредоносными.
Их беспокоит тот факт, что пользователям предлагают доверить зашифрованные DNS-запросы третьей стороне, которую выбирают разработчики браузеров.
А передавать DNS-запросы незашифрованными, то есть доверять вообще хрен знает какой третьей, четвёртой и т.д. стороне -- не беспокоит?
Протокол DoH не позволяет интернет-провайдеру, проследить, какие ресурсы посещает пользователь.
don't bullshit me (c) а как же тогда провайдер провайдер блочит доступ к заболокированым ресурсам несмотря на использование doh?! а всё просто - потому что dpi залазит внутрь покета и цепляет tls_clienthello или как оно там назвается
помнится, правительство uk просило отложить ввод doh в браузерах, мешает контролировать пользователей
вот за пару минут нагуглилось упоминание:
https://www.theregister.com/2019/09/24/mozilla_backtracks_doh_for_uk_users/
потому что dpi залазит внутрь покета и цепляет tls_clienthello
да, но это уже сложнее/дороже
Что происходит с протоколом DNS-over-HTTPS