The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Четвёртый этап тестирования DNS-over-HTTPS в Firefox

03.04.2019 13:06

Разработчики Mozilla сообщили о проведении четвёртого этапа тестирования функции обращения к 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 использует шифрование лишь для аутентификации клиента и сервера, но не защищает трафик от перехвата и не гарантирует конфиденциальность запросов.

  1. Главная ссылка к новости (https://blog.mozilla.org/futur...)
  2. OpenNews: В следующем выпуске Android появится поддержка "DNS over TLS"
  3. OpenNews: ICANN призывает к повсеместному внедрению DNSSEC. Обновление BIND с устранением уязвимостей
  4. OpenNews: Тестирование DNS over HTTPS в Firefox может привести к утечке данных об открываемых сайтах
  5. OpenNews: Mozilla тестирует DNS поверх HTTPS и применение GPU для отрисовки
  6. OpenNews: Новый этап тестирования DNS поверх HTTPS в Firefox
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50448-dns
Ключевые слова: dns, https, dns-over-https, doh
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (75) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 13:43, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    Блин, если честно, то уже некоторая ностальгия наказывает по беззаботному Интернету с простыми как топор протоколами типа DNS, HTTP. Сейчас все с приставочкой S, это так-то нужное дело, безопасность, шифрование. Плюс новые HTTP 2, типа для скорости. Но сложность и вложенность этого хозяйства печалит.
     
     
  • 2.8, Аноним84701 (ok), 15:01, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Сейчас все с приставочкой  S, это так-то нужное дело, безопасность, шифрование.

    Вся беда в том, что все так же путают шифрование с безопасностью, как и 20 лет назад, передавая  прямым текстом пароли внутри шифрованого канала "ну а че, оно ведь зашифровано!", приделывая к браузеру все новые важные апи наподобие "Ambient Light API" и "WebVR/Wifi Information API", тогда как несчастный "HTTP Authentication" так и остался с MD5, а новая версия RFC вообще не предусматривает защиты пароля, потому что для этого, типа, есть S в HTTPS 🙄 …

     
     
  • 3.9, Аноним (1), 15:03, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А каким текстом надо передавать пароль? Или про что ты говоришь?

    А HTTP auth разве не позволял хэш функцию на своё усмотрение использовать?

     
     
  • 4.10, Аноним84701 (ok), 15:08, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А каким текстом надо передавать пароль? Или про что ты говоришь?

    Лучше всего вообще никаким (хотя бы после регистрации). См. хотя бы ту же авторизацию в 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.

    Толку-то, если нигде не используется?

     
     
  • 5.15, Аноним (15), 16:12, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Но в Интернете мы обычно всё же вводим логин-пароль, какие там ещё варианты? Это в SSH можно по сертификату
     
     
  • 6.19, Аноним (19), 16:44, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вводим, но речь про то что передаем, а не про то что вводим.
    В wifi тоже же вводится пароль, но не передается в эфир.
     
     
  • 7.28, Аноним (28), 17:36, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Так в Интернете и передаём
     
  • 6.22, Аноним84701 (ok), 16:54, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Но в Интернете мы обычно всё же вводим логин-пароль, какие там ещё  варианты?

    Это вообще классическое "здесь так принято!".
    Хотя, например, сервер может затребовать "дай-ка мне результат PBKDF2(изначальный_пароль + timenow(), соль, 100500 + random(1337))",
    да и  вообще, хранить не сам пароль в плейнтексте, а что-то вроде PBKDF2(пароль+ сайт, соль, 100499)

    Таким образом, при перехвате обмена сообщениями в расшифрованном виде все равно нет утечки пароля, а при взломе хоста и дампе БД даже слабые пароли взламываются только с большими затратами (а не так, как сейчас - хранят кто во что горазд, в том числе и открыто).

    То же самое желательно с аутентификацией сообщений - оно не должно быть завязанным на шифрование канала.

     
     
  • 7.26, Аноним (28), 17:36, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > да и  вообще, хранить не сам пароль в плейнтексте

    Кто-то ещё не хэши пароли??

     
     
  • 8.27, Аноним (28), 17:36, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    хэширует ... текст свёрнут, показать
     
  • 8.32, тратата (?), 18:40, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Facebook, например, предпочитает просто текст, без хешей ... текст свёрнут, показать
     
     
  • 9.35, Аноним (28), 19:43, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Лол, какого ф га ... текст свёрнут, показать
     
     
  • 10.47, Аноним (47), 23:37, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чем больше информации собрано о пользователе, тем лучше, их бизнес на этом завяз... текст свёрнут, показать
     
  • 7.33, Аноним (33), 19:16, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И незачем городить эти жуткие костыли, есть рабочая схема Secure Remote Password (SRP).
     
  • 6.68, pda (?), 22:44, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже человек думает, что если передавать не пароль для проверки, а хэш пароля это будет более безопасно. :)
     
     
  • 7.70, Аноним (70), 10:04, 05/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    +1, а я то начал думать это я что-то не понял :) Человек тот пусть почитает про радужные таблицы. Если же он про передачу пароля по (OTR) end-to-end, то пусть объяснит смысл этого при наличии https.
     
     
  • 8.72, Аноним (1), 11:06, 05/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Соление паролей обламывает радужные таблицы... текст свёрнут, показать
     
  • 8.73, Аноним84701 (ok), 11:08, 05/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Удачи c радужными таблицами для PBKDF2 пароль timenow , salt, 100500итераций ... текст свёрнут, показать
     
  • 7.71, Аноним (1), 11:06, 05/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да понятно, что передавать пароль по сети небезопасно. Но что лучше? Все остальное требует дополнительных телодвижений, сертификатов или ещё чего-то сверх
     
  • 5.21, Аноним (21), 16:47, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Толку-то, если нигде не используется?

    А какие претензии к стандарту? Может это говорит о том, что никому не нужно что-то другое использовать, раз есть возможность, но не пользуются?

     
     
  • 6.23, Аноним84701 (ok), 17:02, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Толку-то, если нигде не используется?
    > А какие претензии к стандарту?

    Отсутствие реализации  (не обязательно допотопного RFC2617, а просто такого класса АПИ) в браузерах, при наличии API для опроса батарейки или освещения, не говоря уже о DB на стороне пользователя, WebRTC и прочих совсем не простых штуковин?
    Из-за этого имеем вот уже 20 лет хранение паролей "кто во что горазд" и реализацию auth в меру понимания отдельного разработчика конкретного сайта со всеми "вытекающими и протекающими".

    Нелюблю эти "фиксед", но в этом случае само напрашивается
    > Может это говорит о том, что браузеростроителям не нужно что-то другое использовать, раз есть возможность, но не пользуются, а вебмакаки даже не задумываются о том, что "да, так тоже можно делать", ведь "всегда пароли слали чистым текстом!"?

    fix

     
     
  • 7.52, robot228 (?), 07:06, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как с тобой связаться? Хочу консультацию получить.
     
  • 7.54, вебмакак (?), 10:01, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > а вебмакаки даже не задумываются

    мы как раз задумываемся - то user side js'ом пошифруем, то вообще жаба-аплет вам выгрузим, который все в обход браузера сделает, с шифрованием на сертификатах, отдельно защищенных паролем, который вообще никуда не передается (это как раз можно сделать в браузере, но средний пользователь-альтернативно-умный не справится, зато справятся кросс-сайт хаки, выполняющие что-нибудь от его имени -  можно костылить подпорки, но проще вообще без браузера обойтись), раньше еще на флэше делали, чтоб хотя бы внешне имело вид исполняемого внутри браузера, но мудрый гугель в обнимку с хитрой мордокнигой велели его отменить, чтоб не мешал им ваши данные тырить.

    А в браузерах нормальной авторизации нет и не будет, потому что да - ваши пароли уже упали в бездонные базы мордокниги, и она не собирается отказываться от этой прекрасной возможности.

     

  • 1.2, Аноним (2), 13:44, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Web и так уже тормозной из-за раздутых js сайтов и тупости веб разрабов, так они еще хотят DNS замедлить.
     
     
  • 2.4, Аноним (4), 13:47, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Они хотят вывести его из-под возможности подмены/блокирования. Впрочем, превентивные методы для устранения данной недоработки уже анонсированы.
     
     
  • 3.16, zzz (??), 16:15, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вывести из-под возможности подмены/блокирования местным оператором для возможности подмены/блокирования корпорацией/корпорациями добра, ты хотел сказать.
     
  • 3.18, Аноним (18), 16:41, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Они хотят вывести его из-под возможности подмены/блокирования.

    Отнять у пользователя простую возможность подмены/блокирования и забрать себе.

     
  • 2.6, Аноним (1), 13:49, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну DNS-запрос ты, по идее, один делаешь, и дальше его кэшируешь. Разве только на сайте нет запроса к тысяче доменов, типа всяких рекламных 5.dick.lohi.reklama.cool
     

  • 1.3, Аноним (3), 13:46, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > будет применяться DNS-over-TLS и прямое обращение к резолверу Facebook, что исключит из цепочки третьих лиц

    Ну и зачем эта клоунада с отдельным протоколом на базе HTTP?

     
     
  • 2.11, НяшМяш (ok), 15:24, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Потому что работа с сокетами, шифрованием и всем остальным вручную - это сложна. Куда проще бахнуть HTTPS запрос и выдрать готовенький ответ. А об оверхеде подумаем когда-нибудь потом (нет), когда срочные таски по изменению оттенков оформления и телеметрии закончим.
     
  • 2.12, OpenEcho (?), 15:37, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    User=>Computer=>IP=>DNS-request  == Spying in one single place aka DoH
     
  • 2.74, DmA (??), 12:08, 05/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    чтобы не было видно, что вся телеметрия идёт в гугл :)
     

  • 1.5, Аноним (5), 13:48, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Также планируется протестировать расширение EDNS Client Subnet, позволяющее передать резолверу CDN более дательные сведения о местоположении клиента…

    …и вызова маски-шоу на адрес проживания клиента при первом подозрении? :)

     
  • 1.7, Аноним (21), 14:19, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Стоит отметить, что например неадекватные админы archive.is вообще блокируют пользователей cloudflare dns из-за отсутствия edns client subnet, которые не передаются ради приватности.
    https://twitter.com/archiveis/status/1018691421182791680
    https://community.cloudflare.com/t/archive-is-error-1001/18227
     
  • 1.13, Аноним (13), 15:42, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Мои DNS-запросы должна отправлять ось. Кстати вопрос: и как теперь отличить https-траффик от dns-over-https, чтобы порезать его у себя (превентивненько)?
     
     
  • 2.14, Аноним (13), 15:43, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    P.S. Да собственно о чём это я. Итак всё понятно. Инторнет зарулен.
     
  • 2.17, zzz (??), 16:21, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ну что ты, глупенький. Конечно же, ОС ничем рулить не должна - она обновляются слишком медленно, у корпораций добра на это нет времени, сляпали на коленке новую фичу, уяк-уяк - и в продакшн!
     
  • 2.20, Аноним (18), 16:44, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Пока старый вариант DNS протокола поддерживается ещё остаётся возможность поменять конфигурацию клиента или пересобрать его, исправив в крайнем случае.
     
  • 2.29, Аноним (13), 17:45, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    s/у себя/у себя на локалхосте/
    конечно же
     
  • 2.41, AnonPlus (?), 20:33, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А никак. Оно для этого и создавалось, чтобы местные любители обнюхивать трафик (читай "провайдеры" и "локальный сисьадмины, возомнившие себя божками") убрали свои ручонки от трафика абонентов.
     
     
  • 3.55, cloudflare (?), 10:06, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    да, да, это НАШИ эмм... абоненты, и МЫ их траффик будем нюхать, а так же хранить себе на память.

    но вы продолжайте распространять слухи о провайдерах и локальных сисадминах, которым, конечно же, делать нечего, как смотреть на что вы там др..те в рабочее время, пусть больше лохов ведется.

     
     
  • 4.64, AnonPlus (?), 17:49, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, ну да. И рекламу в HTTPS-трафик провайдеры не суют. Вообще трафик их не интересует, делать им нечего больше.

    Билайн на этом ловили пару лет назад. Сегодня поймали Мегафон. И Йота вообще не режет неопознанный трафик. Всё это выдумки. Продолжайте игнорировать реальность.

     

  • 1.24, Аноним (24), 17:20, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Четвёртый этап тестирования DNS-over-HTTPS в Cloudflare

    Пофиксил заголовок

     
  • 1.25, Аноним (25), 17:35, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда уже будет http-over-dns-over-http-over-ssh
     
     
  • 2.30, Ретроград (?), 18:00, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > http over dns

    Уже есть, Iodine называется.

    > dns over http

    Собственно сабж

    > http over ssh

    Туннель настраивается на раз-два.

    Предлагаю тебе все это объединить и отписаться о результатах.

     
     
  • 3.69, Аноним (25), 23:38, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это и без всяких имплементация понятно что плохая затея. Я от недовольства задал вопрос. Не пойму логику сегодняшних разрабов: пропустить все через HTTP.
     

  • 1.31, Аноним (31), 18:33, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > DNS-сервер CloudFlare
    > CloudFlare

    Спасибо, ненужно. Как-нибудь dnscrypt обойдемся. Оно хотя бы позволяет выбрать, заруливать запросы на свой/доверенный сервер или сливать корпорастам/шпионам из списка.

     
     
  • 2.34, Оффтоп (?), 19:19, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Как-нибудь dnscrypt обойдемся

    кстати об этом. Не подскажите хорошего гайда по установке-настройке на ноут с системдой(манжара), нетворкманагером и dnsmasq?
    По гайду с рачевики застрял - там пишут убрать все с 53 порта, а на нем висит pid 1 и отказывается уходить

     
     
  • 3.36, comodo (?), 20:10, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Systemd-resolvd?
     
     
  • 4.44, Оффтоп (?), 22:52, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    скорее всего. Отключить не вышло, ибо после перезагрузки спавнилось обратно
     
  • 2.38, COBA (?), 20:20, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А кто здесь мешает прописать собственный сервер. Там ответ идёт обычным джейсоном. В браузере можно свободно поставить свой сервер. Хттпс от работает стандартный сертификат.
    В чем вопрос?
     
  • 2.39, AnonPlus (?), 20:20, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    DNSCrypt провайдеру легче заблокировать (если говорить о публичнх серверах). Адреса серверов хорошо известны (любезно лежат прямо в репозитории). Адреса эти редко меняются (чтобы клиентам не приходилось думать об обновлении этого списка на своей стороне).

    Вдобавок, у меня есть подозрение, что и детектить трафик DNSCrypt тоже гораздо проще, чем DoT.

    Прчему провайдер может блокировать DNSCrypt? Ну, например, некоторые провайдеры в РФ уже сейчас заворачивают нешифрованный DNS-трафик на себя по рекомендациям Роскомнадзора. Поступит рекомендация резать DNSCrypt - будут резать при условии, что это легко.

    Вдобавок, в прошлом месяце проскочила инфа о совершенно волшебном "кейсе": выездная проверка РКН прибыла в какое-то кафе (они периодически мониторят публичные заведения с целью проверки "а блокируется ли тут у вас доступ к сайту Навального и прочему нехорошему контенту"). Небольшой провайдер, который предоставлял этому кафе доступ в интернет, надеялся на то, что клиенты адекватные и запрещёнку блокировал исключительно принудительным перехватом DNS-запросов. Владелец кафе на своём оборудовании настроил то ли DNSCrypt, то ли DoT. Короче, сделал клиентам интернеты без блокировок. В итоге, вы будете ржать, но штраф выписали провайдеру (да, в РКН умные люди нн работают) Чем дело кончилось, не щнаю, но сисадмин провайдера, который всё это и поведал миру, задумался о более жёстких способах вмешательства в пользовательский трафик.

     
     
  • 3.45, Дон Ягон (?), 22:57, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > DNSCrypt провайдеру легче заблокировать (если говорить о публичнх серверах).

    А адреса cloudflare dns и прочих популярных публичных DoH провайдеров чем-то сложнее будет заблокировать, лол?

    > Вдобавок, у меня есть подозрение, что и детектить трафик DNSCrypt тоже гораздо проще, чем DoT.

    Почему? По-логике - без разницы. Вот отличить DoH от обычного HTTPS невозможно, да. Только, кажется, проблем от этого только больше.

    > вы будете ржать, но штраф выписали провайдеру

    А кому блин надо было выписывать? Владельцу кафе? Так кафе - это деятельность РКНу неподотчётная, я так полагаю. Они, ЕМНИП, приходят только к тем, у кого есть лицензия на оказание услуг связи. И карает лишением оной, если тот, к кому они пришли, послал их по известному адресу. У кафе, очевидно, подобной лицензии нет и следовательно нет и нарушения законов.
    У владельца кафе по закону даже списка "запрещённых сайтов" быть не может, т.е. он, в теории, даже не знает, что должно работать, а что нет.
    Да и косяк так или иначе провайдерский, и на что он там понадеялся - исключительно его, провайдера, половые сложности. И по закону, и по совести.

    А вообще мне жаль, что РКН работает так на от...сь. Работал бы нормально, пришлось бы всем пользоваться нормальными цензуро-устойчивыми решениями, пришлось бы пилить да развивать их и вообще был бы движ. А так - скукота, нажал галочку в бровзере и всё, ты какир. Тьфу.

     
     
  • 4.56, cloudflare (?), 10:07, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вот отличить DoH от обычного HTTPS невозможно, да.

    главное, верьте!

     
     
  • 5.61, Дон Ягон (?), 14:14, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вот отличить DoH от обычного HTTPS невозможно, да.
    > главное, верьте!

    Cloudflare как минимум сможет, да. Но на мой взгляд нет причин использовать DoH как с cloudflare, так и без, так что...

     
  • 4.63, AnonPlus (?), 17:47, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А адреса cloudflare dns и прочих популярных публичных DoH провайдеров чем-то сложнее
    > будет заблокировать, лол?

    Прикинь, да. У РКН уже много лет основная мантра "нам не нужны стрессы". Массова блокировка CF (а не как сейчас по полторая адреса в сутки) создаст стрессы. Так что, сложнее, кек.

    > А кому блин надо было выписывать?

    По твоей логике, если владелец кафе настроил OpenVPN и пустил весь трафик через туннель, тоже надо провайдера штрафовать? А если я тебя обматерю кириллическими буквами, то ты Мефодию морду бить пойдешь?

     
     
  • 5.65, Дон Ягон (?), 18:11, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Прикинь, да. У РКН уже много лет основная мантра "нам не нужны стрессы". Массова блокировка CF (а не как сейчас по полторая адреса в сутки) создаст стрессы. Так что, сложнее, кек.

    Чушь от первого до последнего слова. Забанят сразу подсетью, как делали при попытках забанить телеграм и даже не почешутся. Но вы продолжайте верить, что банить публичные адреса популярных Dnscrypt провайдеров проще, чем какие либо другие публичные адреса.

    > По твоей логике, если владелец кафе настроил OpenVPN и пустил весь трафик через туннель, тоже надо провайдера штрафовать? А если я тебя обматерю кириллическими буквами, то ты Мефодию морду бить пойдешь?

    Это не моя логика, это законодательство. И, к слову, в этом месте абсолютно последовательное, в отличие от тебя; ты же просто передёргиваешь.
    Провайдер предоставляет услуги связи - ему и отвечать за несоответствие услуг требованиям государства. После получения втыка от РКН провайдер может, например, отключить кафе от своих услуг - но только так. Кафе и аналогичное РКН не подотчётны.
    И продолжая твою нелепую аналогию: вне зависимости от того, обматеришь ты меня при личной встрече или по telegram, я пойду "бить морду" тебе, а не дурову. Ферштейн?

     

  • 1.37, Аноним (37), 20:11, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Rkn сасай.
     
     
  • 2.40, AnonPlus (?), 20:27, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот используешь ты DoT как клиент у тебя сертифкат в конфиге прописан? :) Ну вот по умолчанию мало у кого прописан, а если не прописан - то ничто не мешает провайдеру завернуть это дело на себя.

    С Encrypted SNI ещё смешнее - достаточно заворачивать на себя DNS и блокировать запрос eSNI из DNS. После чего браузер клиента откатывается к обычному нешифрованному SNI.

     
  • 2.43, Аноним (28), 22:19, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Прочитал в начале как "Rkn спасай"
     
     
  • 3.57, пох (?), 10:07, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    тут уже к Росатому взывать надо, а не к РКН.
     

  • 1.42, Аноним (42), 22:12, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Никто не расскажет, как включить это дерьмо в  Ubuntu правильным способом - через SystemD?
     
     
  • 2.46, Дон Ягон (?), 23:07, 03/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Никто не расскажет, как включить это дерьмо в  Ubuntu правильным способом - через SystemD?

    Конечно расскажу!
    systemctl enable this-shit-in-ubuntu.service && systemctl start this-shit-in-ubuntu.service
    Не благодари!

     

  • 1.48, Аноним (47), 23:45, 03/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    HTTP(S) стал еще одним уровнем в стеке протоколов Интернета, поверх которого уже работают разные прикладные протоколы (которые теперь почему-то принято называть "Web API"). Только вот в чем смысл этого уровня? Ему можно хотя бы дать название, чтобы было понятно, за что он отвечает?
     
     
  • 2.49, Дон Ягон (?), 00:07, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С точки зрения "стека протоколов интернета", что бы это ни значило, DoH просто не существует. Браузер получает данные о хоснэймах, делая запросы по https вкудато вместо того, чтобы брать эти данные у резолвера.
    Вне браузера DoH - это рак мозга даже с точки зрения его обсаженных создателей.
     
     
  • 3.58, Поцтеринг (?), 10:08, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я уже пилю нужный неотключаемый патч к systemd-resolved! Через пять минут закоммичу, подождите чуток!

     

  • 1.50, Рустам (?), 00:24, 04/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    >Как и раньше в качестве основного будет использован DNS-сервер CloudFlare

    DoH и DoT это конечно восхитительно, но почему именно CloudFlare, не безопасно ведь, PandoraBox так сказать. Лучше Google тем более сервера скоро физически будут размещены на территории Нашей Страны и за безопасность своих данных можно не беспокоится или Отечественный Яндекс вообще было бы прекрасно. Лично я не хочу делить конфиденциальные данные с АНБ!

     
     
  • 2.51, Эльдар (??), 02:09, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Полностью с Вами согласен, Яндекс был бы весьма кстатьи. Интересно Яндекс DNS уже поддерживает DoH, не знаете?
     

  • 1.53, Аноним (53), 07:07, 04/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нужен способ указать исключения для DNS-over-HTTPS, чтобы локальные адреса разрешались нормально. Cloudfare про них, разумеется, не знает.
     
     
  • 2.59, cloudflare (?), 10:10, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    теперь - знаем. И поделимся знанием, если попросят.

    (а fallback в браузере и так есть - только он сначала нам сливает, а уже потом остальное делает)

     

  • 1.60, Аноним (60), 13:48, 04/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вещь нужная. Некоторые используют DNSCrypt. Но использовать CloudFlare однозначно не буду. Услуги последнего весьма и весьма сомнительны.
     
  • 1.62, Аноним (62), 17:38, 04/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Забавно, что включение режима "3" просто делает браузер неработоспособным из-за невозможности разрешения имен. Потому что в network.trr.uri стоит "https://mozilla.cloudflare-dns.com/dns-query". Установка "https://9.9.9.9/dns-query" проблему решает.

    Так они слона не продадут.

     
     
  • 2.66, Аноним (-), 18:42, 04/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Забыл в какой тоталитарной стране жив^W выживаешь?
    https://www.opennet.dev/tips/3086_esni_doh_dns_https.shtml#15
     

  • 1.67, Ivan_83 (ok), 21:25, 04/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Очередная ненужно крипто, чтобы АНБ всё знало обо всех реалтайм.
     
  • 1.75, Олег (??), 11:09, 07/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так, народ, это /etc/hosts теперь для отладки не катит?
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру