Компании Mozilla, Cloudflare, Fastly и Apple работают (https://twitter.com/grittygrease/status/1018566026320019457) над новым TLS-расширением ESNI (https://tools.ietf.org/html/draft-rescorla-tls-esni-00) (Encrypted Server Name Indication), которое позволит передавать идентификатор запрошенного хоста в шифрованном виде. В настоящее время расширение SNI, необходимое для организации работы на одном IP-адресе наскольких HTTPS-сайтов со своими сертификатами, подразумевает передачу имени хоста на стадии согласования соединения в сообщении ClientHello, которое передаётся в открытом виде до установки шифрованного канала связи.
С одной стороны подобная особенность упрощает организацию обработки запросов на http-серверах и позволяет использовать прокси и CDN-сети для проброса шифрованного трафика, но с другой стороны раскрывает информацию о запрошенных ресурсах для транзитных наблюдателей, например, позволяет провайдеру судить о запрашиваемых пользователем сайтах и выборочно фильтровать трафик. До недавнего времени CDN-сети Amazon и Google предоставляли возможность скрытия имени хоста при помощи техники "domain fronting (https://www.bamsoftware.com/papers/fronting/)", позволявшей обращаться по HTTPS с указанием в SNI фиктивного хоста и фактической передачей имени запрашиваемого хоста в HTTP-заголовке Host внутри TLS-сеанса (данная возможность позволяла использовать CDN для обхода блокировок и весной была отключена (https://blog.torproject.org/domain-fronting-critical-open-web)).
Поддержка начальной черновой спецификации ESNI уже реализована в библиотеках BoringSSL (используется в Chromium), NSS (используется в Friefox) и picotls (https://github.com/h2o/picotls) (используется в http-сервере h2o). При использовании ESNI имя хоста (поле server_name) также передаётся в ClientHello, но в зашифрованном виде. Для шифрования используется секрет, вычисленный на основе ключей сервера и клиента. Для расшифровки перехваченного сообщения необходимо наличие открытого ключа сервера (публикуется в DNS с использованием TXT-поля "_esni") и закрытого ключа клиента. Расшифровка также возможна с использованием открытого ключа клиента (передаётся в Client Hello) и закрытого ключа сервера или при помощи согласованного в процессе установки TLS-соединения секрета. В качестве метода обмена закрытыми ключами в черновике спецификации описан механизм, аналогичный передаче секрета (https://ru.wikipedia.org/wiki/SSL#%D0%90%D1&#... известного только клиенту и серверу. Для скрытия обращения к DNS клиентом может применяться DNS-over-HTTPS или DNS-over-TLS.
URL: https://news.ycombinator.com/item?id=17538390
Новость: https://www.opennet.dev/opennews/art.shtml?num=48972
"мурзила, огрызок и прочие гиганты индус-трии ниасилили замахнуться переделать уродливый нашлепок на http, так чтобы избавиться от самой дурацкой идеи передавать то, что и так передается внутри протокола, и разработали новое суперусложненное ненужно во славу NSA и прочих любителей поискать в таких поделках новых дыр".Главное ведь, ненароком ничего не чинить.
Жаров, перелогиньтесь. Мы-то знаем, что шифрование SNI - как серпом по яйцам для всех, кто хочет вставлять клиентам анальные зонды в виде DPI.
серпом по яйцам им было бы выкидывание этого урода в помойку.
заодно с "trusted authorities", и вообще всем уродливым мастодонтом ssl/tls.и не говорите мне, что это невозможно сделать - ssh вместе с протоколом и его рабочей и практически безупречной на тот момент (две серьезных проблемы за десять лет!) реализацией _с_нуля_, без всяких готовых библиотек с багами и глюками тянущимися по двадцать лет, не страдающей ни одной из этих болезней, был написан одним-единственным человеком за пол-года.
Согласен полностью.Коллега, а что нам собственно стоит взять какой-нибудь хромиум и реализовать в нем HTTP/1.1 через SSH?
МОдер, удали эту ересь выше)))
почему ересь? Туннели через обратный ssh известны со времен царя гороха. Другое дело, что область применения этого дела весьма и весьма ограничена
Конечно невозможно. Пофигу, как легко написать - важно, как легко внедрить. А на вебовских масштабах даже очень большая куча костылей дешевле и проще во внедрении, чем "до основанья, а затем".
> Конечно невозможно. Пофигу, как легко написать - важно, как легко внедрить. А
> на вебовских масштабах даже очень большая куча костылей дешевле и проще
> во внедрении, чем "до основанья, а затем".Последние лет 10 так в "вебе" и делают. Поэтому и имеем гигантскую пирамиду из костылей, подпорок и прочего с тормозами и жором ресурсов. Но т.к. жор на клиентских машинках, то всем вышеупомянутым - на*рать. Заодно и "левых" браузерных движков можно больше не опасаться - разработку такого монстра, под современный веб, только корпорация и потянет.
Естественно так и делают. Потому что по-другому не взлетит вообще
Внедрить легко, если не вместо, а рядом. HTTPS много лет был не вместо HTTP и только последние лет пять эта ситуация изменилась.
Вот потому и пролез в конце концов, что много лет рядом был и наросла критическая масса контор, которые его используют, людей, хоть как-то умеющих его готовить и так далее. Можно рядом что-то новое положить, угу. В браузерах. Но быстрого использования на серверной стороне не ждите. Это http-серверы, всё, что вокруг них, оценка надёжности внедрения, отлов граблей... в общем, годы и годы. При этом в 95% случаев оно еще и на фиг не надо. А тут - сгенерировать ключ, запись в DNS добавить и сравнительно простой модуль в балансер или что там на фронте крутится - глядишь, за пару лет и управятся хотя бы процентов 30 сайтов.
Помимо серверной стороны предстоит решить вопрос с контекстами выполнения JS, полученных из разных источников с разным уровнем сикурности. Какой-то механизм управления нужен.
Сейчас мы имеем, что JS на HTTPS страницах можно грузить только с HTTPS серверов. Это совершенно избыточно. Нужен контроль целостности и аутентификация.Хотя, что я несу... Веб уже не спасти. Разве что еще один рядом забабахать с блекджеком и шлюхами.
> Сейчас мы имеем, что JS на HTTPS страницах можно грузить только с HTTPS серверов. Это совершенно избыточно. Нужен контроль целостности и аутентификация.Избыточен твой контроль целостности и аутентификация, когда и так есть https. Будет нормальная альтернатива, обеспечивающая то же самое, появится и исключение для загрузки твоей шняги на https страницах. А пока о чём говорить вообще? Собрался над хттп костылять цифровые подписи и прочее, переизобретая tls? Ну удачи, только никому это не нужно.
HTTPS свою задачу не выполняет, пока используются CDN, терминирующие TLS (Cloudflare) и работают сертификаты, подписанные третьими лицами. Контент может быть подменен без возможности это обнаружить.
И какое ты решение предлагаешь? По типу SSH? Как себе представляешь? Откуда ты возьмёшь ключ сайта, который хочешь открыть? Встретишься с Максимом Чирковым чтобы потом открывать опеннет? А если нет, то как ты можешь быть уверен в отсутствии митма?
Согласование фаз между зашифрованным DNS и HTTP/HTTPS.DNS и BGP должны быть включены на валидацию сторон и шифрование.
> По типу SSH? Как себе представляешь? Откуда ты возьмёшь ключ сайта, который хочешь открыть?откуда ты берешь ключи ssh? Лично бегаешь по всем хостам, или все же предполагаешь, что в обычных условиях вряд ли ОНИ тебе все подменили, не зная ни кто ты, ни куда собираешься, ни когда тебе приспичит - а после этого любая подмена уже будет видна.
> А если нет, то как ты можешь быть уверен в отсутствии митма?
страдай, бедняжка...
Ну и да - для чего-то такого, где используются сейчас EV - очень неплохо бы пихать везде, где это возможно, 3d-код для верификации. Эх, мечты, мечты...
из блокчейна. emercoin это умеет
>Нужен контроль целостности и аутентификацияуже есть: https://en.wikipedia.org/wiki/Subresource_Integrity
> Вот потому и пролез в конце концов, что много лет рядом был и наросла критическая масса конторто есть гугл, один штука.
да, отказ от возврата в результатах поиска "неправильных" сайтов отлично сработал.> Но быстрого использования на серверной стороне не ждите.
казалось бы, причем тут cloudflare, контролирующая половину нынешнего веба если не напрямую, то из-за любимых макаками src=""...
но, похоже, товарищ майор платит больше, чем не-халявные пользователи.
> похоже, товарищ майор платит больше, чем не-халявные пользователи.он не платит ничего (платят только лохи).
он угрожает дать по башке, отобрать деньги и посадить в тюрьму.
по кр.мере я давал такое указание.если у вас есть данные что он именно платит - сообщайте мне, я разберусь.
HTTPS был рядом потому, что использовать SSL было дорого. йа бы сказал супер-пупер как ОЧЕНЬ дорого.Начиная с ежегодной покупки сертификата за тыщщи денег, требующимися для шифрования более мощными (более дорогими) процами на КАЖДОМ сервере и на КАЖДОМ клиенте, дорогими каналами связи с оплатой побайтно, при https невозможно полноценно кэшировать на proxy (региональных национальных (CDN) провайдерских транзитных (чтоб меньше платить международным магистралам), конторских локальных (чтоб резать мусорные банеры\"вирусы")).
only https internet выглядел бы сейчас как в 2000 году. 190 унылых основных сайтов и 2300 сайтов визиток.
AES-NI/FPGA/pcie-card
ты сам то понял что сказал?
> Начиная с ежегодной покупки сертификата за тыщщи денегмой сертификат startssl (ныне покойного) стоил мне $0. extended validation thawte (ныне покойной), с отсылкой заверенных бланков регистрационной информации курьером - $350 на три, что-ли, года. Что может себе позволить любая лавочка по продаже кондомов second-hand, если вообще хочет что-то таким образом продавать.
Прокси у провайдеров? Назовите этих чудаков на букву M?! В 2000м году - годится, люди с годами только тупеют (если они уже банкроты, можете не называть, мало ли было пузырей в 2000м, классно чпокнушвих уже через год-полтора, кто с проксей, кто вообще весь интернет на одном сd пытался продавать). Ладно б какие-нибудь хоменеты из дерьма и палок, с апстримом аж 64 килобита на всех... правда, это уже и в 2000м было немодно.
Настоящие cdn работают совершенно не так, как ты подумал - у них есть сертификат того, чем они представляются, и никакие другие им не требуются.
зачем уютному персональному бложику или лавочке по продаже second-hand кондомов SSL?кроме того, речь тут шла о том "а пачиму сразу не был сделан интернет на HTTPS only".
потому, что глупо и нелепо приводить цены 2016 года. на заре интернета SSL extended validation сертификат стоил 3000 (три тысячи) в год.
на один домен третьего уровня, для частного лица, по большой акции я покупил со скидкой за 750.
и startssl тогда еще в проекте не было.потому, что широко распространенное железо в то время, как на серваках так и на персональных компах общего опльзования не потянули бы еще и SSL шифрование. а специальные крипто сопроцессоры тогда стоили дороже средней рабочей станции.
да. прокси у провайдеров и в 1994 и в 2000 и сейчас (сам фаллоформировал, когда прочитал в июне 2018 года на форуме nag.ru). раньше в основном кэшировали контент, резали банеры и malware - повышали скорость узкого аплинка, сейчас в основном режут\ограничивают скорости на абонентов (и кэшируют что получится). man squid delay pool.
я знаю как сейчас работает CDN. тот CDN о котором ты говоришь, который работает сегодня - это уже отдельное молодое направление бизнеса. а тогда (на заре интернета) это было стихийное явление, провайдеры вынуждены были ставить proxy из за дороговизны трафика, "узости" международных каналов, жлобских пиринговых войн. раньше и слова то такого не было, CDN. зато был HTTP, который отлично кэшировался бесплатно для сайтовладельцев и с пользой для юзеров.
> зачем уютному персональному бложикув стране, где сажают за лайк, вы серьезно спрашиваете?
> или лавочке по продаже second-hand кондомов SSL?
у тебя какие-то другие деньги для second-hand кондомов, ты данные кредитки прямо в открытый http вобьешь? Да и просто почтовый адрес и прочие личные данные, наверное, не стоит палить прямо вот так?
> на заре интернета SSL extended validation сертификат стоил 3000 (три тысячи) в год.
наверное, я эту зарю пропустил - или просто не ходил к п-сам в самом плохо смысле, а ходил к "дешевой" thawte. Тысячные цены, по-моему, были исключительно у verisign, и там ты, действительно, платил за понты. (то есть вот ровно так Космонафт и заработал свой первый миллиард - продавал тот же самый воздух вдесятеро дешевле, понятно, покупатели валили валом)
> раньше и слова то такого не было, CDN
ну тогда может не надо употреблять этот термин для описания совсем другого явления, которое так и не называлось?
Я верю, что какие-то местечковые провайдеры, выросшие из хоменетов (где интернет был побочным сервисом за отдельные деньги, и через один adsl на весь микрорайон, а так вообще-то в quake все рубились - там, понятно, и делали всякие проксилки и любые другие странные способы уменьшить траффик) могли в 2000м так работать, но мне вот как-то повезло,ни разу не сталкивался.
В 98м да, бывало - но и то чаще позиционировалось как дополнительный сервис, для тех кто понимает, а не наоборот (у нас было именно так).
> и с пользой для юзеров.
или с вредом - когда закэшировалось, к примеру, не в той кодировке, и пользователь получал абаракадабру, не зная, как от нее избавиться и думая что виноват тот сайт.
>> зачем уютному персональному бложику
> в стране, где сажают за лайк, вы серьезно спрашиваете?и как SSL на это повлияет? следователь не увидит лайка? ему будет показываться какой то другой сайт?
>> или лавочке по продаже second-hand кондомов SSL?
> у тебя какие-то другие деньги для second-hand кондомов, ты данные кредитки прямо
> в открытый http вобьешь? Да и просто почтовый адрес и прочие
> личные данные, наверное, не стоит палить прямо вот так?20 лет палили и ничиего, но тут, ВНЕЗАПНО очковать начали? что так вдруг?
> Я верю, что какие-то местечковые провайдеры, выросшие из хоменетов (где интернет был
использование кэширующего прокси магистральными провайдерами, это не вопрос веры. это факт.
>> и с пользой для юзеров.
> или с вредом - когда закэшировалось, к примеру, не в той кодировке,
> и пользователь получал абаракадабру, не зная, как от нее избавиться и
> думая что виноват тот сайт.и ты не видишь здесь пользы? мне вас жаль(с).
> и как SSL на это повлияет? следователь не увидит лайка?увидит, но не сможет просто так выяснить кто его поставил,когда нет возможности ни перехватить траффик и подшить к делу запрос к базе оператора с паспортными данными, ни спросить у владельца бложека так, чтоб тот не мог отказать.
А подписаться "нах" каждый у нас может.> 20 лет палили и ничиего
вы 20 последних лет совали данные своих карт в открытые каналы?
До этого - да, было дело, их и перли все кому не лень, и даже кому лень тоже перли - для халявного интернета, например. Но те времена давно прошли, уже даже больше 20 лет тому.> использование кэширующего прокси магистральными провайдерами, это не вопрос веры. это факт.
и третий раз спрашиваю - кто эти п-сы?
Нашими апстримами (надеюсь, никто не угадает) были Спринт и МТУ(забыл, кто у них самих) - никаких проксей там в помине не было. У нас прокси был, выдавался пользователю на дискеточке - и тот должен был обладать интеллектом, чтобы _вручную_ и правильный (их было по числу кодировок) вписать в свои настройки - повторяю, это был сервис, а не анти-сервис. Кстати, я даже как-то и не уверен, что наше оборудование позволило бы избирательно пустить именно http траффик через прозрачный прокси.
Мы далеко не самый крупный провайдер, но и не хоменет, гуляли не на свои.
Проблема в том, что без "trusted authorities" невозможно защищенно связаться с незнакомцем.Ведь чтобы начать связь, необходимо подтвердить, что именно ему принадлежит тот или иной публичный ключ (а то вдруг на нас идёт MitM-атака). А как это сделать? В SSH можно сверить хеши ключей, но для этого в начале надо знать настоящий хеш. А у нас нет доверенного канала, чтобы его переслать.
TLS решает проблему тем, что вы оба доверяете тому самому дяденьке trusted autority, который подтверждает идентичность корреспондента(ов)
> Проблема в том, что без "trusted authorities" невозможно защищенно связаться с незнакомцем.возможно. невозможно убедиться что он тот, за кого себя выдает - но чаще всего это и не требуется.
Значительно важнее - потом не дать кому-то выдать себя за того - когда у того уже есть репутация.> В SSH можно сверить хеши ключей, но для этого в начале надо знать настоящий хеш.
и в ssl можно. Ну да, надо - и много вам ssh ключей злые хакеры успели подменить - угадав время, место и target host?
Оттож. При этом ничто не мешает иметь и отдельный канал для простого получения fingerprint или самих ключей (правильнее -второе) - хотя бы даже тот же dns, но использовать его исключительно для _дополнительной_ проверки, а первичной - именно локальную копию ключа.> TLS решает проблему тем, что вы оба доверяете тому самому дяденьке trusted autority
нет. tls ее решает тем, что твой браузер тyпо доверяет тем дяденькам, и тебя ненужными знаниями не огорчает. При том что у дяденек и так рыла в пушку, так еще в их строй товарищи майоры затесываются целыми батальонами (и различать ca по степени доверия - казалось бы, первое, о чем должны были подумать разработчики, если бы им было, чем - мы не умеем никак).
А если что-то пошло не так - выдает огромную страницу красной бни, без кнопки продолжить.
> невозможно убедиться что он тот, за кого себя выдает - но чаще всего это и не требуется.В случае банка, биржи и любого другого финансового учреждения важно как раз именно это - что он тот, за кого себя выдаёт
> Ну да, надо - и много вам ssh ключей злые хакеры успели подменить - угадав время, место и target host?
много или мало, но с теоретической точки зрения не должно быть такой возможности, шансы к минимум должны быть сведены
> При этом ничто не мешает иметь и отдельный канал для простого получения fingerprint или самих ключей (правильнее -второе)
Если этот канал небезопасен, то доверять ему можно будет с трудом. Разве что для обнаружения самого факта вмешательства и высвечивания тревоги.
> tls ее решает тем, что твой браузер тyпо доверяет тем дяденькам, и тебя ненужными знаниями не огорчает
Если простого юзера огорчают знания, то он вынужден доверять какой-то сущности, будто администратор локалки, разработчики браузера и т.д.
> При том что у дяденек и так рыла в пушку, так еще в их строй товарищи майоры затесываются целыми батальонами
Я и не говорю, что trusted authorities - безотказная схема, серебряной пули как раз нет. Я лишь говорю, какие задачи она решает, почему возникла
а делают они это вот этими самыми руками:https://mobile.twitter.com/levelsio/status/10187934515533455...
https://mobile.twitter.com/0xjomo/status/1018810610597941249...
Ой какой же ты дуpак, ну дуpаааак... Забаньте уже всех этих "пoxов", "наxoв", и прочих увеселительных клoeнок. У нас тут вроде не царский двор, шyтов хватает и на других сайтах.
Наконец-то! Тогда и DNS и SNI будут шифрованны, шикарно.
>и DNSdnscrypt, не?
>Компании Mozilla, Cloudflare, Fastly и Apple работают над новым TLS-расширением ESNIмазила до сих пор резолвер TTR (Trusted Recursive Resolver), предоставляющего возможность отправки DNS-запросов поверх HTTPS (DoH, DNS over HTTPS)сделать не может и довести до конца проект, хотя обещала что в 60 уже будет работать, а уже за новое взялись, ну типичный современный айти хайтек, срочно лепим новое забивая на старое
Зато клаудфлара смогла.
В 61 уже нормально работает DoH. В 60 крашил браузер. Сейчас мне не хватает только префа для эксклюда некоторых доменов из DoH, чтобы их резолвить через hosts или легаси-днс системой (один домен не резолвится клаудфлярой, другой резолвится неоптимально, т.к. не видит где я с DoH), баг уже открыт с P3.> ну типичный современный айти хайтек, срочно лепим новое забивая на старое
Обоснуй. Это же прямо связанные вещи. Никогда что ли не слышал смешных людей, которые говорят:
— да зачем вам SNI шифрованный в TLS 1.3 (было обсуждение при работе над ним, с конкретными предложениями, но не вошло в итоге) или далее, всё равно ведь палится через открытый DNS
— да зачем вам DNS шифрованный, всё равно ведь через SNI домен палится, даже в новом 1.3
И ведь не понимают, что обе проблемы надо решать. И ничего не делать — худший вариант. Надо начинать с любого из двух, или одновременно оба, не суть. Надо хоть что-то делать, потому что не важен порядок закрытия этих проблем. Не важно, что решение любого из двух, без второго, будет почти бесполезным на практике, ибо домен утекает. Важен конечный результат: чтобы домен не был виден ни через DNS, ни через TLS. К этому надо идти, и к этому идём, спасибо всем причастным. Это кардинальное улучшение интернета. Голый днс и сни в наши дни просто смешны и ужасны.
Как удалось завести? У меня и в 61.0 не работал. :-/
Просто 3 префа https://gist.github.com/bagder/5e29101079e9ac78920ba2fc718aceec
network.trr.bootstrapAddress;1.1.1.1 или 1.0.0.1 (первый может быть недоступен)
network.trr.mode;3
network.trr.uri;https://mozilla.cloudflare-dns.com/dns-queryЕщё можно ipv6 резолв отключить, если не нужен: network.dns.disableIPv6;true
А с гугловским сервером работает? У меня теперь тоже заработало, но только с mozilla.cloudflare-dns.com и никакими другими, в т.ч. со своим. Даже с dns.cloudflare.com и cloudflare-dns.com не работает.
> При использовании ESNI имя хоста (поле server_name) также передаётся в ClientHello, но в зашифрованном виде. Для шифрования используется секрет, вычисленный на основе ключей сервера и клиента. Для расшифровки перехваченного или полученного значения поля ESNI необходимо знать закрытый ключ клиента или сервера (полюс открытые ключи сервера или клиента). Информация об открытых ключах передаётся для серверного ключа в DNS с использованием TXT-поля "_esni", а для клиентсного ключа в сообщении ClientHello. Расшифровка также возможна при помощи согласованного в процессе установки TLS-соединения общего секрета, известного только клиенту и серверу. Для скрытия обращения к DNS клиентом может применяться DNS-over-HTTPS или DNS-over-TLS.боже! это слишком сложно!
один маленький (управляемый?!) сбой -- и всё это откатывается на старый дырявый протокол :-) ..
провайдеры лишь всего-навсего просто будут:
* блокировать DNS-over-HTTPS/DNS-over-TLS [ну как минимум популярные серверы].
* перенаправлять все DNS запросы -- на свой DNS-сервер.
* вырезать из DNS -- DNSSEC-структуры и _esni-структуры .
* как и прежде -- подслушивать-и-реагировать на старый добрый нешифрованный SNI!
это даже будут делать не сами провайдеры (по якобы своей воле) -- а по-средствам типового DPI-софта который будет навязываться им (провайдерАМ) для обеспечения законов РКН-и-Яровой.
--------------------------------------------------
клиентский софт -- будет от безысходности откатываться на старое поведение и делать всё по старинке.
а из-за того что _esni-структуры требуют ручное вмешательство -- то это не получит должного распространения среди сайтов.
(будет использовано как обычно только на twitter и gmail.. ну и плюс на полтора сайтах хакера-васи :))
из-за отсутствия популярности инициативы среди сайтов -- Мозилла-и-другие-браузеры НЕ смогут заявить типа "внимание! теперь мы будем работать только с ESNI-сайтами! остальные открываться не будут!"
и это как замкнутый круг приведёт к том что про esni со временем просто забудут как очередная неудачная попытка наладить шифропорядок в web-паутине
> провайдеры лишь всего-навсего просто будут:Это не «всего-навсего просто», лол. И по твоей логике ничего не надо делать, ведь всё равно могут интернет открубить.
Зачем нам трафик TLS шифровать? Ведь могут просто заблочить и вынудить http юзать. Но нет, уже не могут так сделать. Максимум — по IP и SNI мешать устанавливать соединение.
Зачем VPN существует? Ведь легко протокол детектится в 98% случаев. Но чёт только в Китае более-менее пытаются, да и там люди продолжают использовать. Более неумело в Иране пытаются.
Усложнять работу цензурятам всегда есть смысл. Даже чуток.
Это задел на будущее. Старый открытый SNI потом уберут из браузеров и другого софта. Напомню, что некоторые маргинальные браузеры и сейчас поддержки SNI не имеют, и в них даже что-то частично работает.
А блочащие DoH просто выставят себя как дикие страны (у передовых другие методы есть, им это не нужно). Которым можно и санкций подкинуть, мотивируя правами человека.
Да, в теории многое можно, но на практике не всегда все это реализуется.
> Старый открытый SNI потом уберут из браузеров и другого софтане смогут убрать!
потому что кроме www-браузера если и обычные библиотеки делающее свои дела через tls.
и вот представь себе -- ты хочешь написать утилиту которая делает запрос.
ты подрубаешь TCP-сокет -- затем хочешь апгрейдить его на TLS-сессию и вдруг тебе становится для этого нужен уже какой-то чёртов esni-ключ! ты уже будешь обязан ещё и DNS-запрос отправить на получение этого ESNI-ключа!
ну теоретически есть вероятность что рано или поздно придёт культура которая будет это поощьрять...
типа каждый программист-будущего будет даже без заиканья (разбуди его ночью ото сна!) говорить "ну конечно чтобы заапгрейдить на TLS нужно сделать DNS-запрос!"
...но сейчас в веритьcя с трудом. :-) .. хотя и возможно -- кто знает.
И почему верится с трудом? Вот был 2004 год, и всё кроме браузера, да и даже сами браузеры в большинстве случаев, юзали плейн хттп. И библиотеки все твои. И вот однажды, постепенно, требование TLS возросло до такой степени, что ты теперь не пишешь: вот раньше я мог открыть tcp-сокет и начать просто слать хттп запросы, а теперь мне нужно какой-то tls ещё реализовывать/брать другую библиотеку, заворачивать всё в шифрование, ужас какой!
Или может ты не застал до-tls эру. Вот как ты сейчас tls без особой проблемы реализуешь, так и с ESNI будет. В чём проблема? Ничему новому не хочешь учиться? Ну иди кодь под win98 и старый линух, а то ведь сколько всего напихали нового за эти десятилетия.
Уж из браузеров убрать - запросто, хоть и поэтапно
> потому что кроме www-браузера если и обычные библиотеки делающее свои дела через tls.целых две, не считая форков?
Ну так одну вон уже... эммм...антимат... отрефакторили!> и вот представь себе -- ты хочешь написать утилиту которая делает запрос.
как и сейчас - тянешь через интуитивно-приятную обертку openssl, ну может - первое время - придется использовать какой-нибудь ее клон, кто у нас там сегодня модно, boring? Вот ее и пользуй. Там еще опасТные протоколы выпилены и сборка под опасТные операционные системы (все что не линукс) поломана, сплошные бонусы!
Если он не дотянулся до этого дурацкого esni - возвращаешь пользователю БОЛЬШОЕКРАСНОЕОКНО - внутрь можешь что-нибудь из /dev/random процитировать, все равно пользы от этого никакой.
Не то чтобы я хотел опровергнуть что-то из вами сказанного, просто напомнить, что в SSL/TLS есть очень www-ориентированные штуки, которые за пределами вебсервера не очень-то и работают в массе своей. Из них сходу вспоминаются 2:
- само SNI, которое поддерживается даже не в каждом вебклиенте, браузеры и большие библиотеки - это да, но в TLS может оказаться не только вебня и вот там всё грустно.
- Wildcard, опять же, применение которого тоже ограничено в протоколах.
- Их сочетание.Я понимаю, что для посылки веб-запроса по идее надо бы иметь SNI, в общем случае. Но многие не парятся, а убирать поддержку расширения, которое гарантировано работает только в браузерах и больших популярных библиотеках из "другого софта" очень просто, ведь его и не завезли. ESNI туда тоже не завезут, сложно.
Да, на фоне ESNI само SNI выглядит просто, но народ решает оба вопроса (SNI/Wildcard) посредством обязывания покупать сертификат содержащий SAN.
>блокировать DNS-over-HTTPSРазве это так уж просто сделать?
>>блокировать DNS-over-HTTPS
> Разве это так уж просто сделать?ну как Телеграм :-)
Вообще-то да. Это обычный HTTPS трафик, провайдер его видит шифрованым, ну если не пойти и не перебанить все известные DOH сервера.
Так ведь перебанить _все известные_ DOH сервера невозможно, а блокировать весь https трафик никто не станет в здравом уме.
Станут. Госбезопасность шерифа волнует, а проблемы индейцев - нет.
Как раз нормально. Как отладят/внедрят - браузеры для начала станут всё, что такие штуки не реализует, показывать как недоверенный сайт (точнее, сначала так будет происходить для какого-то известного набора, как для HSTS, например). А потом - тупо перестанут работать в несекьюрном режиме без адских плясок.Ну а что в Россиях это могут тупо административно побить - так с тем же успехом могут и вовсе шифрование трафика запретить. Это не проблема мейнстримных решений, борьба со свихнувшимися властями - это к даркнетам.
> из-за отсутствия популярности инициативы среди сайтов -- Мозилла-и-другие-браузеры НЕ смогут
> заявить типа "внимание! теперь мы будем работать только с ESNI-сайтами! остальные открываться не
> будут!"мурзила - уже может, полутора оставшимся пользователям уже все равно.
> провайдеры лишь всего-навсего просто будут:* блокировать DNS-over-HTTPS/DNS-over-TLS [ну как минимум популярные серверы].
* перенаправлять все DNS запросы -- на свой DNS-сервер.
* вырезать из DNS -- DNSSEC-структуры и _esni-структуры .А, кардеры им будут очень благодарны.
Вопрос, мягко говоря, перезрел.
Рыба уже давно уже сгнила с головы, они ток задумались.
Тут бы проблемы DNSSec и антиспуфа порешать в BGP by default...
+100500
Сегодня DNSSEC / DANE + DNS-over-TLS должно стать первоочередной задачей.
Как выше писали, DoT не имеет такого уж большого смысла, если имя хоста передаётся в SNI в открытом виде даже в TLS 1.3.
Во-первых, не вижу где. А, во-вторых, и это главное, не вижу связи.
На кой, собственно, использовать SNI вместе с DNS-over-TLS?
Не вместе с DoT, а при обращении к сайту по HTTPS, будет передаваться SNI.
В DNS-over-TLS внезапно никакого HTTPS нет.
Внезапно при установлении TLS соединения со SNI, твой DNS-over-TLS теряет смысл, потому что имя домена прекрасно светится в SNI.
Да бизнес это никогда не внедрит.Вы же видели - Mozilla и Amazon закрыли domain fronting для того, чтобы угодить российскому государству.
Поэтому никто заморачиваться с детектом и удалением этого шифрованного sni не будет. Поступят гораздо проще. Ведь уже есть закон о передаче ключей шифрования. Соответственно, если на одном сервере с заблокигованным или просто неугодным сайтом размещается сайт с этой байдой, то от него требуется передача ключей шифрования, и сайт блочится.
> Да бизнес это никогда не внедрит.Чушь. Бизнесу нет причин это бойкотировать. И есть причины это внедрять. Ибо иначе бы и https не внедряли. А РКН никого не волнует.
> Вы же видели - Mozilla и Amazon закрыли domain fronting для того, чтобы угодить российскому государству.
Ложь и чушь. У Mozilla никогда не было фронтинга. Щас бы их с гуглом путать, лол.
Амазон не закрывал из-за РФ, как и гугл. Читайте https://www.opennet.dev/opennews/art.shtml?num=48768#9
> Чисто хронологически может и после, но не вследствие. Гугл закрыл фронтинг ещё 13 апреля:
> https://trac.torproject.org/projects/tor/ticket/25804
> https://www.theverge.com/2018/4/18/17253784/google-domain-fr...
> Т.е. прямо в день суда по Телеграму. Вы верите в такую скорость реакции? Это при том, что столько неделю его миллионы айпишников были забанены? Некоторое время даже те, что фронтят www.google.com и прочие его ресурсы. Очевидно уже какое-то время собирались закрыть фронтинг. Напомню ещё деталь, если кто не следил. Хоть суд был и 13 апреля, блокировки РКН начал только в понедельник 16.
> Амазон следом пошёл, но запрещал фронтить он не телеграму, а Signal мессенджеру. Который в свою очередь вовсе не бодался с РКН, а юзал фронтинг для арабских стран. И привлечь внимание пытались они:
> https://signal.org/blog/looking-back-on-the-front/
> А РКН и без всякого рабочего фронтинга держал 9 миллионов айпишников Амазона в блоке до прошлой недели. И до сего момента ещё держит почти 3 миллиона.
> Поэтому никто заморачиваться с детектом и удалением этого шифрованного sni не будет. Поступят гораздо проще. Ведь уже есть закон о передаче ключей шифрования. Соответственно, если на одном сервере с заблокигованным или просто неугодным сайтом размещается сайт с этой байдой, то от него требуется передача ключей шифрования, и сайт блочится.Да, могут и так поехать. Что сказать-то хотел? Могут ещё проще: государственный митм государственным сертификатом, без которого https просто не будет работать. И всё, весь трафик на ладони.
Но кого волнует Северная Корея, Иран, РФ и Китай? Не для них и не ими это разрабатывается.
> Но кого волнует Северная Корея, Иран, РФ и Китай?амазона и гугля, как видите, волнует. самый богатый человек мира потому и самый богатый, что не ленится нагнуться за лишним рубликом довольных россейских потребителей - даже если ради этого надо вышвырнуть со своих серверов какой-нибудь телеграмм, чтоб товарищмайор был доволен.
это вот клятая корпорация зла дошла в своем зле аж до того, что windows store через mitm proxy не работает никак, никогда и ни при каких настройках. Теряет бабки, да и репутацию среди офисных крыс, но чинить отказывается. А тем временем корпорация добра выпилила из хрома pkp, чтоб товарищмайору было удобнее.
(а из телеметрии - не выпилила, afaik. Это товар, товарищмайору надо за него заплатить, как все.)
>даже если ради этого надо вышвырнуть со своих серверов какой-нибудь телеграмм, чтоб товарищмайор был доволенЭто весьма непростая медийная история. Если выкидывать, то есть репутационные риски(общественное мнение в США сильное и это выльется в ощутимую потерю денег). Если не выкидывать - недоступность для клиентов в регионе.
В случае с РКН сыграл факт, что Жаров в санкционном списке.
> Это весьма непростая медийная история. Если выкидывать, то есть репутационные риски(общественное
> мнение в США сильноеоно там специфичное - пока не затрагивает сами Штаты, особо ни на что не влияет.
А у нас: "Egypt, Oman, Qatar, and UAE" (из сигналовского письма скорби) - боюсь, что общество в США слабо представляет, где это и на какой планете.
> позволит передавать идентификатор запрошенного хоста в шифрованном виде.Нужно. Нужно. Нужно!
Получается, прокси - как анонимайзеры, так и корпоративные - при таком раскладе идут лесом?
Похоже на то. Я во всяком случае не очень понимаю, как в таком случае прокси будет определять, кому запрос адресован.Местные эксперты, по ходу, с ответом слились, но пост на всякий случай заминусовали... а меж тем вопрос вполне здравый.
Как это как определять? А айпишник в пакете для чего указан? Вот пусть прокся и шлёт его туда неизменённым, как сейчас и происходит с прозрачными проксями. Зачем им смотреть в SNI, лол? Это не их слой. Ей пришёл IP-пакет, адресованный на ip:port сервера, это всё, что надо знать, чтобы его отправить дальше. А там уже сервер назначения разберётся со SNI/ESNI.
Вопрос не здравый, а глупый, видимо поэтому проминусовали и прошли мимо.
> Как это как определять? А айпишник в пакете для чего указан? Вот
> пусть прокся и шлёт его туда неизменённым, как сейчас и происходит
> с прозрачными проксями. Зачем им смотреть в SNI, лол?Затем, что прокси еще и для фильтрации трафика используются. Лол.
В такой ситуации останется только либо пропускать весь шифрованный траф молча, либо блочить все шифрованное "потому что шифрованное".> Вопрос не здравый, а глупый, видимо поэтому проминусовали и прошли мимо.
Нормальный вопрос. Безопасность - это хорошо, только не нужно из=за нее все ломать...
Чего там шифровать? С каких сайтов тянешь ad блоки по текущему гнезду? да уж великий секрет. А если адрес вбил, без dns никуда, вот его скрыть это плюс. А браузеры пусть дальше свои костыли засовывают, скорей накроется этот скриптовый треш.
> А если адрес вбил, без dns никуда, вот его скрыть это плюс.И какой же в этом плюс без шифрования SNI? Вот скрыл ты днс шифрованием, а всё равно домен палится в открытом SNI. Это бесполезно.
Решать надо обе проблемы, они напрямую связанны и представляют одну проблему. И это как раз движение к решению.
Или ты вообще не понимаешь как интернет и веб работает, дружок?
дружок, я про то что реализация веба на сегодня исключительно косячна, эти наработки из прошлого века. Сегодня пользоваться уже почти невозможно. Хотят лечить флаг им
Хотят лечить вебом флаг? Какой флаг? И зачем его лечить? Это какой-то молодёжный сленг?
этому сленгу лет за писят уж. Это вообще моя планета?
Запятые нужно ставить.
"эти наработки из прошлого века. Сегодня пользоваться уже почти невозможно."(с)
QUIC шифрует SNI еще надежнее, единственное что там из заголовка можно получить это метку connection-id. И вообще как так вышло, что TLS умеет отдавать заголовок хоста без шифрования?
У лидеров рынка NIH-синдром же.
>И вообще как так вышло, что TLS умеет отдавать заголовок хоста без шифрования?Сначала не умели. Т.е. идя на сайт по ip X.X.X.X клиент ожидал там сертификат по имени www.yyyyyyy.com. Прокси на сервере никак не могло угадать, а куда ломится клиент. Поэтому https сервера были по одному на ip. И сказали все -это не хорошо. И добавили открытое имя, чтоб сервер мог ответить нужным сертификатом. Догадаться выдать ответ сразу на кучу и клиент бы шифровал нужным, решили, что глупо и несекурно. :)
> Поэтому https сервера были по одному на ip. И сказали все -это не хорошо.и это была чудовищная глупость. Настолько вопиющая, что начинаешь сомневаться, что именно глупость.
В тот момент, когда ты шел на одессу, а вышел ты нахрен - надо вывести понятное человекочитаемое (а не большую-красную-хню) сообщение - "здесь шифрование только для галочки - и обеспечивает его не www.yyyyyyy.com, а www.xxxx.net - нажмите два раза reset,и застрелитесь, если вы ничего не поняли - все равно вы в этом мире не жилец"потому что если там cloudflare - этот yyyyyyy доверил твою (!) информацию cloudflare. Если дефолтхост шитхостера "мильенсайтовза$25" - то сам понимаешь. А если google.com вместо gmail - то ничего в общем страшного. Как и корпоративный прокси. Но вообще-то неплохо бы тебе об этом знать до нажатия ok. И предупредить, если в другой раз вылезет кто-то другой. Ни в одном из этих случаев sni никакой секьюрити не добавляет, наоборот, позволяет скрывать явную сдачу тебя с потрохами.
P.S. кстати, одного меня напрягает ультимативное требование cloudflare переводить домен на их ns, без каких-либо альтернативных вариантов?
>> Поэтому https сервера были по одному на ip. И сказали все -это не хорошо.
> и это была чудовищная глупость. Настолько вопиющая, что начинаешь сомневаться, что именно
> глупость.
> В тот момент, когда ты шел на одессу, а вышел ты нахренПочему нахрен? Ну на Украину, ну и что сразу так... >:-)
На шаред хостинге овер 1000 хостов на одном IP. Так каждому клиенту портянку в XX мегабайт на каждый запрос придётся отдавать.
> QUIC шифрует SNI еще надежнее,ну и поведай -- как же в QUIC происходит обмен ключами для SNI ?
точнее говоря -- расскажи -- как происходит противостояние от MitM для фазы SNI ?
>Информация об открытых ключах передаётся для серверного ключа в DNS с использованием TXT-поля "_esni"да ну нафиг. лишняя сложность, плюс дополнительная точка отказа
DNS устарел, HTTP устарел, BGP без BGPsec устарел... Нас нужны новые интернет!!!!!
>Нас нужны новые интернет!!!!!https://duckduckgo.com/?q=pied+piper+new+internet
https://duckduckgo.com/?q=pied+piper+new+internet&iax=images...
похоже на какое-то бла-бла
whois говорит, что duckduckgo хостится в ирландии, а все мы знаем, что по ирландии фбр ходит как у себя дома, а раз фбр ходит, то и для остальных твои поисковые запросы — не секрет. Особенно c учётом того, что ты не отключил жабоскрипт.
> whois говорит, что duckduckgo хостится в ирландии, а все мы знаем, что
> по ирландии фбр ходит как у себя дома, а раз фбр
> ходит, то и для остальных твои поисковые запросы — не секрет.
> Особенно c учётом того, что ты не отключил жабоскрипт.Айяйяй, Как же мне спрятать мои поисковые запросы, которые я выложил на опенет?? Бида-бида.
ФБР не работает за границей USA. Ты бредишь.
Работает, в тех случаях, когда преступление, разрабатываемое ФБР, предполагает действия преступника/ов, являющегося/ихся гражданином/анами США с территории вне США - естественно, при согласовании действий с соответствующими органами соответствующей страны. С некоторыми странами заключены помимо общих, по части выдачи и проч. бла-бла еще и партнерские ведомственные соглашения, позволяющие ФБР в определенных случаях действовать в юрисдикции этих стран.
Навскидку по теме - https://ria.ru/society/20051012/41752859.html
Также ФБР может проводить оперативно-розыскные мероприятия за рубежом и в отношении неграждан США, если последние совершили преступления на территории США - опять же, всё упирается в конкретные соглашения.
Какая точка, какого отказа. Без DNS всё равно у вас HTTPS ни.
народ не понимает, что это делают не для их безопасности, а для финансовой безопасности неких инет-контор. это натягивание шифрование на все и вся рано или поздно выльется в то, что невозможно(или очень проблематично) будет блокировать непотребный пользователю контент. т.е. как минимум они хотят убрать возможность блочить рекламу на уровне днс и хттп. когда с этим закончат, в браузерах поменяют апи, чтобы невозможно было юзать блокировщики рекламы.
это нескоро будет, но будет.
Никто тебе не мешает поднять собственный прокси и блочить всё что угодно на уровне DNS и HTTP. Виндовые антивирусы имеют такую встроенную функцию.А чтобы недопустить блокировщиков рекламы на уровне API рассширений, надо так сильно его урезать, что возникнут успешные форки браузеров. Возможно, даже возглавляемые некоторыми из оригинальных разработчиков.
Финансовая безопасность? Лол.
> как минимум они хотят убрать возможность блочить рекламу на уровне днс и хттпуж не буду говорить про то что ни кто тебе не мешает наложить на исходный код браузера патч (и заметь -- ПАТЧ а не ФОРК).
вместо этого скажу -- ни кто тебе не запрещает НЕ ПОСЕЩАТЬ сайты реклама на которых тебя раздражает.
А не похер бы, если всем это в плюс?
Хорошая штука, если действительно вбедрится и будет стабильно работать. Но Боже, сколько соплей в комментах - эти люди не въезжают что SSL/TLS это уже давно не про HTTPS, а про те новые протоколы вроде MQTT на которых сейчас "умная" электроника вертится и её сейчас будет всё больше и больше, и там вы как пользователь/потребитель на вашу безопасность сами повлиять не можете, если разработчик за вас не позапотился. И государству как раз весь этот траффик вполне по барабану, а вот всяким "хацкерам", реальному криминалу и всяким биг-дата-социнженерам очень даже интересен.
> а про те новые протоколы вроде MQTTгде там sni и зачем он нужен умному дому ("ключи от всего у кого-то поумнее чем хозяин" (c) ?
серьёзные IoT сейчас работают с облаком через SSL/TLS, SNI необходим чтобы трафик между нодами балансировать
в том смысле что заточенное под IoT облако обеспечивает N сервисов (виртуальных хостов) с М нод, и всё это нужно правильно балансировать.
вы что-то пургу несете. Какой именно промышленный балансер работает на основании такой ерунды как sni, чтоб не вляпаться ненароком?И что мешает вместо этого использовать банальный dns по его прямому назначению - у вас в ipv6 снова недостаточно адресов?
может здесь лучше объяснят: https://aws.amazon.com/de/blogs/aws/new-application-load-bal.../
> может здесь лучше объяснятнет, здесь не лучше - у них sni используется по прямому назначению, чтобы напихать на один балансировщик мильен хостов с разными зачем-то сертификатами. Балансировщик этот траффик честно расшифровывает. Ну мало ли, какие у людей бывают странные идеи - купил на амазоне балансер, решил поделиться с друзьями, почему же нет. До этого они как раз sni не поддерживали.
где тут вы узрели балансировку ПО sni и причем тут вообще iot и шибкоумныедома, которым и одного домена (может с сабдоменами, но и это необязательно) достаточно - совершенно неясно.
если конкретно вы, зачем-то, при разработке такой системы наплодили несвязанных доменов, выписали на них все отдельные сертификаты, а потом начали с этим героически бороться - то так и скажите, тут все свои, подумаешь, обляпался.
именно по тому же назначению: организующая свое облако компания (или арендующая кусок облака у амазона) делает это не для своей забавы, а чтобы продавать сервис клиентам - иногда конечным пользователям, но чаще B2B заказчикам, а они уж потребителям. Получается, что на каком-то числе нод хостится какое-то число _независимых_ проектов, чаще всего больше одного, соответственно на проект минимум один домен и свой сертификат. В случае классического веба и https обычно нагрузка на ноду была достаточная чтобы каждая отдельная нода обслуживала только один проект (сервис), скалировались они горизонтально. Для IoT это неразумно, там нагрузка по другому распределяется, например важно иметь десятки тысячи открытых tcp соединений без потери латентности, но по которым относительно редко что проходит. Поэтому для IoT используется другая структура, ноды вполне скалируются вертикально (по несколько сервисов на ноду, на разных портах или IP например), а балансируют это все софтверные прокси (несколько выделенных нод на всё облако), которые же умеют ssl и tls эффективнее чем сами app- ноды, и админить там это удобнее. И как вы теперь такую структуру без sni сделаете?
"DNS-over-HTTPS или DNS-over-TLS" - АНБ радо.
Оно и будет держать под колпаком те несколько таких серверов.
А то они было запереживали что отдали совсем контроль за инетом в виде ICANN, а теперь они ещё и DNS сделают чтобы только через них работал, и смогут выключать инет любому когда захотят.
Потихоньку растёт число DoH/DoT серверов от энтузиастов из разных стран.
А ты прямо вот так доверяешь всем незнакомцам на улице ключи от хаты?
А что, вы таки уже внедрили свою альтернативу DNS, как водится, с блекджеком и шлюхами?
Мне не требуется скрывать факт обмена информацией с сайтами.
А если потребуется я воспользуюсь тором или и2п, а не будут фигнёй страдать.
Ещё один "честный человек" которому "нечего скрывать".
Не так.
Все эти навороты излишни и бессмысленны.
У меня свой unbound но я не включал и не настраивал dnssec потому что в этом нет смысла: сайты где деньги имеют сертификат, а на остальное мне плевать.Мозилла вообще давно хотела встроить тор в браузер, а вместо этого страдаёт фигнёй и костылями вокруг DNS.
Остальные участники могли бы сделать так же.
В тор эти проблемы решены кой как.Но они упорно двигают костыли, которые дадут им рычаги влияния.
Думаешь все эти участники не поднимут у себя эти сервера и не прибьют на гвозди в софте?
Это первое что они сделают, и после этого будут видеть каждый шаг каждого юзера, а кого надо смогут куда надо заворачивать или отключать.Я за открытый веб, а весь этот TLS, DNSSEC - оно прямо про обратное, концентрация ключевых элементов инфраструктуры в одних лапах.
Думаю им очень понравились результаты работы 8.8.8.8 и теперь хотя осчастливить всех насильно.
> Все эти навороты излишни и бессмысленнывспомните об этом пожалуйста когда станете покупать какие-нибудь радио-включаемые розетки или настольные лампы с доступом со смартфона, управляемые со смартфона и голосом электро- жалюзи на окна, вентиляторы, регуляторы отопительных батарей, мотор для гаражных ворот, может ещё какой гаджет из списка "Device modules" на https://fhem.de/commandref.html (хотя там на fhem всё устаревшее на пару лет). Это всё ведь реально становится так удобно, когда всю старую и новую домашнюю электронику можно включать не вставая, со смартфона, который и так всегда в кармане, правда? Или там уходя из дома статус посмотреть, не забыли и чего?
И как вы на всю эту разнородную мелочь свой tor пихать будете?
> вспомните об этом пожалуйстая об этом каждый раз вспоминаю, когда выясняется, что еще один поставщик модулей для x10 кончился.
Но нет, оборудования, зависимого от чужих клаудов, в моем доме не будет никогда.
(в том числе, кстати, потому что уже были истории, как людям приходилось выковыривать шибкоумные розетки, регуляторы, водяные вентили и прочее, что нельзя вот так просто и быстро заменить, потому что производитель контроллера внезапно взял и закрыл свой сервис - а контроллер без него ни чихнуть, ни пёрнуть не может)
Я такой хлам никогда не куплю, разве что на запчасти.
У меня даже смарт телеку инет запрещён, потому что задрал ставить виджеты вендора.
И это ещё старый смарт тв, без камеры и микрофона.В остальном, у меня маленькая квартира а я пока здоровый человек, поэтому мне проще встать, подойти и вкл/выкл, чем дрюкать пальцем в экран. Вот пду от телека и вентилятора удобно - можно даже глаза не открывать, а сенсорный экран - отстой.
> Я такой хлам никогда не куплю, разве что на запчасти.не зарекайся, не зарекайся.
телек-то еще может работать без интернета. А эти хоменетовские железяки - _в_принципе_ не могут - НЕТ у тебя прямого доступа к управлению.
что там творится в мозгах у их разработчиков - съедены гуглем, или это они так заботятся о пользователях, хз. Но найти полноценную систему умного дома, способную хоть как-то работать изолированно - даже не пытайся. Сразу бери паяльник и ардуину. До тебя уже сто раз искали.
> что там творится в мозгах у их разработчиковэто всётаки как-то больше у маркетологов и продуктманагеров мозги так заточены, а разрабы-то обычно люди подневольные, делают как начальство скажет. У меня вот ровно в прошлом году такой проект был где до заказчика наконец доперло что отказавшись от тотальной интернетозависимости они заполучат ещё несколько процентов дополнительных покупателей, поэтому они пришли к нам уже с запросом что смартфон должен уметь работать с их железяками приоритетно через локальный вайфай, облако опционально. Интересный получился проект, крутилось на локальном wifi-gateway со слегка подпиленным mosquitto, avahi там итд.. Жаль сорвался проект - пробники я им сделал, заплатили неплохо, но потом увели их у нас кто-то покрупнее. Ждем встретить их на рынке :)
> А если потребуется я воспользуюсь тором или и2пправильно, чтобы мы сразу увидели, что к тебе надо заглянуть на огонек.
Весь смысл избавления от sni, если ты не понял, был (бы, если бы я не нажал кое-какие рычажки) именно в том, что невозможно нормально отличить, котиков ты смотришь, как предыдущие десять лет что мы за тобой наблюдаем, или тебе уже потребовалось заниматься вредной антигосударственной деятельностью.
И как они представляют себе работу виртуальных хостингов в таких условиях?
Элементарно. Вывешивается фронтинг, далее балансер как анализировал SNI, так и продолжит.
Без SNI тоже можно понять что там хостят, отсутствие SNI не панацея. ISP будет анализировать по IP.
понять можно, пришить к делу нельзя.
Сколько сайтов висит на одном IP от cloudflare? :-)
MITM от FSB не проблема.
> MITM от FSB не проблема.Истеричный государственный бомбеж Телеграма говорит как раз об обратном.
Если бы не было проблемы, то просто прослушивали бы, и все.
нуну ) А дальше alt-svc quic="www.example.com:443";
Вот единственное, что реально во всём этом пугает - всё нарастающая сложность. На старые бородатые технологии все накручивается и накручивается слоями, будто матрешку пакуют. Я понимаю, что обратная совместимость. Но сложность - это плохо
+1. Невозможно доверять технологии слишком сложной для понимания.
доверять причём во всех смыслах. Даже если делали без закладок, в сложной куда выше шанс непреднамеренной ошибки, просто из-за сложности
В чём сложность? В необходимости прочитать один public key с DNS?
> Я понимаю, что обратная совместимость.о чем вы, я вас умоляю? Никому обратная совместимость не нужна в современном мире.
У вас все равно может быть только самая распоследняя версия браузера и самая распоследняя версия чегонибудьssl, иначе вы полезете на мой ценный хомячок по неправильному tls <1.3-драфт-еще-не-дописали протоколу, и он вас не пустит (и даже не потому что я принципиальный козел, а потому что докер-образ обновился)> Но сложность - это плохо
вам - плохо, товарищмайору - неплохо.
> Никому обратная совместимость не нужна в современном мире.Ага, а почему тогда почему нельзя спроектировать протокол с нуля, без реликтов истории? Ведь вы же говорите, что не нужна обратная совместимость.
Под низом любого tls всё равно лежит старый добрый http, и никто движок браузера на рендеринг чего-то ещё переписывать не будет. А tls сам лежит под старым добрым tcp, ну и т.д. Обратная совместимость правит миром!
> вам - плохо, товарищмайору - неплохо.
Да что вы со своим майором всё время, как будто ему делать нечего как вот за вами персонально следить. Кроме майора есть ещё много всяких субъектов и факторов.
> Ага, а почему тогда почему нельзя спроектировать протокол с нуля, без реликтов истории?можно, там выше в теме есть пример.
Просто мозила не хочет, а вам не дадут (спроектировать дадут, не дадут возможности широко распространить)> Под низом любого tls всё равно лежит старый добрый http
ой...
> необходимо знать закрытый ключ клиента или сервераА который из серверных ключей, если имя сервера клиент ещё не указал?
Имеется в виду пара к esni public.
Но вот для всяких автаркий типа известных "блокировщиков" телеграма это будет реально не eSNI, а soSNI. И это радует.
Для отбитых идиотов поясняю:1. Кто хотел что-то скрывать - давно скрывает и делает это успешно и тихо, а не как идиот Дуров, который зачем-то мазолит глаза органам своими публичными заявлениями.
2. Как сотрудник провайдера истинно не понимаю чему тут школьники и идиоты радуются - данное нововведение приведёт только к ухудшению ситуации с блокировкой по спискам РКН. РКН, думается мне, тупо будет блочить по ip в этом случае. Кто пострадает? Мы же. Чему вы радуетесь, болезные?
> Для отбитых идиотов поясняю:бестолку. Тут и условно-вменяемые радуются, пляшут и поют... :-(
и очень навряд ли Дуров - идиот, у идиота не может быть овер2k BTC не считая прочего нажитого "честным трудом" бабла. Скорее он работает ровно на тех же прекрасных людей, вполне сознательно. Вот насчет Жарова есть сомнения.
> и очень навряд ли Дуров - идиот, у идиота не может быть
>Скорее он
> работает ровно на тех же прекрасных людей, вполне сознательно. Вот насчет
> Жарова есть сомнения.И этот оже работает. И тоже на прекрасных людей. Цветы цветут, какие сомнения-то?
> И этот оже работает. И тоже на прекрасных людей.этот может быть искренне верующим, такое случается. В отличие от того, который с 2k BTC - так точно не бывает.
Пусть "блочит по IP". Подмена адресов в "заблоченных" доменах очень быстро отучит от сего действия.
Ну и общий эффект от таких "блокировок" будет уже приличным. Не вижу особой беды, если эти блокировки превратятся в полное дерьмо.
> Пусть "блочит по IP". Подмена адресов в "заблоченных" доменах очень быстро отучит
> от сего действия.Не отучила. Они уже составили белый список из 3-ёх IP, президент.ру, 127.0.0.1 и их хост раздачи блокировок. Теперь всё работает[I]!
Так это вообще отлично.
> Пусть "блочит по IP". Подмена адресов в "заблоченных" доменах очень быстро отучит от сего действия.Да ничему не научит. Есть решение суда, есть запись в реестре РКН согласно этому решению. Нет на данный момент процедур, которые бы быстро этот ip от туда убрали на основании того, что "там блокируется ещё куча всего невинного". Страдать будут пользователи. Надо просто понимать элементарные особенности работы законов и т.п. Вот что бы такого не было было хотя бы SNI - теперь не будет. Судьи, вообще, ни разу не подкованы технически. Даже близко. Они выносят решение на основании имеющихся бумаг и есть ли техническая возможность блокировать именно этот ресурс без вреда для других на том же ip, они понятия не имеют. Блокируй и всё.
Ну и отлично. Нет, так нет, значит будете стрелять себе в ногу до упора.
Половые проблемы конкретной гондурасии - не повод всем остальным зацикливаться на этих самых половых проблемах. Мир двигается вперёд, не желающие - остаются.
Ты чё в спячке был последние 4 месяца? Почти 20 миллионов айпишников было в блокировке. Именно айпишников, диапазонами тупо. Никаких доменов. И блочились они по айпишникам, независимо от SNI. И до сих пор не все провайдеры имеют DPI. А ещё парадокс в том, что весь трафик провести через DPI могут себе позволить только мелкие провайдеры, а крупные нет. Послушай Кулина https://www.youtube.com/watch?v=YccwFWiSryY
И до сих пор 3 миллиона айпишников амазона заблокированы. Что ты несёшь, болезный? Хуже не будет.
> А ещё парадокс в том, что весь трафик провести через DPI могут себе позволить только мелкиедружище, ну а тебе-то зачем зарплату платят?
Тебе надо детально разжевать, что нужен вовсе не "весь", и даже не 1/10 его часть?
Саботажник ты хренов, надо на тебя товарищмайору накапать, глядишь, мне скидка выйдет...
> Ты чё в спячке был последние 4 месяца? Почти 20 миллионов айпишников было в блокировке. Именно айпишников, диапазонами тупо. Никаких доменов. И блочились они по айпишникам, независимо от SNI.Ты мне-то не рассказывай :-). Я это своими глазами видел :-).
> Хуже не будет.
А-ха! Откуда вы, такие оптимисты, берётесь?.. Поверь - будет. Если SNI превратиться в тыкву, блокирование 20 миллионов ip покажется тебе сказкой.
Сейчас:Entries count: 108565
blockType default: 44235
blockType domain: 59570
blockType ip: 1924
blockType ipSubnet: 26
blockType domain-mask: 2810Если SNI сгинет, то 59570 доменов превратятся в ip/ipSubnet тип блокировки. Сам догадаешься что получится?
Забыл туда ещё добавить domain-mask 2810, которые тоже в перспективе станут ip/ipSubnet.
Охеренно получится. Может хоть до кого-то дойдёт, что масштабные блокировки - зло.
> Если SNI сгинет, то 59570 доменов превратятся в ip/ipSubnet тип блокировки. Сам догадаешься что получится?Что же получится? 60-100-300 тысяч айпишников добавятся в блокировку? Ух, как страшно. Когда там 3 миллиона крупнейшего облака по сей день. Это капля в море, даже заметно не будет. Напугал ежа голой жопой.
20 миллионов сравнятся только с 30 миллионами. Не надо запугивать, товарищ майор, мы за шифрование SNI.
> А ещё парадокс в том, что весь трафик провести через DPI могут себе позволить только мелкие провайдеры, а крупные нет.:-D Парадокс в том, что мелкие себе просто DPI позволить не могут :-). Крупные как раз таки норм. У них бабла навалом.
Это не так. DPI приходится покупать всем. И как говорится в видео выше, мелкие провайдеры купили DPI на 10-15 гбит, и пускают туда все свои 10 гбит. Крупным как раз не норм, у них трафика навалом и это очень дорого для них.