Разработчики Mozilla сообщили (https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-.../) о проведении четвёртого этапа тестирования функции обращения к DNS поверх HTTPS (DoH, DNS over HTTPS), который будет сосредоточен на оценке изменения производительности при применении DNS-over-HTTPS в условиях работы через сети доставки контента. На этой неделе небольшой части пользователей релизов Firefox из США будет предложено активировать DoH (при нежелании пользователь сможет отказаться). Как и раньше в качестве основного будет использован DNS-сервер CloudFlare, но в будущем планируется расширить число участвующих в тесте DNS-провайдеров.
Необходимость дополнительного тестирования DNS-over-HTTPS при работе через сети доставки контента связана с тем, что DNS-сервер CDN-сети формирует ответ, учитывая адрес резолвера и выдаёт ближайший хост для получения контента. Таким образом, отправка DNS-запроса c ближайшего к пользователю резолвера приведёт к тому, что CDN вернёт адрес ближайшего хоста, но при отправке DNS-запроса с централизованного резолвера DNS-over-HTTPS ближайший к пользователю хост определить не получится и будет выдан адрес хоста, ближайший к серверу DNS-over-HTTPS.
Указанная особенность сводит на нет средства оптимизации трафика в CDN, поэтому в процессе принятия решения о внедрении DNS-over-HTTPS необходимо учитывать не только производительность операций с DNS, но и дополнительные задержки, которые могут возникнуть из-за снижения эффективности загрузки контента через CDN. В прошлом году были проведены первые тесты для комплексной оценке задержек при использовании CDN, которые показали минимальное влияние применения DNS-over-HTTPS на задержки перед началом передачи контента (для быстрых соединений задержки не превышали 10 миллисекунд, а для медленных каналах связи наблюдалось даже ускорение работы).
При этом также были замечены подозрительные особенности, требующие дополнительного тестирования. Например, в прошлом тесте работы через CDN выявлено увеличение интенсивности появления ошибок при отправке DNS-запросов, независимо от использования DNS-over-HTTPS. В новом тесте планируется собрать более детальные данные об возникающих ошибках. Также планируется протестировать расширение EDNS Client Subnet, позволяющее передать резолверу CDN более дательные сведения о местоположении клиента для выбора ближайшей к нему точки отдачи трафика.
Так как обращение к финальному резолверу производится без шифрования и может привести к утечке сведений третьим лицам, решено ограничить применение EDNS Client Subnet только обращениями к Facebook через Cloudflare по совместной договорённости этих компаний и с применением шифрования DNS-трафика между ними (будет применяться DNS-over-TLS и прямое обращение к резолверу Facebook, что исключит из цепочки третьих лиц). При наличии в браузере Cookie от Facebook и при согласии пользователя на участие в эксперименте, браузер будет раз в день отправлять тестовые запросы к Facebooк (без передачи cookie) и измерять время отклика.
Для включения DoH на системах не приглашённых для участия в тестировании, достаточно в about:config изменить значение переменной network.trr.mode, которая поддерживается начиная с Firefox 60. Значение 0 полностью отключает DoH; 1 - используется DNS или DoH, в зависимости от того, что быстрее; 2 - используется DoH по умолчанию, а DNS как запасной вариант; 3 - используется только DoH; 4 - режим зеркалирования при котором DoH и DNS задействованы параллельно. По умолчанию используется DNS-сервер CloudFlare, но его можно изменить через параметр network.trr.uri, например, можно установить "https://dns.google.com/experimental" или "https://9.9.9.9/dns-query".Напомним, что DoH может оказаться полезным для исключения утечек сведений о запрашиваемых именах хостов через DNS-серверы провайдеров, борьбы с MITM-атаками и подменой DNS-трафика, противостояния блокировкам на уровне DNS или для организации работы в случае невозможности прямого обращения к DNS-серверам (например, при работе через прокси). Если в обычной ситуации DNS-запросы напрямую отправляются на определённые в конфигурации системы DNS-серверы, то в случае DoH запрос на определение IP-адреса хоста инкапсулируется в трафик HTTPS и отправляется на HTTP-сервер, на котором резолвер обрабатывает запросы через Web API. Существующий стандарт DNSSEC использует шифрование лишь для аутентификации клиента и сервера, но не защищает трафик от перехвата и не гарантирует конфиденциальность запросов.
URL: https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-.../
Новость: https://www.opennet.me/opennews/art.shtml?num=50448
Блин, если честно, то уже некоторая ностальгия наказывает по беззаботному Интернету с простыми как топор протоколами типа DNS, HTTP. Сейчас все с приставочкой S, это так-то нужное дело, безопасность, шифрование. Плюс новые HTTP 2, типа для скорости. Но сложность и вложенность этого хозяйства печалит.
> Сейчас все с приставочкой S, это так-то нужное дело, безопасность, шифрование.Вся беда в том, что все так же путают шифрование с безопасностью, как и 20 лет назад, передавая прямым текстом пароли внутри шифрованого канала "ну а че, оно ведь зашифровано!", приделывая к браузеру все новые важные апи наподобие "Ambient Light API" и "WebVR/Wifi Information API", тогда как несчастный "HTTP Authentication" так и остался с MD5, а новая версия RFC вообще не предусматривает защиты пароля, потому что для этого, типа, есть S в HTTPS 🙄 …
А каким текстом надо передавать пароль? Или про что ты говоришь?А HTTP auth разве не позволял хэш функцию на своё усмотрение использовать?
> А каким текстом надо передавать пароль? Или про что ты говоришь?Лучше всего вообще никаким (хотя бы после регистрации). См. хотя бы ту же авторизацию в WPA-PSK (никто не гоняет пароль), как и 100500 других способов обмена ключей, их геренации/модификации - PBKDF2 и т.д. и т.п.
> А HTTP auth разве не позволял хэш функцию на своё усмотрение использовать?
Глянул:
> An optional header allows the server to specify the algorithm used to
> create the checksum or digest. By default the MD5 algorithm is used
> and that is the only algorithm described in this document.Толку-то, если нигде не используется?
Но в Интернете мы обычно всё же вводим логин-пароль, какие там ещё варианты? Это в SSH можно по сертификату
Вводим, но речь про то что передаем, а не про то что вводим.
В wifi тоже же вводится пароль, но не передается в эфир.
Так в Интернете и передаём
> Но в Интернете мы обычно всё же вводим логин-пароль, какие там ещё варианты?Это вообще классическое "здесь так принято!".
Хотя, например, сервер может затребовать "дай-ка мне результат PBKDF2(изначальный_пароль + timenow(), соль, 100500 + random(1337))",
да и вообще, хранить не сам пароль в плейнтексте, а что-то вроде PBKDF2(пароль+ сайт, соль, 100499)Таким образом, при перехвате обмена сообщениями в расшифрованном виде все равно нет утечки пароля, а при взломе хоста и дампе БД даже слабые пароли взламываются только с большими затратами (а не так, как сейчас - хранят кто во что горазд, в том числе и открыто).
То же самое желательно с аутентификацией сообщений - оно не должно быть завязанным на шифрование канала.
> да и вообще, хранить не сам пароль в плейнтекстеКто-то ещё не хэши пароли??
*хэширует
Facebook, например, предпочитает просто текст, без хешей.
Лол, какого ф*га?
Чем больше информации собрано о пользователе, тем лучше, их бизнес на этом завязан. С чего бы им не хранить пароли, если выбор пароля тоже что-то говорит о пользователе?
И незачем городить эти жуткие костыли, есть рабочая схема Secure Remote Password (SRP).
Похоже человек думает, что если передавать не пароль для проверки, а хэш пароля это будет более безопасно. :)
+1, а я то начал думать это я что-то не понял :) Человек тот пусть почитает про радужные таблицы. Если же он про передачу пароля по (OTR) end-to-end, то пусть объяснит смысл этого при наличии https.
Соление паролей обламывает радужные таблицы
> +1, а я то начал думать это я что-то не понял :)
> Человек тот пусть почитает про радужные таблицы.Удачи c радужными таблицами для PBKDF2(пароль + timenow(), salt, 100500итераций). Не говоря уже об упомянутом SRP (Secure Remote Password)
> Если же он про передачу пароля по (OTR) end-to-end, то пусть объяснит смысл этого при наличии https.Сперва пусть любители радуг объяснят, зачем передавать пароль, когда можно его не передавать и зачем завязывать все на Single Point of Failure в виде шифрования канала передачи, когда можно не завязывать?
Да понятно, что передавать пароль по сети небезопасно. Но что лучше? Все остальное требует дополнительных телодвижений, сертификатов или ещё чего-то сверх
> Толку-то, если нигде не используется?А какие претензии к стандарту? Может это говорит о том, что никому не нужно что-то другое использовать, раз есть возможность, но не пользуются?
>> Толку-то, если нигде не используется?
> А какие претензии к стандарту?Отсутствие реализации (не обязательно допотопного RFC2617, а просто такого класса АПИ) в браузерах, при наличии API для опроса батарейки или освещения, не говоря уже о DB на стороне пользователя, WebRTC и прочих совсем не простых штуковин?
Из-за этого имеем вот уже 20 лет хранение паролей "кто во что горазд" и реализацию auth в меру понимания отдельного разработчика конкретного сайта со всеми "вытекающими и протекающими".Нелюблю эти "фиксед", но в этом случае само напрашивается
> Может это говорит о том, что браузеростроителям не нужно что-то другое использовать, раз есть возможность, но не пользуются, а вебмакаки даже не задумываются о том, что "да, так тоже можно делать", ведь "всегда пароли слали чистым текстом!"?fix
Как с тобой связаться? Хочу консультацию получить.
> а вебмакаки даже не задумываютсямы как раз задумываемся - то user side js'ом пошифруем, то вообще жаба-аплет вам выгрузим, который все в обход браузера сделает, с шифрованием на сертификатах, отдельно защищенных паролем, который вообще никуда не передается (это как раз можно сделать в браузере, но средний пользователь-альтернативно-умный не справится, зато справятся кросс-сайт хаки, выполняющие что-нибудь от его имени - можно костылить подпорки, но проще вообще без браузера обойтись), раньше еще на флэше делали, чтоб хотя бы внешне имело вид исполняемого внутри браузера, но мудрый гугель в обнимку с хитрой мордокнигой велели его отменить, чтоб не мешал им ваши данные тырить.
А в браузерах нормальной авторизации нет и не будет, потому что да - ваши пароли уже упали в бездонные базы мордокниги, и она не собирается отказываться от этой прекрасной возможности.
Web и так уже тормозной из-за раздутых js сайтов и тупости веб разрабов, так они еще хотят DNS замедлить.
Они хотят вывести его из-под возможности подмены/блокирования. Впрочем, превентивные методы для устранения данной недоработки уже анонсированы.
Вывести из-под возможности подмены/блокирования местным оператором для возможности подмены/блокирования корпорацией/корпорациями добра, ты хотел сказать.
> Они хотят вывести его из-под возможности подмены/блокирования.Отнять у пользователя простую возможность подмены/блокирования и забрать себе.
Ну DNS-запрос ты, по идее, один делаешь, и дальше его кэшируешь. Разве только на сайте нет запроса к тысяче доменов, типа всяких рекламных 5.dick.lohi.reklama.cool
> будет применяться DNS-over-TLS и прямое обращение к резолверу Facebook, что исключит из цепочки третьих лицНу и зачем эта клоунада с отдельным протоколом на базе HTTP?
Потому что работа с сокетами, шифрованием и всем остальным вручную - это сложна. Куда проще бахнуть HTTPS запрос и выдрать готовенький ответ. А об оверхеде подумаем когда-нибудь потом (нет), когда срочные таски по изменению оттенков оформления и телеметрии закончим.
User=>Computer=>IP=>DNS-request == Spying in one single place aka DoH
чтобы не было видно, что вся телеметрия идёт в гугл :)
> Также планируется протестировать расширение EDNS Client Subnet, позволяющее передать резолверу CDN более дательные сведения о местоположении клиента……и вызова маски-шоу на адрес проживания клиента при первом подозрении? :)
Стоит отметить, что например неадекватные админы archive.is вообще блокируют пользователей cloudflare dns из-за отсутствия edns client subnet, которые не передаются ради приватности.
https://twitter.com/archiveis/status/1018691421182791680
https://community.cloudflare.com/t/archive-is-error-1001/18227
Мои DNS-запросы должна отправлять ось. Кстати вопрос: и как теперь отличить https-траффик от dns-over-https, чтобы порезать его у себя (превентивненько)?
P.S. Да собственно о чём это я. Итак всё понятно. Инторнет зарулен.
Ну что ты, глупенький. Конечно же, ОС ничем рулить не должна - она обновляются слишком медленно, у корпораций добра на это нет времени, сляпали на коленке новую фичу, уяк-уяк - и в продакшн!
Пока старый вариант DNS протокола поддерживается ещё остаётся возможность поменять конфигурацию клиента или пересобрать его, исправив в крайнем случае.
s/у себя/у себя на локалхосте/
конечно же
А никак. Оно для этого и создавалось, чтобы местные любители обнюхивать трафик (читай "провайдеры" и "локальный сисьадмины, возомнившие себя божками") убрали свои ручонки от трафика абонентов.
да, да, это НАШИ эмм... абоненты, и МЫ их траффик будем нюхать, а так же хранить себе на память.но вы продолжайте распространять слухи о провайдерах и локальных сисадминах, которым, конечно же, делать нечего, как смотреть на что вы там др..те в рабочее время, пусть больше лохов ведется.
Ну да, ну да. И рекламу в HTTPS-трафик провайдеры не суют. Вообще трафик их не интересует, делать им нечего больше.Билайн на этом ловили пару лет назад. Сегодня поймали Мегафон. И Йота вообще не режет неопознанный трафик. Всё это выдумки. Продолжайте игнорировать реальность.
Четвёртый этап тестирования DNS-over-HTTPS в CloudflareПофиксил заголовок
Когда уже будет http-over-dns-over-http-over-ssh
> http over dnsУже есть, Iodine называется.
> dns over http
Собственно сабж
> http over ssh
Туннель настраивается на раз-два.
Предлагаю тебе все это объединить и отписаться о результатах.
Это и без всяких имплементация понятно что плохая затея. Я от недовольства задал вопрос. Не пойму логику сегодняшних разрабов: пропустить все через HTTP.
> DNS-сервер CloudFlare
> CloudFlareСпасибо, ненужно. Как-нибудь dnscrypt обойдемся. Оно хотя бы позволяет выбрать, заруливать запросы на свой/доверенный сервер или сливать корпорастам/шпионам из списка.
> Как-нибудь dnscrypt обойдемсякстати об этом. Не подскажите хорошего гайда по установке-настройке на ноут с системдой(манжара), нетворкманагером и dnsmasq?
По гайду с рачевики застрял - там пишут убрать все с 53 порта, а на нем висит pid 1 и отказывается уходить
Systemd-resolvd?
скорее всего. Отключить не вышло, ибо после перезагрузки спавнилось обратно
А кто здесь мешает прописать собственный сервер. Там ответ идёт обычным джейсоном. В браузере можно свободно поставить свой сервер. Хттпс от работает стандартный сертификат.
В чем вопрос?
DNSCrypt провайдеру легче заблокировать (если говорить о публичнх серверах). Адреса серверов хорошо известны (любезно лежат прямо в репозитории). Адреса эти редко меняются (чтобы клиентам не приходилось думать об обновлении этого списка на своей стороне).Вдобавок, у меня есть подозрение, что и детектить трафик DNSCrypt тоже гораздо проще, чем DoT.
Прчему провайдер может блокировать DNSCrypt? Ну, например, некоторые провайдеры в РФ уже сейчас заворачивают нешифрованный DNS-трафик на себя по рекомендациям Роскомнадзора. Поступит рекомендация резать DNSCrypt - будут резать при условии, что это легко.
Вдобавок, в прошлом месяце проскочила инфа о совершенно волшебном "кейсе": выездная проверка РКН прибыла в какое-то кафе (они периодически мониторят публичные заведения с целью проверки "а блокируется ли тут у вас доступ к сайту Навального и прочему нехорошему контенту"). Небольшой провайдер, который предоставлял этому кафе доступ в интернет, надеялся на то, что клиенты адекватные и запрещёнку блокировал исключительно принудительным перехватом DNS-запросов. Владелец кафе на своём оборудовании настроил то ли DNSCrypt, то ли DoT. Короче, сделал клиентам интернеты без блокировок. В итоге, вы будете ржать, но штраф выписали провайдеру (да, в РКН умные люди нн работают) Чем дело кончилось, не щнаю, но сисадмин провайдера, который всё это и поведал миру, задумался о более жёстких способах вмешательства в пользовательский трафик.
> DNSCrypt провайдеру легче заблокировать (если говорить о публичнх серверах).А адреса cloudflare dns и прочих популярных публичных DoH провайдеров чем-то сложнее будет заблокировать, лол?
> Вдобавок, у меня есть подозрение, что и детектить трафик DNSCrypt тоже гораздо проще, чем DoT.
Почему? По-логике - без разницы. Вот отличить DoH от обычного HTTPS невозможно, да. Только, кажется, проблем от этого только больше.
> вы будете ржать, но штраф выписали провайдеру
А кому блин надо было выписывать? Владельцу кафе? Так кафе - это деятельность РКНу неподотчётная, я так полагаю. Они, ЕМНИП, приходят только к тем, у кого есть лицензия на оказание услуг связи. И карает лишением оной, если тот, к кому они пришли, послал их по известному адресу. У кафе, очевидно, подобной лицензии нет и следовательно нет и нарушения законов.
У владельца кафе по закону даже списка "запрещённых сайтов" быть не может, т.е. он, в теории, даже не знает, что должно работать, а что нет.
Да и косяк так или иначе провайдерский, и на что он там понадеялся - исключительно его, провайдера, половые сложности. И по закону, и по совести.А вообще мне жаль, что РКН работает так на от...сь. Работал бы нормально, пришлось бы всем пользоваться нормальными цензуро-устойчивыми решениями, пришлось бы пилить да развивать их и вообще был бы движ. А так - скукота, нажал галочку в бровзере и всё, ты какир. Тьфу.
> Вот отличить DoH от обычного HTTPS невозможно, да.главное, верьте!
>> Вот отличить DoH от обычного HTTPS невозможно, да.
> главное, верьте!Cloudflare как минимум сможет, да. Но на мой взгляд нет причин использовать DoH как с cloudflare, так и без, так что...
> А адреса cloudflare dns и прочих популярных публичных DoH провайдеров чем-то сложнее
> будет заблокировать, лол?Прикинь, да. У РКН уже много лет основная мантра "нам не нужны стрессы". Массова блокировка CF (а не как сейчас по полторая адреса в сутки) создаст стрессы. Так что, сложнее, кек.
> А кому блин надо было выписывать?
По твоей логике, если владелец кафе настроил OpenVPN и пустил весь трафик через туннель, тоже надо провайдера штрафовать? А если я тебя обматерю кириллическими буквами, то ты Мефодию морду бить пойдешь?
> Прикинь, да. У РКН уже много лет основная мантра "нам не нужны стрессы". Массова блокировка CF (а не как сейчас по полторая адреса в сутки) создаст стрессы. Так что, сложнее, кек.Чушь от первого до последнего слова. Забанят сразу подсетью, как делали при попытках забанить телеграм и даже не почешутся. Но вы продолжайте верить, что банить публичные адреса популярных Dnscrypt провайдеров проще, чем какие либо другие публичные адреса.
> По твоей логике, если владелец кафе настроил OpenVPN и пустил весь трафик через туннель, тоже надо провайдера штрафовать? А если я тебя обматерю кириллическими буквами, то ты Мефодию морду бить пойдешь?
Это не моя логика, это законодательство. И, к слову, в этом месте абсолютно последовательное, в отличие от тебя; ты же просто передёргиваешь.
Провайдер предоставляет услуги связи - ему и отвечать за несоответствие услуг требованиям государства. После получения втыка от РКН провайдер может, например, отключить кафе от своих услуг - но только так. Кафе и аналогичное РКН не подотчётны.
И продолжая твою нелепую аналогию: вне зависимости от того, обматеришь ты меня при личной встрече или по telegram, я пойду "бить морду" тебе, а не дурову. Ферштейн?
Rkn сасай.
Вот используешь ты DoT как клиент у тебя сертифкат в конфиге прописан? :) Ну вот по умолчанию мало у кого прописан, а если не прописан - то ничто не мешает провайдеру завернуть это дело на себя.С Encrypted SNI ещё смешнее - достаточно заворачивать на себя DNS и блокировать запрос eSNI из DNS. После чего браузер клиента откатывается к обычному нешифрованному SNI.
Прочитал в начале как "Rkn спасай"
тут уже к Росатому взывать надо, а не к РКН.
Никто не расскажет, как включить это дерьмо в Ubuntu правильным способом - через SystemD?
> Никто не расскажет, как включить это дерьмо в Ubuntu правильным способом - через SystemD?Конечно расскажу!
systemctl enable this-shit-in-ubuntu.service && systemctl start this-shit-in-ubuntu.service
Не благодари!
HTTP(S) стал еще одним уровнем в стеке протоколов Интернета, поверх которого уже работают разные прикладные протоколы (которые теперь почему-то принято называть "Web API"). Только вот в чем смысл этого уровня? Ему можно хотя бы дать название, чтобы было понятно, за что он отвечает?
С точки зрения "стека протоколов интернета", что бы это ни значило, DoH просто не существует. Браузер получает данные о хоснэймах, делая запросы по https вкудато вместо того, чтобы брать эти данные у резолвера.
Вне браузера DoH - это рак мозга даже с точки зрения его обсаженных создателей.
я уже пилю нужный неотключаемый патч к systemd-resolved! Через пять минут закоммичу, подождите чуток!
>Как и раньше в качестве основного будет использован DNS-сервер CloudFlareDoH и DoT это конечно восхитительно, но почему именно CloudFlare, не безопасно ведь, PandoraBox так сказать. Лучше Google тем более сервера скоро физически будут размещены на территории Нашей Страны и за безопасность своих данных можно не беспокоится или Отечественный Яндекс вообще было бы прекрасно. Лично я не хочу делить конфиденциальные данные с АНБ!
Полностью с Вами согласен, Яндекс был бы весьма кстатьи. Интересно Яндекс DNS уже поддерживает DoH, не знаете?
Нужен способ указать исключения для DNS-over-HTTPS, чтобы локальные адреса разрешались нормально. Cloudfare про них, разумеется, не знает.
теперь - знаем. И поделимся знанием, если попросят.(а fallback в браузере и так есть - только он сначала нам сливает, а уже потом остальное делает)
Вещь нужная. Некоторые используют DNSCrypt. Но использовать CloudFlare однозначно не буду. Услуги последнего весьма и весьма сомнительны.
Забавно, что включение режима "3" просто делает браузер неработоспособным из-за невозможности разрешения имен. Потому что в network.trr.uri стоит "https://mozilla.cloudflare-dns.com/dns-query". Установка "https://9.9.9.9/dns-query" проблему решает.Так они слона не продадут.
Забыл в какой тоталитарной стране жив^W выживаешь?
https://www.opennet.me/tips/3086_esni_doh_dns_https.shtml#15
Очередная ненужно крипто, чтобы АНБ всё знало обо всех реалтайм.
Так, народ, это /etc/hosts теперь для отладки не катит?