Блог компании Qrator Labs
Высокая производительность
Информационная безопасность
IT-инфраструктура
IT-стандарты
Комментарии 72
+3
DNS-over-HTTPS

Все больше и больше HTTPS, с сертификатами, которым доверяет основная масса компаний, а не непосредственных пользователей.


Не это нужно, а нужен полноценный DANE. Чтобы можно было поставить свой DNS сервер (или использовать сервис того, кому доверяете) и разместить там сертификат, созднанный на компе в соседней комнате.


Пока HTTPS бегает с бодрый TLS1.3 и сертификатом подписанным 3й стороной — этот сертификат не обеспечивает защиту.


Что до ДНС — DNSSEC обеспечит получение юзером именно того самого, своего сгенерированного, сертификата.

0
DNSSEC обеспечит получение юзером именно того самого, своего сгенерированного, сертификата.

Да, и это тоже. С внедрением DNSSEC + DANE получится что центров авторизации CA и не надо и контролировать выпуск (для параноиков — просматривать трафик) не получится.
Конечно, доверие переносится на уровень регистратора домена, который будет ваши публичные ключи пушить в DNS, но, в любом случае, одним уровнем (не)доверия становится меньше.

+3
Есть такое понятие «триада CIA» (кстати, никакого отношения к Central Intelligence Agency aka ЦРУ не имеющее).

Грубо говоря, основные задачи дизайна, ориентированного на безопасность — это сохранение конфиденциальности (confidentiality), целостности (integrity) и доступности (availability). Так вот, DNSSEC ориентирован на целостность данных, обслуживаемых протоколом DNS, а DoH, DNSoTLS и DNSoQUIC — ставят своей задачей конфиденциальность (то есть защиту от человека-посередине, пассивно слушающего трафик) и доступность (то есть, охрану данных от человека-посередине, работающего с трафиком активно и умеющего сбрасывать те фрагменты данных, которые ему не нравятся).

C и A можно обеспечить и поверх DANE, но вот беда: DNSSEC будут разворачивать ещё минимум лет 10, а проблема активных людей посередине, ломающих Интернет направо и налево, чрезвычайно актуальна уже сейчас. В стране розовых пони мы бы, конечно, радостно подняли DANE и успокоились бы, но весь доклад-то, по сути, о том, что розовых пони на планете наблюдается категорический дефицит.

[CC: mxms ]
+1

Главная проблема с DANE сегодня это его поддержка клиентским софтом, а точнее её отсутствие. Навскидку только основные SMTP серверы её и реализовали.

0
  • На уровне серверов DNS: nsd и bind поддерживают.
  • Если смотреть dnsmasq, то тот отлично поддерживаетdnssec (у меня лаптопы и сервера резолвят через локальный dnsmasq, который резолвит с 8.8.8.8 c dnssec).
  • На уровне крупныз DNS хостингов — CF (cloudflare.com) и HE (dns.he.net) не поддерживают.
  • SMTP — постфикс поддерживает. А вот клиенты… тут все страшно.
  • На уровне софта — читал, что на firefox TLSA решалось плагинами. Как время будет, запилю свой сайтик на своем DNS со своими сертификатами
0

Из, что вы сейчас перечислили, клиентским софтом в смысле потребителя информации DANЕ, являются только SMTP серверы, о которых я упомянул выше. Exim и Postfix её имеют точно.
Я, в общем-то, коротенько описывал это некоторое время назад в своём блоге. Там же есть и о том, почему DNSSEC так плохо внедряется.
https://kostikov.co/tehnologiya-dane-bezopasnostj-cherez-dns

НЛО прилетело и опубликовало эту надпись здесь
+6
поднявший DANE сервер у себя на ноутбуке

Просьба не использовать термины смысл которых вы не понимаете. Спасибо.

НЛО прилетело и опубликовало эту надпись здесь
+5

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


у вас нет возможности проверить, что ответы dnssec — это действительно авторитетные сервера

Есть. Публичный ключ корневых серверов известен.


Ещё раз повторю свою просьбу.

НЛО прилетело и опубликовало эту надпись здесь
+2

Действительно, на уровне "сервер DANE на ноуте" я говорить не готов.

0

В начале важное определение: речь о доменах у регистраторов в чужих зонах.


Давайте подменять руками ответы, чего мелочится: https://dnssec-debugger.verisignlabs.com/habr.com



В случае с DANE цепочка 3-их лиц будет ограничена:


  • регистратор
  • держатель зоны
  • root dns
  • CA https

И все.


Правильно, и любой Вася, поднявший DANE сервер у себя на ноутбуке, сможет этот траффик перехватывать.

Бред с гиктаймса. DANE — просто записи в DNS. Если Вася раздал свой собственный DNS всем подряд и заставил всех его юзать — тут и к бабке не ходи. Отдавай что хочу.
Если же Вася поставил на лаптоп dns +dnssec и установив у регистратора своего домена соотвуствующую запись, то в цепочке резолся DNSEC он будет зеленым.


Тут уже регистратор может атаковать, сменив запись. Но тогда он будет красным и будет как кто-то атаковал ДНС Васи (так как подпись не прошла). Соответственно клиенты ничего не получат.




Для остальных и кратно:


  • любой Вася может перехватывать траффик к своему серверу
  • любой, кто держит свой DNS без DNSSEC и вы его юзаете может слушать ваш траффик при активном DANE для https.
  • DANE это просто пачка DNS записей, только и всего
  • для защиты от спуфинга нужен активный DNSSEC
  • слабые точки: регистратор, держатель зоны и root dns.
  • решение проблемы регистраторы/держателязоны — зарегить свою зону за пару сотен килобаксов.
НЛО прилетело и опубликовало эту надпись здесь
+1
Ну все же предполагается, что DANE записи берутся только из валидного DNSSEC ответа. Иначе не имеет смысла использовать это.

На самом деле такие штуки не добавляют безопасности, а только уменьшают ее. Ради совместимости клиент будет поддерживать и DNSSEC с DANE и классический DNS + TLS + preinstalled CA. В результате поверхность для атак только увеличивается.

Плюс, DNSSEC говорит нам, что вместо кучки соревнующихся CA мы должны доверять корневым DNS серверам, которых не так уж и много, и которые находятся под контролем одной организации, но при этом раскиданы по миру. Например, в России есть несколько зеркал корневых серверов. Я и уверен, что правительство при желании сможет отжать приватные ключи этих серверов.

Короче, DNSSEC+DANE добавляет больше проблем, чем решает, как мне кажется.
0
Ну все же предполагается, что DANE записи берутся только из валидного DNSSEC ответа. Иначе не имеет смысла использовать это.

Верно.


Короче, DNSSEC+DANE добавляет больше проблем, чем решает, как мне кажется.

Неверно. Сейчас, в 2018 добавляется больше работы поднятия своего DANE, так как интересы CA-центров лоббируются и там большие бабки. В связи с этим его поддержки у "гигантов" нету.

0
Ну я бы не был так уверен насчет «больших бабок». Let's encrypt шагает по планете (и это отдельная проблема, кстати). Можете рассказать про интересы CA и лоббирование, кстати? Я знаю только несколько неприятных историй с тем же симантеком, или goddady, когда они подписывали то, чего подписывать не должны были. А вот про лоббирование не слышал ничего.

Как бы считается что централизация плохо, а децентрализация — хорошо. Но DNSSEC как раз приводит к централизации. Вы вынуждены доверять одному DNS root и всему что от него приходит. Компрометация этого ключа сломает весь Интернет. В то время как CA — натурально сотни и они конкурируют друг с другом (и с бесплатным LE).

Без DANE яйца лежат в разных корзинах: надо и подменить DNS ответ и раздобыть где-то валидный сертификат. С DANE мне будет достаточно скомпрометировать один ключ в цепочке от корневого ключа, до ключа сервера и все!

Более того, я не нашел в DNSSEC ничего напоминающего списков отзыва или сроков валидности ключа. Я так понимаю, что вместе этого предполагается положиться на TTL зоны. Что в свою очередь требует постоянного переподписания зоны. Что требует хранения приватных ключей в онлайне, что как бы не очень безопасно.
0
Более того, я не нашел в DNSSEC ничего напоминающего списков отзыва или сроков валидности ключа.

Срок действия ключей не регламентирован, однако есть рекомендации по срокам и их ротации. Зато сами записи цифровых подписей (RRSIG) вполне себе сроки действия имеют. Именно с этим и связана необходимость периодической переподписи.
Ключи в онлайне хранить не надо, конечно же. Можете хранить в защищённом хранилище.


Но DNSSEC как раз приводит к централизации.

В смысле что всё замыкается на подпись корневой записи то да. Но нет в смысле децентрализации самой системы хранения и обмена ключами. DNS иерархичен но децентрализован.

0
Вот это:
Именно с этим и связана необходимость периодической переподписи.

Конфликтует с этим:
Ключи в онлайне хранить не надо, конечно же. Можете хранить в защищённом хранилище.


Если, допустим, TTL у подписи 10 минут, то каждых 10 минут (на самом деле чаще) вам нужен будет приватный ключ, чтобы сделать новую подпись. Если TTL у подписи один месяц, то конечно можно хранить ключ и оффлайн. Но за месяц всякое может произойти…

Вот что говорит ICS:

However, we do not suggest longer than a week nor shorter than an hour for most TTL values which are not expected to change rapidly


Каждую неделю возится с оффлайновым хранилищем… Ну не знаю…

DNS иерархичен но децентрализован.

Если у меня домен в зоне .com, то я из нее уже никуда не денусь. И если я смогу сменить CА, если меня не будет устраивать текущий, то провайдера зоны .com я не сменю, как бы не хотел.
0

Никто и не обещал что будет легко.
Вообще, конечно, DNSSЕС и иже с ним не самая простая и логичная технология.
Но кто без греха? ;-)
В любом случае, любить DANE надо лишь только за то, что она способна выпилить CA как лишнее звено.


Если у меня домен в зоне .com, то я из нее уже никуда не денусь.

Не надо передёргивать. Вы и сейчас никуда не денетесь.

0
  • Если регистратор сменил NS, то все пойдет коту под хвост.
  • Если текущий DNS сменил A/AAAA записи и TLSA, то аналогично, все пойдет под хвост.
  • Если текущий CA выпустил сертификат Васе, то все пойдет тому же коту под хвост в свете без DNSSEC на кастрированный безdnssec клиентах.

И пофигу DANE или обычный HTTPS.


Теперь: сам себе CA — это с DANE.
Условие: все юзеры юзают DNSSEC.
В итоге: свой DNS, DNSSEC, вся цепочка подписей правильная.
В идеале — своя зона и свой домен для себя любимого уж. Иначе остается уязвимость через регистратора.


Но уже от CA мы избавились.

0
Во первых, светлое время, когда «юзеры юзают DNSSEC» придет в лучшем случае лет через 10. Пока что придется поддерживать оба механизма.

Прямо сейчас есть две уязвимых точки: свой приватный ключ и rogue CA. К счастью, CA много, они конкурируют друг с другом, к тому же уже есть опыт выноса «плохих» CA из списка доверенных (как это было с Симантеком). Короче, им есть чем дорожить.

Теперь мы исключаем CA, зато вместо него вводим регистратора. Чем регистратор лучше СА в данном случае — непонятно. Мы в любом случае должны доверять или одному или другому. Но теперь мы должны доверять еще и оператору домена (например .com управляется тем же Verisign, который очень даже коммерческая операция и один из крупнейших CA). И мы должны доверять корневой зоне.

Короче, мы заменяем СА на регистратора и добавляем еще несколько организаций в цепочку.

В чем же профит? В возможности использовать самоподписанный сертификат на сервере?

Конечно да, можно купить свою зону и укоротить chain of trust до одного элемента. Сколько компаний в мире может позволить себе такое?
0
Короче, мы заменяем СА на регистратора и добавляем еще несколько организаций в цепочку.

Регистратор никуда не девается и в случае обычного HTTPS.


Конечно да, можно купить свою зону и укоротить chain of trust до одного элемента. Сколько компаний в мире может позволить себе такое?

Читаем внимательно, ну… или гуглим.

0
Регистратор никуда не девается и в случае обычного HTTPS.


Но регистратор не сможет скомпрометировать соединение клиента с сервером. Он может подменить NS, A/AAAA, но без DANE он не сможет стать MitM, поэтому мы не обязаны ему доверять.
+1

Что-то вы недопонимаете.


  1. Ситуация когда нет DNSSEC/DANE. Регистратор меняет ваши NS на свои и делает что хочет. TLS-сертификат тут не поможет — выпустит новый. DNS то под контролем.
  2. Ситуация когда есть DNSSEC/DANE. Всё точно так же, только не надо обращаться к стороннему CA за сертификатом.
    Ничего не меняется, за исключением выпадания CA из процесса.
0
Да, действительно. О том что контролируя DNS можно получить сертификат я не подумал.
0

Именно! Кратно и ясно передана мысль.


Главная цель DANE — отказ от чужих CA. Это не панацея от угроз, но сея технология позволяет устранить одно из звеньев, которые могут потенциально скомпрометировать ресурс.


Далее — можно отказатся и от регистратора. Использовать RDNS хостера и выдав себе сертификат на этот rdns и на айпи (такое можно).


Тем самым остается хостер (высшая точка доверия и контроля), следом root DNS и… все.

0
Если злоумышленник сможет подменять DNS-ответы, то он сможет делегировать домен себе (подменить NS-записи), а затем поставить
свои A-записи и выписать сертификат у любого CA (пройдёт domain validation).
0
Let's encrypt шагает по планете

Признаться, меня темп этого "великого похода" уже начинает напрягать. Слишком уже много всего сложено теперь в эту большую корзину.

0
Ага, я там не зря написал в скобках, что это само по себе проблема.
НЛО прилетело и опубликовало эту надпись здесь
0
DANE без бекапа в виде классического x509 — это single point of failure + отсутствие поддержки устройствами в течении ближайших лет 10.

DANE с запасным сертификатом x509 — безопасность в два раза ниже (достаточно подделать что-то одно из двух).

Мне кажется, что уже прошло время революций в интернете. От IPv4, SSL/TLS (с PKI), TCP/IP — уже никуда не деться.
0
Например, в России есть несколько зеркал корневых серверов. Я и уверен, что правительство при желании сможет отжать приватные ключи этих серверов.

Нет, не сможет. Это именно что зеркало.
Почитайте, кстати, как работают и как хранятся приватные ключ корневых серверов. Там всё как надо организовано.

0

Вижу что за этим форсированием темы DNS-over-HTTPS вместо, казалось бы, самого логичного DNS-over-TLS, стоит тот же Google который хочет завернуть весь мир в свой Chrome (OS).

+2
Ну, вообще авторами черновика DoH числятся Пол Хоффман из ICANN и Патрик МакМанус из Mozilla. Ну и к процессу создания очень много людей приложило руку, вроде Стефана Борцмайера, никакого отношения к Google не имеющих.

Процитирую цели документа:
Two primary uses cases were considered during this protocol's
development. They included preventing on-path devices from
interfering with DNS operations and allowing web applications to
access DNS information via existing browser APIs in a safe way
consistent with Cross Origin Resource Sharing (CORS) [CORS]. No
special effort has been taken to enable or prevent application to
other use cases. This document focuses on communication between DNS
clients (such as operating system stub resolvers) and recursive
resolvers.

Собственно, плагин для Firefox (начиная с версии 57 Quantum), осуществляющий DNSSEC-валидацию, именно на DoH и основан. Так как голое socket API в Quantum дополнениям недоступно, то это, фактически, был единственный способ это реализовать (старый плагин от CZ.NIC Labs больше не работает).
0
у, вообще авторами черновика DoH числятся Пол Хоффман из ICANN и Патрик МакМанус из Mozilla

В данном случае интересы Mozilla совпадают с Google (вспоминаем Firefox OS).

0
Сравните DNS over TLS и DoH тут, например: dnscrypt.info/faq
Questionable practical benefits over DoH

С голым TLS просто сложнее, похоже. Поэтому DNSCrypt 2 поддерживает свой собственный протокол и DoH, а не TLS: github.com/jedisct1/dnscrypt-proxy/issues/68
Implementing DNS-over-TLS is not planned since it provides no benefits over DNS-over-HTTP/2.
0

Сложнее кому? Браузеру? Да, возможно.
Софту не использующему HTTP? Вряд ли.
Вместо того, чтобы внедрить DNS-over-TLS, что будет незаметно для клиентского софта, предлагается втащить DoH куда только руки дотянутся путём перелопачивания всего и вся.
Бред.

0
DNSCrypt

После изучения этого протокола у меня возникло стойкое ощущение, что его лепили из того, что было на тот момент под рукой. Жуткая смесь из прокси, кусков DNSSEC, TLS и HPKP. Спасибо, не надо.

-1
Банкир порадовал! «А как же шпионить за своими?» А ему в ответ: «Никак, ибо нефиг».

DNSSEC'a не будет, пока Микрософт не станет поддерживать записи DNS в своем модуле DNS Server, необходимых для его работы, а если меня не глючит, то самая новая запись по типу, из того, что умеет вообще Microsoft DNS, это SRV, где-то 2003 года выпуска. Пихать последовательность октетов, может, и можно, но совершенно неподдерживаемо.
+1
DNSSEC'a не будет, пока Микрософт не станет поддерживать записи DNS в своем модуле DNS Server

Вообще-то они его поддерживают очень давно. Начиная с Windows Server 2008R2.

+1
А что, поддержка DNSSEC куда-то делать из их серверов? 2012R2 умел с рождения. И свои зоны подписывать, и чужие проверять. SRV, TXT и прочие, впрочем, тоже никуда не делись.
НЛО прилетело и опубликовало эту надпись здесь
0

Вы очень кстати затронули тему CDN, хотя и не совсем в русле дискуссии по содержанию статьи. Мне кажется что степень опасности этих сервисов в части угроз приватности сильно недооценена.

0
Я присоединяюсь, читается очень интересно, интересные цитаты и примеры.
+2
Если абстрагироваться от технических аспектов, можно прийти к интересному выводу, что QUIC — это отличный способ для Гугла полностью исключить возможность какой-либо выборочной приоритизации трафика к своим сервисам, поскольку для провайдера это просто поток шифрованного UDP-мусора, и никакого хостнейма в текстовом виде там не передаётся. Соответственно, голубые мечты операторов связи резать Ютуб на мобильных подключениях уже накрылись медным тазом, и процент трафика по 443/udp только растёт.

Более того, даже если кто-то всё-таки научится определять категорию QUIC-трафика или выцарапывать хостнейм, Гугл может просто обновить протокол, обновить все Хромы и андроидные приложения в течение пары недель, и снова обломать кайф операторам связи.

И это ещё сейчас обыгрывается упрощённая ситуация, когда QUIC-трафик может ходить только по 443 порту (не пытайтесь поднимать тестовые серверы на других портах, в Хроме это ограничение прибито гвоздями). Когда они уберут это ограничение, будет гораздо веселее.
0
В принципе ничего, кроме того, что при этом могут отвалиться другие более важные сервисы, типа Gmail или Google Play. Конечно, шейпить так или иначе будут, других вариантов нет, но невозможность определения вида трафика сильно связывает руки и не даёт зарезáть адресно именно то, что мешает.

Только вряд ли это будет именно шейпинг по IP сервиса, т.к. владелец сервиса может перенаправлять клиента куда угодно, и связать два подключения друг с другом провайдер не сможет. Скорее уж будут ограничивать весь трафик пользователя целиком. А это уже серьёзный костыль, который испортит жизнь массе людей.
0
отвалиться другие более важные сервисы, типа Gmail или Google Play.

А что отвалятся? Письмам много не нужно, а что софт по часу обновляется, так это сам гугл обвинять будут, ведь у пользователя 5G и 4 палки.
0
Да, тут была моя ошибка, основанная на вере в какие-то ранние статьи про QUIC. Послушал tcpdump, действительно, есть и хостнейм в открытом виде (один раз на соединение), и даже полный юзерагент.
0

SNI это про TLS а не про QUIC. И даже в v1.3 TLS передаёт эту информацию открытым текстом.

0
Насколько я понимаю, одна из основных целей QUIC на этот год — сделать поддержку одновременного использования нескольких каналов (multipath), чтобы на телефонах можно было одновременно обращаться по одному соединению и через LTE, и через Wi-Fi.
multipath-quic.org

Multipath TCP в Linux в плохом состоянии, патчи еще далеки от сливания с основным ядром, поддержка Multipath TCP есть только у Apple на iOS (не на десктопной macOS), и у Samsung, вроде бы. А Multipath QUIC позволит без обновления устройств использовать несколько каналов одновременно, что не получилось у Multipath TCP за все эти годы.
0
1) Речь идет о том, что бы балансировать трафик TCP или другого протокола транспортного уровня упомянутой модели OSI через каналы IP с разной (случайной) задержкой, джиттером, шириной, нагрузкой?

А при чем тут multipath TCP?
Насколько я понимаю, по правильному эта задача решается
1) упорядоченной буферизацией принимаемых пакетов
2) использование нескольких портов udp/tcp портов для балансировки сообщений приложений
3) использованием 2 маршрутов на сетевом уровне (IP). Т. е. использовать два destination или source ip-адреса, доступных по разным маршрутам. По которым работают и доступны приложения на РАЗНЫХ портах TCP (или UDP)
Например, веб сервис, доступный одновременно по двум разным парам ip
и порта 1.1.1.1:80 и 2.2.2.2:8080
DNS сервер может для домена раздавать оба IP адреса + вес маршрута к каждому из них.
Либо вес маршрута определяется протоколом (tcp/udp) и номером порта.
Плюс вес маршрута сетевого уровня.

