Разработчики Mozilla анонсировали (https://blog.mozilla.org/futurereleases/2018/11/27/next-step.../) третий этап тестирования функции обращения к DNS поверх HTTPS (DoH, DNS over HTTPS), на котором небольшой части пользователей Firefox из США будет предложено активировать DoH и принять участие в тестировании (при нежелании пользователь сможет отказаться). Если первые два этапа тестирования проводились на пользователях ночных сборок и бета-выпусков, то на третьем этапа DoH будет предложен пользователям релизов.
Отмечается, что первые два этапа тестирования продемонстрировали неплохие показатели ускорения при работе через медленные каналы связи. У пользователей с высокоскоростным доступом к сети отмечалось замедление на уровне 6 миллисекунд, которое признано несущественным и незаметным в процессе работы. Если первые два этапа измеряли производительность непосредственно операций с DNS, то на третьем этапе планируется оценить общую картину, учитывающую и время загрузки тестовой страницы. Раз в сутки браузер будет измерять скорость загрузки специальной тестовой страницы, что позволит оценить влияние локализации обращений к DNS через сети доставки контента.Для включения 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/".
Напомним, что DoH может оказаться полезным для исключения утечек сведений о запрашиваемых именах хостов через DNS-серверы провайдеров, борьбы с MITM-атаками и подменой DNS-трафика, противостояния блокировкам на уровне DNS или для организации работы в случае невозможности прямого обращения к DNS-серверам (например, при работе через прокси). Если в обычной ситуации DNS-запросы напрямую отправляются на определённые в конфигурации системы DNS-серверы, то в случае DoH запрос на определение IP-адреса хоста инкапсулируется в трафик HTTPS и отправляется на HTTP-сервер, на котором резолвер обрабатывает запросы через Web API. Существующий стандарт DNSSEC использует шифрование лишь для аутентификации клиента и сервера, но не защищает трафик от перехвата и не гарантирует конфиденциальность запросов.URL: https://blog.mozilla.org/futurereleases/2018/11/27/next-step.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=49673
Да годная, годная штука. Только у меня почему-то ряд адресов в режиме только DoH не резолвится...
Я х.з. как это работает, но наверное нужна поддержка этой технологии и со стороны самого DNS-сервера. И эта поддержка, скорее всего, пока ещё есть далеко не везде.
Поддержка необязательна.
Нет, не годная.
https://youtu.be/OxFFTxJv1L4?t=2627
Всё что я увидел в вашем видео по таймкоду это:
>Ты то куда лезешь χ¥€¢Ø￠№₳ из нижнего интернета
>Мы тут все крутые DNS мужыки, а ты просто HTTP-школьник-неудачник поверивший сказочкнику Сноудену бла бла блаИ всё что он сказал про DoH неправда. Я уже пощупал эту штуку в фирефоксе и могу сказать что HTTPS до дефолтого сервера не закрывается через две минуты, а продолжает висеть и висеть. А если бы даже и закрывалось то что? Его-то какое дело? Мало ли реализаций DoH есть и ещё появится? Может я наоборот хочу чтобы закрывалось?
Что ещё он сказал? Ах, да, кажется, что-то про то, что DoH не поддерживает асинхронные ответы - и это тоже не правда. По крайней мере ответы ipv6 и ipv4 могут приходить независимо, об этом даже настройка соответствующая есть...Короче батхертит он знатно. Я хоть и признаю Калловый-флейр ещё большей червем-корпорацией, чем даже Гугл, но этого слушать этого поехавшего больше не смог...
И 500 просмотров у видео... Жаль поздно заметил.
Мужик не убедителен. Выше уже отметили другие вещи (чувствуется, что его бесит, что какие-то веб-макаки взяли и сделали шифрование днс прямо здесь и сейчас, а крутые днс-мужики сидят на жопе ровно, обесценивают проблему (даже в случае хвалимого им dns over tls, видно что он намекает на не особую нужность шифрования днс и не собирался шевелить пальцем) и успеют только через 10 лет со своей реализацией), затрону одну. Проблема локальных доменов не проблема. Есть старый https://tools.ietf.org/html/rfc2606 в котором указано 4 зарезервированных tld. Нет никакой проблемы для браузера автоматически не резолвить их через DoH, а спрашивать систему. И это уже так: https://daniel.haxx.se/blog/2018/06/03/inside-firefoxs-doh-e.../
> Additionally, "localhost" and all names in the ".local" TLD are sort of hard-coded as blacklisted and will never be resolved with TRR. (Unless you run TRR-only...)Если только вы не профнепригодный, как те что брали .dev tld, который никогда не обозначался зарезервированным для локальных/девелоперских нужд (ну и что? зато красиво, берём!), и когда гугл покупает эту зону и невозбранно форсит на ней HSTS, они получили невозможность открывать свои красивые локальные домены в современных браузерах по http, которую заслужили.
Более того, в его примере с сетью в его доме, если придёт гость с ноутбуком/смартфоном, где захардкожен гуглднс, то автоматически у него тоже не будет работать локальный домен. Устройство гостя проигнорирует dns-сервер, который выплюнуло DHCP его локалки, и продолжит использовать гугл. При чём тут шифрование, казалось бы? Видимо при том, что с открытым днс у него всё равно остаётся возможность наплевать на настройки гостя и забрать его днс-запросы себе, ответить от имени гугла, а устройства гостя и не заметят ничего. Видимо он рад такой возможности, упоминал же что любит контроль и пугает ботнетами. Только почему нас должны волновать его желания?
Пожалуй, единственное, в чем он прав, так это в том, что сейчас DOH живёт в браузере, а не в системном резолвере, что может быть хорошо только при использовании доверенного браузера во враждебной ОС. А это само по себе уже плохая идея.
Да, никто не отрицает, что это не совсем правильно и в идеале надо это делать в ОС. Но это ведь не самоцель. Просто ОСи будут долго внедрять, скорее всего. И даже внедрив, пользователи будут долго обновляться на новые версии ОСей (привет win7-8, старым андроидам). А у браузера есть возможность внедрить это прямо сейчас и пользователи обновятся сразу. Плюс, цитируя https://dnscrypt.info/faq/ по поводу DNS over TLS:
> Difficult to implement securely. Validating TLS certificates in non-browser software is the most dangerous code in the world https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-...А в браузерах эта часть годами отполирована и нигде не сделано лучше среди клиентской части.
И те домены, которые желательно скрыть, чаще резолвятся именно для браузера, а не другого софта.
По этим причинам мы и видим это в браузере. Когда-нибудь это станет не нужно, но сейчас полезно и не мешает внедрению шифрования в ОСи.
Когда ещё только завели эту фичу, у меня ни один сайт не открывался с DoH. Больше не тестил.
Ну, теперь будет только один источник цензуры - удостоверяющий центр. Только один, зато на всех. Этож лучше "товарищ майор" - далеко и ему совершенно нет до тебя дела, да? ;)
"Когда вы говорите, такое впечатление, что вы бредите" - Шурик.
"Сейчас к людям надо помягше. А на вопросы смотреть ширше."
Друг шурика
Друг-ли?..
ну чего это "только один"? Сколько надо, столько и будет.А "удостоверяющий центр" может быть и впрямь один - это ж гугль, если мы правильно попросим - подпишет чего надо. Они вообще с удовольствием с нами сотрудничают. И с "ними" тоже, конечно, но мы в данном случае - не конкурируем, а тоже сотрудничаем.
"Сколько надо, столько и будет."А в том то и дело, товарищ майор, что "достаточно только одной таблетки".
Так что от такого сотрудничества ожидать можно разве что слияния органов если не сказать совокупления...
Как бы помягчьте сказать ... DNS юзает не только браузер.
Да. Что сказать то хотели?
1. Основная часть конфиденциальных днс-запросов это именно браузер. Резолвы клиента стима сильно хочется шифровать?
2. ОСям никто не мешает реализовывать нативную поддержку. Вон, последний андроид уже умеет. Но ждать люди будут 10 лет. Независимо от того, что будет делать мозилла.
3. Что тебе не нравится и что ты хочешь от мозиллы в этом плане?
Вот именно в случае браузера DoH добавляет мало конфиденциальности: имена видны в самих https запросах.
Ты не пробовал подумать на 1 шаг вперёд? Или хотя бы логику включить?
Смотри, на данный момент (условно) мы имеем два слива: DNS и SNI. И ты тут такой говоришь, что какой смысл фиксить x, если остался y. Или какой смысл фиксить y, если остался x. Это смешно, лол. Внедрять надо оба, в любом порядке. И именно это делается. ESNI уже тоже есть и работает.
Более того, зырнуть в открытый днс попросту технически легче, чем в сертификат сервера (в TLS 1.2, в 1.3 он уже шифрован) или нешифрованный SNI. Так что даже если бы ESNI ещё не был готов к стандартизации, шифрование dns уже лучше чем ничего.
иксперды опеннета такие иксперды...sni отправляет имя твоего порноресурса открытым текстом без всякой ненужной сложности, "посмотреть" на него может почти любой васян, освоивший вайршкварк (я бы сказал 'любой', но вот ты, как выясняется, не можешь, бредишь какими-то сертификатами сервера), но есть один ньюанс - он должен как-то уметь перехватить твой траффик.
(причем эта технология a) вредная b) ненужная c) стоило бы внимательно посмотреть, что за люди вообще ее пропихнули в стандарты, и, на всякий случай, проверить что они еще понапропихивали.)
но вместо этого мы будем городить dns-over-tls чтоб никто не догадался, кому именно принадлежат те dns-прокси и зачем их владельцы пошли на такие затраты.
наивные детишки вроде тебя будут счастливы слить помимо васяна еще и клаудфлейру все свои секретики. Причем васян-то существует только в их фантазии, зато клаудфлейр существует вполне себе в материальном мире.
> Причем васян-то существует только в их фантазии, зато клаудфлейр существует вполне себе в материальном мире.А по-твоему, других провайдеров кроме Cloudflare не существует?
для типового опеннетчика - нет, не существует. Для сильно продвинутого - ну да, еще же и гугль ;-)Мы ведь все еще о людях, которым зачем-то хочется сливать свою информацию целенаправленно в бездонные bigdataхренилища, а не случайному мимокрокодилу (которому меньше всего, пожалуй, интересны имена сайтов)?
У тех кого на самом деле волнуют такие вещи-то, давно, полагаю, настроен криптотуннель подальше от товарищмайоров, без всяких модных openрешет, встроенных в браузер. Но вот они-то могут теперь лохануться, забыв отключить стопиццотую "очень полезную фичу", ага.
Вот выпилить sni - задача куда посложнее, в современных браузерах она решения, imho, не имеет (поскольку они давно разучились модальным диалогам, и им просто негде будет переспрашивать подтверждения)
> Мы ведь все еще о людях, которым зачем-то хочется сливать свою информацию целенаправленно в бездонные bigdataхренилищаА разве эти люди не сливают её сейчас все тем же Google и Cloudflare? Так хоть будут сливать исключительно им, если eSNI таки получит распространение.
> А разве эти люди не сливают её сейчас все тем же Google и Cloudflare?ну, очевидно же, не в полном объеме - особенно cloudflare, которая на этом рынке догоняющая.
> Так хоть будут сливать исключительно им, если eSNI таки получит распространение.
на _их_ серверах - безусловно получит. другим не должно достаться нахаляву то, за что тут уполчено.
поинт-то в другом, если кто не заметил - sni технология ненужная и вредная в принципе, ни один уважающий себя сервис на нее не полагается, а наличие на другой стороне не того сертификата должно вызывать как минимум нежелание отдавать ей данные карты, поскольку даже если он честный - данные очевидно доступны третьим лицам.
esni, всунутый по самые гланды в принудительном порядке, лишит вас даже теоретической возможности это вовремя заметить.
Ростелеком, например, корпорация, а не мимикрокодил. П
ростелекому твои котики даром не нужны.
CleanBrowsing ещё)
https://cleanbrowsing.org/dnsoverhttps
Таки погугли ESNI
твой esni - это точно такой же оверинжиниренный ненужно-мусор, как и doh.sni ненужен. Ни e, ни обычный.
Нужно выводить предупреждение каждый раз, как в ответ вместо сертификата запрошенного сервера вылезло мурло клаудфлари.но современные мартышки, др...щие на модные фишки, во-первых, на такие сложные изменения неспособны, во-вторых все равно не поймут.
Согласен со всеми вашими предыдущими мыслями, но не с этим: "sni ненужен. Ни e, ни обычный."
Без SNI на каждый сайт надо будет иметь или выделенный IP или хостать его на другигих портах в случае исползования SSL, что не есть практично (и не экономично). С SNI на одном ипишнике можно навешать кучу веб сайтов и у каждого будет свой собственный SSL сертификат
Никто не сомневается, что sni полезен хостерам, но параноик вроде предыдущего оратора вполне может пожертвовать доступом к таким сайтам ради своей иллюзорной приватности в общественном туа^Wинтернете
> Никто не сомневается, что sni полезен хостерам, но параноик вроде предыдущего оратора вполне
> может пожертвовать доступом к таким сайтама я не хожу по "таким" сайтам. А на сайте, где ssl - ради удовлетворения гуглошантажистов - нажму ok, понимая, что никакой безопасностью тут и не пахнет.
Сайт рашкованского "интернет-магазина" накормлю именем иван петров и мобилой специально для таких - все равно они кредитные карты ниасилили (если и асилили - через платежную прокладку, у которой все в порядке, и на ее серверах никого левого нет,данные карт тырят только честные люди, ее сотрудники), и будут "перезванивать", по другому работать не умеют. А вот продать твой номер или проиметь его спаммерам - умеют.
> Без SNI на каждый сайт надо будет иметь или выделенный IPда. На каждый сайт, где шифрование - по делу, а не в попытках удовлетворить гугля.
Потому что иначе, повторяю, твой ssl превращается в тыкву.ну то есть можно и не иметь - в предположении что у тебя есть браузер доисторической эпохи, умеющий внятно, на человеческом языке вывести предупреждение. И дальше ты уже глазами смотришь - кто там живет, и думаешь. зачем он вместо того за кем ты пришел.
> С SNI на одном ипишнике можно навешать кучу веб сайтов и у каждого будет свой собственный SSL
> сертификаттолько смысла в этом не будет никакого.
ну кроме прямого обмана пользователя - в свойствах "эта страница защищена шифрованием, сертификат принадлежит уважаемая-компания", а на практике - он слит клаудфлейру, и все твое шифрование кончается на их проксилке. Что, подчеркиваю, не факт что плохо. но хотелось бы об этом знать заранее.
В итоге без SNI адрес сайта к которому твой браузер обращается определяется тривиально - нужно просто установить соединение и посмотреть какой сертификат отправил сервер. А блокировать сайты без sni вообще отлично.
> В итоге без SNI адрес сайта к которому твой браузер обращается определяется
> тривиально - нужно просто установить соединение и посмотреть какой сертификат отправил
> сервер.так cloudflare же ж! ;-)
сессия останется зашифрованной. просто пользователь будет в курсе, что его не видит товарищ майор, зато видят те, кто вполне могут продать товарищ-майору.
что ж в этом неправильного-то?
А там где security is the issue - так там в любом случае не может быть никакого sni. sni не средство обхода блокировок, это средство улпрощения слежки.
> а на практике - он слит клаудфлейруНо ведь SNI использует не только cloudflare.
Есть огромная куча дешёвых shared-хостингов, где можно прикрутить TLS и не раскошеливаться на отдельные IP.
> Но ведь SNI использует не только cloudflare.естественно
> Есть огромная куча дешёвых shared-хостингов, где можно прикрутить TLS и
> не раскошеливаться на отдельные IP.именно - и превратить твою секьюрить в тыкву может уже не только cloudflare, которая все же данные крединых карт воровать вряд ли станет, у них другие цели и, скорее всего, они не намерены делиться со своими индусскими сотрудниками, а и грошовый админ урюпинского шаредхостера, и соседний по шареду васян, ломанувший тот хостинг.
или даже не ломанувший, а просто данные кредиток лежат в файлике creditcards.txt с пермишнами 777 (они где-то прочитали что это самые надежные, точно все будет работать), или пароль от базы с ними где-то в таком же config.php, и дамп ее рядышком лежит.
а если там вся секьюрить только ради шантаж гугля удовлетворить - то и пофиг тебе, что сертификат вылезет шаредхостера - при условии что ты умеешь это прочитать и понять, а не пустая страница-полная-неведомой-фигни, как это сейчас принято, без кнопки "продолжить".
то есть работа браузеров без этой ненужно-фичи намеренно и очень основательно сломана лет семь назад, ты не можешь ее отключить никакими силами.
>> Без SNI на каждый сайт надо будет иметь или выделенный IP
> да. На каждый сайт, где шифрование - по делу, а не в
> попытках удовлетворить гугля.
> Потому что иначе, повторяю, твой ssl превращается в тыкву.SSL шифрование в тыкву не превращется (если конечно сисадин не подсадил в браузер свой доверенный рут сертификат и декодирует все на файрволе).
Гугл под видом того что он волнуется за приватность и так давно удовлетворен без SNI, любой выданный сертификат на (суб)домен находится у них в certificate transparency database доступный кстати кому попало. Кстати привязка SSL только к однлму ИП идентифицирует значительно лучше, чем если на одном ИП навешенно куча SSL хостов
>> С SNI на одном ипишнике можно навешать кучу веб сайтов и у каждого будет свой собственный SSL
>> сертификат
> только смысла в этом не будет никакого.Как это не будет ? Выделенный ИПшник стоит не так уж и дешево, от $3-15/month (если конечно не брать обезличиные /32 на дедиках и ВПС-ах где можно за 3 бакса отмазаться разово, но при этом свято доверять что в клаудном серваке никто не лазит со стороны хостера), а для любого нормального домена надо как миниум 3 сертификата, на сайт, на емэил сервак, на веб мэил сидящем в субдомене
SNI в открытом виде конечно не впечетляет, поэтому и придумали ESNI чтоб упрятать хост внутри шифрования, но опять же, OSCP со стороны браузеров не избежать...
>>> С SNI на одном ипишнике можно навешать кучу веб сайтов и у каждого будет свой собственный SSL
>>> сертификат
>> только смысла в этом не будет никакого.
> Как это не будет ? Выделенный ИПшник стоит не так уж ибанально - раз на одном ip живет куча сайтов с разными сертификатами вместо wildcard/altnames - либо оно там где-то дешифруется на прокси, либо... правильно, shared hosting, и число могущих стырить твои данные уже после дешифровки становится неограничено.
> дешево, от $3-15/month (если конечно не брать обезличиные /32 на дедиках
у меня <$1, что я делаю не так? Необезличенный с отметкой в райпе еще дешевле, но там, понятно, от /28, не надо мне столько на один ящик, дохлые они у меня, а распределять их нельзя.
> и ВПС-ах где можно за 3 бакса отмазаться разово, но при
> этом свято доверять что в клаудном серваке никто не лазит со
> стороны хостера), а для любого нормального домена надо как миниум 3я вот побыл тут надысь тем хостером - понадобилось при смене работы забрать все нажитое непосильным трудом. И знаешь, доложу тебе - непростая это затея, залезть внутрь виртуалки не под распрекрасным лин-oops. То есть она вообще общего решения не имеет, а уж беспалевного - так и вовсе не.
Ну можно, конечно, бэкап-софтом воспользоваться, через специфический api утащить образы дисков - но тебе понадобится овердофига места (потому что чтобы порыться, образ таки надо иметь в развернутом виде) и овердофига времени и пропускной способности, если ты не за конкретным клиентом приходил, а пытаешься шпионить за всеми (и обломаться об encfs). И да, у этого хостера на дешевом тарифе бэкапы ни разу не предусмотрены, и san тоже - по-моему, я могу спать совершенно спокойно, пока не торгую наркотиками крупным оптом и ядерным оружием с доставкой баллистической ракетой.
> сертификата, на сайт, на емэил сервак, на веб мэил сидящем в
> субдоменевообще-то для этого достаточно одного, а email-серваку вообще не нужен (к счастию великому, гугль еще не контролирует весь почтовый софт).
> SNI в открытом виде конечно не впечетляет, поэтому и придумали ESNI чтоб
с опозданием на десять лет, ага. Причем надо было, вместо этого, придумать пересогласование протокола с новым сертификатом, апи для этого по сути уже был - вместо этого его как раз срочно выпилили под кудахтанье "это небезопасТно, вдруг там сервер настраивали враги" (кого при этом еще волнует безопасность соединения с таким?), и вместо мелкого исправления впилили громадную, уродливую, неверифицируемую хрень.
> упрятать хост внутри шифрования, но опять же, OSCP со стороны браузеров
> не избежать...выключаешь - и избежать. Ну и да - за этот "сервис" тоже скажи спасибо мурзилоглю, которые заявили что скачивать всякие черные списки и телеметрию отправлять - это ничего, а вот crl это долго, медленно, не приносит гуглю данных о посещаемом сервере, и его надо срочно выпилить.
>банально - раз на одном ip живет куча сайтов с разными сертификатами вместо
> wildcard/altnames - либо оно там где-то дешифруется на прокси, либо... правильно,
> shared hosting, и число могущих стырить твои данные уже после дешифровки становится неограничено.Я имел ввиду нормальные сертификаты, а не all-in-one, wildcard не работает на всех клиентах, и каждому сервису не shared сертификат, очень однако большая разница....
> у меня <$1,
Завидую белой завистью...
> И знаешь, доложу тебе - непростая это затея, залезть внутрь виртуалки не под распрекрасным лин-oops. То есть она вообще общего решения не имеет, а уж беспалевного - так и вовсе не.
Я имел ввиду имено хостера у которого есть официальное право шманать виртуалки, легально а не хаки со стороны работников и пршмонать конкретную виртуалку не такая уж и проблема, тем более что не надо никуда и нечего перекачивать, а локальненько...
> ообще-то для этого достаточно одного, а email-серваку вообще не нужен SSL
Класс, т.е. боремся за приватность, но вот трафик между серваками пусть смотрят, так что ли?
>> упрятать хост внутри шифрования, но опять же, OSCP со стороны браузеров
>> не избежать...
>выключаешь - и избежать. Ну и да - за этот "сервис" тоже скажи спасибо мурзилоглюДа, блин, я не говорю о себе и тех кто может это сделать, а в глобальном плане...
> Я имел ввиду нормальные сертификаты, а не all-in-one, wildcard не работает начто неправильного в сертификате *.mycompany.com и тем более www.mycompany.com /alt:mycompany.com server.mycompany.com etc (а для very-secure-server.mycompany.com - отдельный на отдельном ip)?
> всех клиентах, и каждому сервису не shared сертификат, очень однако большая
лолшта? widcard и alt работает в этой вот мазиле 3.6 - которая понятия не имеет ни о каком sni. Ну, правда, да, а где теперь взять wildcard, если ты не очень большой банк? Да и altnames недешевы и продаются поштучно. Постарался гугель, на славу, все кто мешал тырить траффик, уничтожены.
>> у меня <$1,
> Завидую белой завистью...aruba за 2евро/мес тебе с адресом еще и vm завернет. Только thinprint читай внимательно, а то будут сюрпризы. ssd штука такая...
>> И знаешь, доложу тебе - непростая это затея, залезть внутрь виртуалки не под распрекрасным
>> лин-oops. То есть она вообще общего решения не имеет, а уж беспалевного - так и вовсе не.
> Я имел ввиду имено хостера у которого есть официальное право шманать виртуалки,блин. я сам себе хостер, машину отбирают, клиент уезжает, официальное право есть, времени мало. И вот чо делать? Доступ непосредственно внутрь vmdk в вмвари ни разу не предусмотрен.
Скопировать можно - по сети, мээээдлэээнно - команда mount чтобы просто подключить внешний диск или хранилку - тоже ни разу не предусмотрена.
Можно подключить внешнее устройство через usb непосредственно к гостевой системе - это, по факту, оказался самый быстрый способ, но он требует перехвата контроля над гостевой системой - беспалевно этого не сделать.
(надо заметить, что у таких хостеров никакие пароли никуда не вводятся и перехватывать их бестолку - только открытые ключи ssh)> легально а не хаки со стороны работников и пршмонать конкретную виртуалку
> не такая уж и проблема, тем более что не надо никуда
> и нечего перекачивать, а локальненько...ну вот есть у тебя доступ, положим, к консоли виртуалки - и чо делать будииим? Пароля-то нет. Ребут? Вызовет вопросы у клиента, кто йта меня перезагружал - с проверкой целостности и т д. А что, если там что-то ценное, на ней нет шифрования хотя бы тем же encfs?
То есть сделать это массово - не получится, можно индивидуально для специальных клиентов, за которых очень попросят - но искать иголку в стоге сена тоже непросто и небыстро, поэтому, повторюсь, пока ты не торгуешь совсем крупными партиями хмурого и не распространяешь запрещенные вооружения - хрен тебя кто вообще подрядится искать.
>> ообще-то для этого достаточно одного, а email-серваку вообще не нужен SSL
> Класс, т.е. боремся за приватность, но вот трафик между серваками пусть смотрят,
> так что ли?траффик между серверами - пусть смотрят, там нет шибкоумных админчиков с манией величия и васянов, ломанувших свитч на чердаке. Накрайняк зашифруй самоподписанным, все равно никто его проверять не будет. Почта шифруется в клиенте, испокон веку - хошь pgp, именно для почты изначально и изобретенный, хошь s/mime, встроен в аутглюк, если она представляет собой хоть какую-то ценность, так что узнать в любом случае могут только from/to конверта.
>>выключаешь - и избежать. Ну и да - за этот "сервис" тоже скажи спасибо мурзилоглю
> Да, блин, я не говорю о себе и тех кто может это
> сделать, а в глобальном плане...а в глобальном плане жопа, о том, собственно, и вся эта новость :-(
под видом приобщения к шифрованию - подсунули глобальную слежку. В очередной раз. А ты за траффик между серверами паришься - да кому он вообще теперь будет нужен...
Васян-то может, и для него разницы нет, вайршарк открыть или что-то другое. А вот в масштабе провайдера просмотр SNI это уже deep packet inspection. И это не так просто для больших провайдеров (особенно), как может показаться, накладная и дорогая штука. Нельзя просто взять, и весь поток трафика через него пустить, они очень стараются экономить. Посмотри презентации Фила Кулина и других, сейчас шли и ещё будут пиринговые форумы и HighLoad++.
А днс трафик всяко проще смотрится и рулится. И когда есть/был выбор, он очевидно падает на днс, а не SNI.
> (я бы сказал 'любой', но вот ты, как выясняется, не можешь, бредишь какими-то сертификатами сервера)О, иксперд спалился. Ты не в курсах, что в tls 1.2 и ранее серверный сертфикат в serverhello тоже открыто передаётся, как и SNI в clienthello? И соответственно мог использоваться для детекта наравне со SNI тем же DPI (а в период до введения обязательного SNI основными браузерами мог быть даже основным). Ну молодец, мы запомним уровень твоих знаний, хорошо что ты залогинен.
> deep packet inspection. И это не так просто для больших провайдеровА у них что есть выбор?
Нарушители Конституции должны страдать.
> И ты тут такойТы читаешь что-то между строк и споришь с голосами в голове.
Я написал только, что написал.
Возможно, стоило добавить слово "Сейчас".
Сейчас, на рандомом сайте нет esni.
Насколько, с учётом этого, конфиденциальнее становится сёрфинг c doh-ом?
Доменные имена в https запросах видны? Ты что куришь?
SNI
ESNI. С разморозкой
Колюня, кинь статистику внедрения esni, ознакомимся.
Да, имя домена до SNI не шифровалось в HTTPS и шло в хендшейке SSL.Увы, SNI сейчас расширение и это скорее новинка и прикольная штука,
но нет гарантий, что она включена и работает.
> Да, имя домена до SNI не шифровалось в HTTPS и шло в
> хендшейке SSL.
> Увы, SNI сейчас расширение и это скорее новинка и прикольная штука,
> но нет гарантий, что она включена и работает.Да, опасно по tumblr лазить.
> нет гарантий, что она включена и работаетЕсть возможность проверить: https://www.cloudflare.com/ssl/encrypted-sni/
"Увы, SNI сейчас расширение и это скорее новинка и прикольная штука,"
Really???
Да не один шэринг хостинг без SNI не работает уже лет эдак 10...
Без SNI для SSL нужен отдельный ИП на каждый сертификат, а с SNI хоть сколь хошь на одном ИП и сразными сертификатами
> SNI сейчас расширение и это скорее новинка и прикольная штукКак там в 2005 году? SNI в IE с 2006, в Firefox с 2006, в Chrome с 2009(то есть с его бет).
Вылезай из криокамеры. SNI — стандарт, без него ты бы так и жил с 1 httpsным сайтом на 1 IPшнике.
Он просто путает термины. Замени в его посте SNI на ESNI и всё будет верно.
> Он просто путает термины. Замени в его посте SNI на ESNI и
> всё будет верно.Ну да. Мальчик-девочка, какая в дупу разница. Подумаешь SNI и ESNI, пофигу что SNI старше, чем он.
https://github.com/jedisct1/dnscrypt-proxy
Тебя спасет!
А он уже умеет и DoH, и DNSCrypt, и черта лысого верхом на метле.
> Основная часть конфиденциальных днс-запросов это именно браузерЭто еще зачем ?
> браузер будет измерять скорость загрузки специальной тестовой страницы, что позволит......держать на карандаше пользователя браузера.
> По умолчанию используется DNS-сервер CloudFlareТак вот чьи уши из-за кулис торчат.
> DoH может оказаться полезным для организации утечки сведений о запрашиваемых именах хостов через DoH-серверы провайдеров, обеспечения возможности MITM-атак и подмены DoH-трафика правильными организациями, организации блокировок на уровне DoH или для организации работы так, как это нужно владельцу DoH-сервера в случае невозможности прямого обращения к DNS-серверамМожете не благодарить.
>> По умолчанию используется DNS-сервер CloudFlare
> Так вот чьи уши из-за кулис торчат.Видимо, у гугла пока ушей на всех не хватает:
https://github.com/systemd/systemd/blob/master/meson_options...
> description : 'space-separated list of default DNS servers',
> value : '8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844')[...]
> option('ntp-servers', type : 'string',
> description : 'space-separated list of default NTP servers',
> value : 'time1.google.com time2.google.com time3.google.com time4.google.com')
>
Я так понимаю, что в данном случае, для использования липового сертификата спецслужбам не надо даже на канал врезаться - достаточно просто переписать А запись на "своем" ДНС?
А что в первый раз по указке спецслужб dns-ответы подменяются? Блокировка рутрекера вас ничему не научила?
Может для начала научится отделять гласное от негласного?
Интересно, а есть браузеры для корпоративного использования? Чтобы можно было запретить установку расширений и махинаций с ДНС? Очень полезная была бы штука.
IE. Там нельзя устанавливать расширения. Корпоративней некуда...
+1 и рулится политикой в AD
только MS рулилку ломает от версии к версии
> IE. Там нельзя устанавливать расширения.вы прослушали очередную порцию потока сознания типичного опеннетчика, не ведающего ничего за пределами родной бубунточки.
В IE вполне устанавливаются расширения. Но апи не на жабкоскрипте, поэтому число их было крайне ограничено даже в благословенные времена седьмой версии - не только лишь каждый васян может освоить C++ .
Т.е. линух не пригоден для корпоративного использования?
Закрывай все проксей и говори что корпорация в серой сети.
Internet Explorer
Firefox, там любой параметр фиксируется.
Любой опенсорсный броузер, в исходниках которого ты можешь выстричь возможность установки расширений, прибить гвоздями свой корпоративный DNS-сервер и свой корпоративный прокси, прописать один-единственный корневой сертификат своей организации, без возможности добавления новых, а заодно прописать URL веб-интерфейса корпоративной ERP/CRM как стартовый URL, убрав адресную строку и запретив открытие URL'ов "about:".
Дерзай.
хер с пальцем скрещивают лишь бы нормальную технологию не придумывать.
да они нормальную технологию придумали - только, в очередной раз, под видом заботы о несчастных лохах их собираются снова подоить.
Нажал плюс Вашему комменту, а засчиталось как минус. Поэтому напишу так - полностью поддерживаю.
Заодно еше разок скину - https://support.mozilla.org/en-US/kb/how-stop-firefox-making...
Я не могу понять тех нытиков, которым что-то не нравится в tls соединении до днс-резолвера. Что вы ноете? В чем суть ваших претензий? Что сервер собирает стату ваших запросов? Ну, так и обычные, абсолютно все текущие локальные провы могут и делают это. Так же как подменяют ответ, и сливает трафика на сорм. Что вам не нравится? Хотя подменять днс ответы не будут, хотя бы пров не сможет вести стату. Хотя бы такая польза.
>>Я не могу понять тех нытиковвы походу ничего не понимаете
>>Что вам не нравится?
выше в коменте написал, хер и палец разные вещи, разницу не ощущаете?
А какая технология нормальная? Децентрализованная? Технология ручной правки hosts?
Мир отрыт для новых технологий. Предлагайте.
>>Мир отрыт для новых технологий. Предлагайте.Если мир погряз в прошлом, будущее на этом не построишь. Обращаюсь к "старикам", направляйте "новичков" (привет Иванову :)) (будущее поколение), чтобы они создавали кардинально новые технологии, а не "скрещивали старье". Мир меняется, меняются требования, изучайте минусы/плюсы "прошлых" технологий, создавайте кардинально "новое" (новые идеи). При всем этом "скрещивании" вы думаете человек развивается? На сей день стандартный "новичек" даже не способен придумать банальный текстовый протокол.
пс: Удачи.
Что бы еще инкапсулировать в HTTPS? IP? Было... IEEE 802.3? Или тоже уже было?
Парни я действительно не пойму зачем всё это. Центр обработки данных у клод фларе есть в москве. Я так понимаю что это всеравно что в контакте чтото шифровать. А может я что непойму?
DoH = Spying mechanismПоследователи Цукерберга следующие его правилу "We moving fast, we breaking things..." будут очень рады новому инструменту для слежки, так же как и лохи не понимающие простой вещи: не сломалось, - не чини, но дело не в этом, главное здесь контроль толпы
Верующих в добро от 8.8.8.8 и 1.1.1.1 больше, так что велком в коллективное стадо...
Спасибо гугловским инсайдерам в мозиле, которые технично и стабильно убивают лисуПока что можно запретить все исходящие запросы к DNS и кормить своим ДНС-ом (который кормится только с рут серверов) локалку, но вот запрещать 443 порт не получится так просто, так как Гугля очень хочет что бы все было через HTTPS и рано или поздно они нагнут интернет (ибо certificate transparency всех SSL сертификатов у них хоститься) и блокировать rolling IPs of DoH будет не так просто. Каждый браузер бегает на OSCP проверить сертификаты, поэтому установить зависимость кто куда ходит очень легко. Короче, благодаря любителям всего нового - все в загон или дышим свободой пока network.trr.mode=0 можно использовать...
Если это твой браузер - настрой его чтобы ходил по DNS или по DoH на твой сервер. Если не твой - не лезь, всё просто.
Да разговор то не о технарях, которые могут что то настроить чтоб не быть под колпаком, а о массовости трэкинга и когда DoH не будет вызывать много шума, то станет главным резолвером, а если учесть что уже сейчас многие конторы (включая банки) работают только под хромом, в котором много особо не наменяешь то напрашивается не приятный вывод...
не переживай так за банки- в хромом не просто так отломали нафиг pkp. Менять в нем нам ничего не надо, нам гугль уже все поменял - любой https траффик у нас дешифруется на файрволле, если родина скажет - то и подменить можем.ну, придется подождать пару часов апдейта от вендора, если вдруг еще фича не предусмотрена штатными средствами той же PA7xxx
гугель же - он понятливый. хочешь в банку - соблюдай правила. Это мурзила выпендривается - ни системные настройки прокси не подбирает, ни системные же сертификаты ей, видите ли, не подходят (с линуксом, кстати, проще - там как раз прежне-мазильную помойку сделали общесистемной), и pkp кое-где все еще срабатывает, насколько я вижу.
> если учесть что уже сейчас многие конторы (включая банки) работают только под хромом, в котором много особо не наменяешь то напрашивается не приятный вывода зачем вы собрались что-то менять в ПО и на машине которые вам не принадлежат?
вы в инстаграмчик ходите с рабочей машинки?
>> если учесть что уже сейчас многие конторы (включая банки) работают только под хромом, в котором много особо не наменяешь то напрашивается не приятный вывод
> а зачем вы собрались что-то менять в ПО и на машине которые
> вам не принадлежат?С чего вы это взяли, что я что то собираюсь менять не на моих машинах?
Я говорю о повальном использовании шпионищим Хромом DevOp-ами, привязки к нему
> вы в инстаграмчик ходите с рабочей машинки?Я на истаграмчик вооообще не хожу....
>>Короче, благодаря любителям всего нового - все в загон или дышим свободойага и все приложения скоро по одному порту бегать будут (подразумеваю это tcp 443)
Welcome в мир коллектевизма под управлением несущих "добро" 1.1.1.1 & 8.8.8.8
интернет коммунизм, знаем к чему это все привело, всех в колхозы, ни один крестьянин не получил земли!
Объясняю зачем корпорации и спецслужбы вводят DNS-через-HTTPS:1. Блокировка торрентов.
После ввода DoH можно заблокировать UDP, и торренты перестанут работать, наконец сбудутся голубые мечты копирастов и корпорастов.
2. Блокировка p2p.
Также при полном переходе на TCP можно будет избавиться от зарождающихся p2p-сетей, ведь через TCP на порядок сложнее "дырявить" NAT'ы, чем через UDP.
3. Цензура доменов.
Так как протокол HTTPS потребует сертификаты подписанные головным удостоверяющим центром, то корпорации опять-таки смогут контролировать DNS-запросы и блокировать неугодные домены.
Хотим услышать ваше решение проблемы
...именно поэтому Гугл (и прочие "злые корпорации") проталкивают udp-based HTTP/3...
У тебя каша в голове, лол. DNS на UDP и 53 порте никак не мешает резать текущие торренты и p2p UDP, ведь они не маскируются под DNS и легко отличимы.
А гугловский QUIC на UDP, который всех захватит, просто разбивает весь твой бред. С ним наоборот UDP зацветёт полнейшей жизнью, забыв о болях предыдущих десятилетий, когда его дискриминировали и резали.
Зацветёт, ага — прям как IPv6 зацвёл. Будет fallback на TCP для 60% популяции.
Цифру из башки взял? 80% популяции это последний хром, там будет HTTP/2-over-QUIC и прочее новьё и никаких фолбеков из-за юзера. Да и лиса тоже будет поддерживать. Не недооценивай реактивность веба.
Смешались в кучу кони-люди.
Где DoH работающий только в браузере и где UDP? Ты вообще понимаешь о чем пишешь?
Как они связаны, убогий?
Это всё круто, но как там с поддержкой OpenNIC?
Ставишь себе dnscrypt-proxy, говоришь ему ходить к серверам OpenNIC'а и серверам поддерживающим DoH. Он умеет. И обращаешься у себя локально к нему.
>DNS-сервер CloudFlare, но его можно изменить через параметр network.trr.uri, например, можно установить "https://dns.google.com/".Заведомо неверные параметры конфигурации приводящие к неработоспособности вместо ссылки на список известных серверов https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-av... ...
И целый абзац о том какое это ненужно
Ньюсмейкеры опеннета ничего больше не пишите!*
*просто нажмите плюсик над этим постом чтобы мы поняли что вы находитесь под дулом тов. майора...
жмите, жмите, я разрешаю.список васяну-известных-серверов мне вполне нравится, я понимаю, что есть масса васянов, осиливших запустить неведомый им код на го и ноджс, чтобы иметь возможность и самим приобщиться, так сказать, к нашей "и опасна и трудна", и поинтересоваться, кто и каких интересных вещей качает. А тут рассказывают про снифферы, злых провайдеров, проклятый сорм - вот же ж как все просто - взял и создал никому неведомый васян, простите, он тут Димон, не путайте с не-димоном, репу на гитхапе, и выложил список, он-то точно на стороне добра, нет-нет, что вы, что вы, ему в голову не приходит включить лог запросов в своем "toy server".
Мне однозначно интересно, как у них 3-way handshake в TCP оказался быстрее request-response схемы UDP. Умолчу об ещё одном этапе обмена сертификатами в HTTPS.При rtt до 50мс (привет, Starlink/SpaceX) всё будет красиво, не спорю, на практике же, особенно при высоких rtt всё очень печально.
Всё просто. TCP и TLS хендшейки делаются один раз при запуске браузера. А потом соединение живёт часами и работает. И там обязательный HTTP/2, кстати, по задумке и реализации. По HTTP/1.1 они даже не планировали вообще. Т.е. корректное название DoH это DNS over HTTP/2. Соответственно все плюшки его имеет.
Плюс у TLS 1.3 1 rtt при первом соединении, и 0 rtt при возобновлении. https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/
Вот тебе и скорость на плохих каналах, где старый UDP DNS может и потеряться, а tls бегает стабильнее (сам много лет назад заметил, что http намного более страдает от проблем сети чем https, ибо в него лезут тормозные нагруженные фильтры провайдера, и может кто-то ещё криворукий).
Спасибо, теперь стало понятней в теории. На практике, разрабатывая один проект, пришлось использовать DoH, но сервер-резолвер был в США - полминуты тупняка на резолв мне показалось многовато. Но это с отдельного устройства, который локальный UDP-DNS преобразовывал в DoH. Если с клиентских устройств использовать в браузерах, то должно быть нормально.
> http намного более страдает от проблем сети чем https, ибо в него лезут тормозные нагруженные фильтры провайдера, и может кто-то ещё криворукий).Это пока, как в Китае, не ввели белые списки. И остается красивый шифрованный HTTPS (и не только он, конечно) на самом дне приоритетов, да еще и искусственно шейпится.
И чем ОНО лучше dnscrypt?
Тем что стандарт. Даже автор dnscrypt одобряет DoH и поддерживает его в своей софтине. https://dnscrypt.info/faq/
А вот dns over tls не одобряет.
Ну там приводится оценка +/-, но нет категоричных выводов.
Так какие же сертификаты будут использоваться при шифровании?
Ну и главное - dnscrypt шифрует весь трафик DNS, и зачем мне метсечковый в ФФ?
> Ну там приводится оценка +/-, но нет категоричных выводов.Если вчитаться в них (и поверить что это исчерпывающая правда), то там получаются выводы, что DoTLS хрень (опасно (сложно ненакосячить), необходимо много оверинжинерить и переизобретать http/2 ради приоритетов, реордеринга и параллелизма, палевно и легко блокируется из-за отдельного порта, очень сложно, но всё равно недодуманно и вообще ужасно), а DoH вполне себе хорош.
> Так какие же сертификаты будут использоваться при шифровании?X.509.
> Ну и главное - dnscrypt шифрует весь трафик DNS, и зачем мне метсечковый в ФФ?Тебе незачем. Но у других людей выбор стоит между установкой левой проги и смены настроек ос на неё, и включением в лисе. Второе проще.
А ты можешь в своём же днскрипте (если v2) использовать этот самый DoH и DoH-сервера, а не только днскрипт-протокол.
>[оверквотинг удален]
> блокируется из-за отдельного порта, очень сложно, но всё равно недодуманно и
> вообще ужасно), а DoH вполне себе хорош.
>> Так какие же сертификаты будут использоваться при шифровании?
> X.509.
>> Ну и главное - dnscrypt шифрует весь трафик DNS, и зачем мне метсечковый в ФФ?
> Тебе незачем. Но у других людей выбор стоит между установкой левой проги
> и смены настроек ос на неё, и включением в лисе. Второе
> проще.
> А ты можешь в своём же днскрипте (если v2) использовать этот самый
> DoH и DoH-сервера, а не только днскрипт-протокол.Да так и есть. У меня в конфиге разные сервера, в т.ч. и DoH
Левая не левая, а ФФ тот еще гарант чистоты ))
Мой провайдер когда деньги заканчиваются на счете через DNS перенаправляет на страницу "пара заплатить". Теперь как я понимаю это работать перестанет? Мне то ничего, я понимаю что происходит. А вот у обычных пользователей отвалиться?
> Мой провайдер когда деньги заканчиваются на счете через DNS перенаправляет на страницу
> "пара заплатить". Теперь как я понимаю это работать перестанет? Мне то
> ничего, я понимаю что происходит. А вот у обычных пользователей отвалиться?А обычный пользователь шарахнется от этого функционала, причем большинство из ЭТИХ на Хроме
Captive portals были предусмотрены ещё задолго до.Обычные же пользователи об этой настройке даже не подозревают, а по-умолчанию она выключена...