2) Классная картинка. За исключением терминологии, соответствует 7 уровневой модели OSI и intel iot reference architecture.
— Kernel space обеспечивает? a) функционал транспортного уровня, используя номера udp и tcp портов для идентификации приложений и балансировки между маршрутами сетевого уровня по номерам портов приложений; b) сетевого уровня для балансировки трафика (данных) при прохождении через сеть
— прикладной уровень (приложения получают нужные данные и работают с ними)
— уровень пользователей для работы с приложениями.

На каждом уровне свои методы обеспечения безопасности и балансировки. Зачем смешивать разные уровни?..
image
0
1) Речь идет о том, что бы балансировать трафик TCP или другого протокола транспортного уровня упомянутой модели OSI через каналы IP с разной (случайной) задержкой, джиттером, шириной, нагрузкой?
Да.

А при чем тут multipath TCP?
Потому что это единственная работающая и стандартизированная на текущий момент технология для объединения нескольких каналов без необходимости особых настроек на оборудовании пользователя или провайдера пользователя.

Насколько я понимаю, по правильному эта задача решается упорядоченной буферизацией принимаемых пакетов и использованием 2 маршрутов на уровне IP. Т. е. использовать два destination или source ip-адреса, доступных по разным маршрутам.
Это и делает Multipath TCP, только еще и делает так, чтобы для приложения это выглядело обычным одним TCP-соединением.

На каждом уровне свои методы обеспечения безопасности и балансировки. Зачем смешивать разные уровни?..
Они не работают через интернет, без дополнительных настроек на стороне провайдера или клиента. А Multipath TCP и Multipath QUIC — работают.
0
Было бы правильнее разделить на:
— Kernel space/level/layer
— transport/network space/level/layer
— application space: balancing level
— application space/level/layer
— user space/level/layer
0
Одним соединением неправильно. Лучше двумя. Или потребуется выделить промежуточный подуровень между транспортным протоколом и приложением для балансировки.
Хотя так даже лучше будет выглядеть.
Зафиксировал тут, может когда-нибудь пригодится.
0
Это же очень медленно. Там же сейчас вроде UDP запрос, ответ. Можно было сразу эти пакеты шифровать, подписывать. А так нужно будет соединение устанавливать, обмениваться ключами. В десять раз время запроса увеличится.
+1
Чтобы начать шифровать пакеты, надо сначала установить общий секрет. Да и аутентифицировать противоположную сторону было бы неплохо. Поэтому и надо сначала поперекидываться хендшейками. Собственно, TLS стремится свести размер хендшейка к минимуму.

Вот если бы можно было делать DH в тех же TCP пакетах, где ходит SYN, SYN/ACK, ACK — было бы очень круто.
0
Зачем устанавливать общие секреты и аутентифицировать противоположную сторону? Задача DNS — получить из домена IP и тут мы ещё хотим что бы наш айпи не подменили и что бы об этом никто не узнал.
Мы имеем сертификат DNS сервера с его открытым ключом.
Отправляем серверу запрос шифруя его открытым ключом. В запросе домен и пароль для ответа.
DNS отвечает шифруя пакет полученным ключом и подписывает его своим закрытым ключом.
Всё. Что ещё нужно?
0
А, я думал вы про QUIC.

DNSSEC почти так и работает, как вы описали. Если не считать того что он не шифрует данные, только подписывает. Основные протоколы интернета вообще слабо приспособлены для борьбы с намеренными блокировками.
0
Сейчас подумалось: есть к примеру пакет pdns который кэширует результаты + может использовать dnssec. Значит берем пару нод на амазоне и еще каком-то облачном провайдере. Там поднимаем pdns и все общение с ним заворачиваем в tor. Таким образом мы имеем верифицированные через dnssec адреса в кэше собственного DNS с которым общаемся по шифрованному протоколу. Прошу прощения за наивность, но может это и есть защита от MitM, блокировок и прочего творящегося в настоящее время беспредела?..
0
Ну тут собственно вводят DNS over HTTPS. Это почти то, что вы описали, только более упрощенно.

Но насколько я знаю, ваши провайдеры не ограничиваются только подменой ДНС ответов. Они в том числе блокируют доступ по IP. Тут уже поможет только VPN в другую страну.
0
Не смог найти информации. Поясните, пожалуйста, почему поиск по таблице маршрутизации для UDP занимает больше времени чем для TCP?
0

Т.е. достаточно прикрутить к sendmsg простейший кеш ("если dst не поменялся — работаем по старой схеме") — и всё будет просто летать?
Почему же это ещё не сделали?

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

> Стандарты IETF воспринимаются индустрией, как такие железобетонные документы, как могильная плита, фактически.

> Планируется, что они определяют развитие интернета и учитывают все возможные сценарии использования. То есть, если у нас была старая версия протокола, а потом появилась новая, то она точно сохраняет совместимость со всеми предыдущими юзкейсами и дополнительно решает кучу проблем, оптимизирует работу и так далее.

Те, кто реально реализовывал что-то на основании IETF RFC, знают, насколько те неполны, дырявы и противоречивы. Случаев столько, что задолбёшься перечислять, причём есть и в том, что числится стандартом. Отсутствие процедуры выпуска обновлённых версий спецификаций с учётом найденных багов (в принципе нет, например, выпуска какого-нибудь 822-2000, даже если весь мир знает, что в 822 логические дыры). Переусложнённость спецификаций, чрезмерная любовь к грамматикализации. Наконец, систематическая неполная реализация спецификаций вендорами (настолько, что во многих областях уже не ищут полной и корректной реализации, а просто ищут взаимодействия друг с другом — для SIP даже делали сессии, когда производители устройств съезжались и массово испытывали оборудование друг с другом).

Поэтому думаю, про «железобетонность» было художественным преувеличением, рассчитанным на дальнейшее восприятие доклада :)

Хохмы с неожиданным криптованием отлично укладываются в эту общую канву.

> Что важно: reverse proxy – это технология, которая начала активно использоваться порядка 13 лет назад. То есть это технология середины 2000 годов

Реально раньше: я в 98-м её видел (на squid и apache), и уже отлаженной.

> По результатам измерений, в нормальной ситуации, то есть при работе через беспроводную сеть, реализация протокола QUIC 58% времени проводит в Android в состоянии «Application Limited». Что это за состояние? Это состояние, когда мы какие-то данные отправили и ждем подтверждения. Для сравнения, на десктопах была цифра около 7%.

Тут непонятно, можно ли так сравнивать. В случае TCP подтверждением занимается ядро. Юзерланд может отправить ядру данные и не ждать дальше. Сравнивалось ли время полного цикла от начала запроса до финального байта ответа?

> Например, реализация QUIC от Google работает существенно хуже TCP, если в сети происходит packet reordering, то есть пакеты прилетают не в том порядке, в котором были отправлены сервером.

А что в этом случае происходит? Реализация просто дропает пришедшие не по порядку пакеты?

Но вообще мобильные сети — проблема. Я наблюдаю, что при быстром движении (например, телефон в поезде) происходит неограниченное накопление пакетов: пинг доходил до 150 секунд. Радиомодуль пытается перепосылать одно и то же по многу раз и не имеет нормального дропа пакетов, что сбивает логику всех протоколов транспортного уровня и выше, обычно рассчитанных на то, что IP не накапливает, а дропает.

> Сделано это было следующим образом: открывается «магический» поток номер 0, который отвечает за установку соединения, рукопожатие и шифрование, после чего этот поток 0 шифруется и все остальные шифруются тоже.

Я не понял вообще в их дизайне (начиная с HTTP/2), зачем им принципиальное отсутствие переиспользования потоков. По-моему, это усложнение кода. Как следствие, особая роль потока 0 реализуется более громоздко (от этого может быть и больше багов).

> Feedback от вас ожидается, все хотят его видеть.

Достаточно ли для этого участвовать в профильных рассылках IETF, по вашему опыту?
Крупные корпорации посылают своих людей на живые встречи, где финализируются решения. Это уже финальный кулуарный этап, на котором может быть принято совсем не то, что ожидалось по консенсусу обсуждений в рассылках. Боюсь, тут возникает «естественным» путём предпочтение решений, оптимальных для гигантов. Есть какая-то статистика по этому вопросу?
Только полноправные пользователи могут оставлять комментарии.  , пожалуйста.