Comments 75
DNS-over-HTTPS
Все больше и больше HTTPS, с сертификатами, которым доверяет основная масса компаний, а не непосредственных пользователей.
Не это нужно, а нужен полноценный DANE. Чтобы можно было поставить свой DNS сервер (или использовать сервис того, кому доверяете) и разместить там сертификат, созднанный на компе в соседней комнате.
Пока HTTPS бегает с бодрый TLS1.3 и сертификатом подписанным 3й стороной — этот сертификат не обеспечивает защиту.
Что до ДНС — DNSSEC обеспечит получение юзером именно того самого, своего сгенерированного, сертификата.
DNSSEC обеспечит получение юзером именно того самого, своего сгенерированного, сертификата.
Да, и это тоже. С внедрением DNSSEC + DANE получится что центров авторизации CA и не надо и контролировать выпуск (для параноиков — просматривать трафик) не получится.
Конечно, доверие переносится на уровень регистратора домена, который будет ваши публичные ключи пушить в DNS, но, в любом случае, одним уровнем (не)доверия становится меньше.
Грубо говоря, основные задачи дизайна, ориентированного на безопасность — это сохранение конфиденциальности (confidentiality), целостности (integrity) и доступности (availability). Так вот, DNSSEC ориентирован на целостность данных, обслуживаемых протоколом DNS, а DoH, DNSoTLS и DNSoQUIC — ставят своей задачей конфиденциальность (то есть защиту от человека-посередине, пассивно слушающего трафик) и доступность (то есть, охрану данных от человека-посередине, работающего с трафиком активно и умеющего сбрасывать те фрагменты данных, которые ему не нравятся).
C и A можно обеспечить и поверх DANE, но вот беда: DNSSEC будут разворачивать ещё минимум лет 10, а проблема активных людей посередине, ломающих Интернет направо и налево, чрезвычайно актуальна уже сейчас. В стране розовых пони мы бы, конечно, радостно подняли DANE и успокоились бы, но весь доклад-то, по сути, о том, что розовых пони на планете наблюдается категорический дефицит.
[CC: mxms ]
Главная проблема с DANE сегодня это его поддержка клиентским софтом, а точнее её отсутствие. Навскидку только основные SMTP серверы её и реализовали.
- На уровне серверов DNS: nsd и bind поддерживают.
- Если смотреть dnsmasq, то тот отлично поддерживаетdnssec (у меня лаптопы и сервера резолвят через локальный dnsmasq, который резолвит с 8.8.8.8 c dnssec).
- На уровне крупныз DNS хостингов — CF (cloudflare.com) и HE (dns.he.net) не поддерживают.
- SMTP — постфикс поддерживает. А вот клиенты… тут все страшно.
- На уровне софта — читал, что на firefox TLSA решалось плагинами. Как время будет, запилю свой сайтик на своем DNS со своими сертификатами
Из, что вы сейчас перечислили, клиентским софтом в смысле потребителя информации DANЕ, являются только SMTP серверы, о которых я упомянул выше. Exim и Postfix её имеют точно.
Я, в общем-то, коротенько описывал это некоторое время назад в своём блоге. Там же есть и о том, почему DNSSEC так плохо внедряется.
https://kostikov.co/tehnologiya-dane-bezopasnostj-cherez-dns
поднявший DANE сервер у себя на ноутбуке
Просьба не использовать термины смысл которых вы не понимаете. Спасибо.
Вы не понимаете проблематики, которую пытаетесь обсуждать.
Не хочу разбирать ваш пост по полочкам, чисто для примера.
у вас нет возможности проверить, что ответы dnssec — это действительно авторитетные сервера
Есть. Публичный ключ корневых серверов известен.
Ещё раз повторю свою просьбу.
В начале важное определение: речь о доменах у регистраторов в чужих зонах.
Давайте подменять руками ответы, чего мелочится: https://dnssec-debugger.verisignlabs.com/habr.com
- Это хабр:
- это зона
- а вот это те самые root dns
https://data.iana.org/root-anchors/root-anchors.xml
В случае с DANE цепочка 3-их лиц будет ограничена:
- регистратор
- держатель зоны
- root dns
CA https
И все.
Правильно, и любой Вася, поднявший DANE сервер у себя на ноутбуке, сможет этот траффик перехватывать.
Бред с гиктаймса. DANE — просто записи в DNS. Если Вася раздал свой собственный DNS всем подряд и заставил всех его юзать — тут и к бабке не ходи. Отдавай что хочу.
Если же Вася поставил на лаптоп dns +dnssec и установив у регистратора своего домена соотвуствующую запись, то в цепочке резолся DNSEC он будет зеленым.
Тут уже регистратор может атаковать, сменив запись. Но тогда он будет красным и будет как кто-то атаковал ДНС Васи (так как подпись не прошла). Соответственно клиенты ничего не получат.
Для остальных и кратно:
- любой Вася может перехватывать траффик к своему серверу
- любой, кто держит свой DNS без DNSSEC и вы его юзаете может слушать ваш траффик при активном DANE для https.
- DANE это просто пачка DNS записей, только и всего
- для защиты от спуфинга нужен активный DNSSEC
- слабые точки: регистратор, держатель зоны и root dns.
- решение проблемы регистраторы/держателязоны — зарегить свою зону за пару сотен килобаксов.
На самом деле такие штуки не добавляют безопасности, а только уменьшают ее. Ради совместимости клиент будет поддерживать и DNSSEC с DANE и классический DNS + TLS + preinstalled CA. В результате поверхность для атак только увеличивается.
Плюс, DNSSEC говорит нам, что вместо кучки соревнующихся CA мы должны доверять корневым DNS серверам, которых не так уж и много, и которые находятся под контролем одной организации, но при этом раскиданы по миру. Например, в России есть несколько зеркал корневых серверов. Я и уверен, что правительство при желании сможет отжать приватные ключи этих серверов.
Короче, DNSSEC+DANE добавляет больше проблем, чем решает, как мне кажется.
Ну все же предполагается, что DANE записи берутся только из валидного DNSSEC ответа. Иначе не имеет смысла использовать это.
Верно.
Короче, DNSSEC+DANE добавляет больше проблем, чем решает, как мне кажется.
Неверно. Сейчас, в 2018 добавляется больше работы поднятия своего DANE, так как интересы CA-центров лоббируются и там большие бабки. В связи с этим его поддержки у "гигантов" нету.
Как бы считается что централизация плохо, а децентрализация — хорошо. Но DNSSEC как раз приводит к централизации. Вы вынуждены доверять одному DNS root и всему что от него приходит. Компрометация этого ключа сломает весь Интернет. В то время как CA — натурально сотни и они конкурируют друг с другом (и с бесплатным LE).
Без DANE яйца лежат в разных корзинах: надо и подменить DNS ответ и раздобыть где-то валидный сертификат. С DANE мне будет достаточно скомпрометировать один ключ в цепочке от корневого ключа, до ключа сервера и все!
Более того, я не нашел в DNSSEC ничего напоминающего списков отзыва или сроков валидности ключа. Я так понимаю, что вместе этого предполагается положиться на TTL зоны. Что в свою очередь требует постоянного переподписания зоны. Что требует хранения приватных ключей в онлайне, что как бы не очень безопасно.
Более того, я не нашел в DNSSEC ничего напоминающего списков отзыва или сроков валидности ключа.
Срок действия ключей не регламентирован, однако есть рекомендации по срокам и их ротации. Зато сами записи цифровых подписей (RRSIG) вполне себе сроки действия имеют. Именно с этим и связана необходимость периодической переподписи.
Ключи в онлайне хранить не надо, конечно же. Можете хранить в защищённом хранилище.
Но DNSSEC как раз приводит к централизации.
В смысле что всё замыкается на подпись корневой записи то да. Но нет в смысле децентрализации самой системы хранения и обмена ключами. DNS иерархичен но децентрализован.
Именно с этим и связана необходимость периодической переподписи.
Конфликтует с этим:
Ключи в онлайне хранить не надо, конечно же. Можете хранить в защищённом хранилище.
Если, допустим, 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 я не сменю, как бы не хотел.
Никто и не обещал что будет легко.
Вообще, конечно, DNSSЕС и иже с ним не самая простая и логичная технология.
Но кто без греха? ;-)
В любом случае, любить DANE надо лишь только за то, что она способна выпилить CA как лишнее звено.
Если у меня домен в зоне .com, то я из нее уже никуда не денусь.
Не надо передёргивать. Вы и сейчас никуда не денетесь.
- Если регистратор сменил NS, то все пойдет коту под хвост.
- Если текущий DNS сменил A/AAAA записи и TLSA, то аналогично, все пойдет под хвост.
- Если текущий CA выпустил сертификат Васе, то все пойдет тому же коту под хвост в свете без DNSSEC на кастрированный безdnssec клиентах.
И пофигу DANE или обычный HTTPS.
Теперь: сам себе CA — это с DANE.
Условие: все юзеры юзают DNSSEC.
В итоге: свой DNS, DNSSEC, вся цепочка подписей правильная.
В идеале — своя зона и свой домен для себя любимого уж. Иначе остается уязвимость через регистратора.
Но уже от CA мы избавились.
Прямо сейчас есть две уязвимых точки: свой приватный ключ и rogue CA. К счастью, CA много, они конкурируют друг с другом, к тому же уже есть опыт выноса «плохих» CA из списка доверенных (как это было с Симантеком). Короче, им есть чем дорожить.
Теперь мы исключаем CA, зато вместо него вводим регистратора. Чем регистратор лучше СА в данном случае — непонятно. Мы в любом случае должны доверять или одному или другому. Но теперь мы должны доверять еще и оператору домена (например .com управляется тем же Verisign, который очень даже коммерческая операция и один из крупнейших CA). И мы должны доверять корневой зоне.
Короче, мы заменяем СА на регистратора и добавляем еще несколько организаций в цепочку.
В чем же профит? В возможности использовать самоподписанный сертификат на сервере?
Конечно да, можно купить свою зону и укоротить chain of trust до одного элемента. Сколько компаний в мире может позволить себе такое?
Короче, мы заменяем СА на регистратора и добавляем еще несколько организаций в цепочку.
Регистратор никуда не девается и в случае обычного HTTPS.
Конечно да, можно купить свою зону и укоротить chain of trust до одного элемента. Сколько компаний в мире может позволить себе такое?
Читаем внимательно, ну… или гуглим.
Регистратор никуда не девается и в случае обычного HTTPS.
Но регистратор не сможет скомпрометировать соединение клиента с сервером. Он может подменить NS, A/AAAA, но без DANE он не сможет стать MitM, поэтому мы не обязаны ему доверять.
Что-то вы недопонимаете.
- Ситуация когда нет DNSSEC/DANE. Регистратор меняет ваши NS на свои и делает что хочет. TLS-сертификат тут не поможет — выпустит новый. DNS то под контролем.
- Ситуация когда есть DNSSEC/DANE. Всё точно так же, только не надо обращаться к стороннему CA за сертификатом.
Ничего не меняется, за исключением выпадания CA из процесса.
Именно! Кратно и ясно передана мысль.
Главная цель DANE — отказ от чужих CA. Это не панацея от угроз, но сея технология позволяет устранить одно из звеньев, которые могут потенциально скомпрометировать ресурс.
Далее — можно отказатся и от регистратора. Использовать RDNS хостера и выдав себе сертификат на этот rdns и на айпи (такое можно).
Тем самым остается хостер (высшая точка доверия и контроля), следом root DNS и… все.
Кстати, радостная новость: cloudflare поддерживает TLSA.
свои A-записи и выписать сертификат у любого CA (пройдёт domain validation).
Let's encrypt шагает по планете
Признаться, меня темп этого "великого похода" уже начинает напрягать. Слишком уже много всего сложено теперь в эту большую корзину.
DANE с запасным сертификатом x509 — безопасность в два раза ниже (достаточно подделать что-то одно из двух).
Мне кажется, что уже прошло время революций в интернете. От IPv4, SSL/TLS (с PKI), TCP/IP — уже никуда не деться.
Например, в России есть несколько зеркал корневых серверов. Я и уверен, что правительство при желании сможет отжать приватные ключи этих серверов.
Нет, не сможет. Это именно что зеркало.
Почитайте, кстати, как работают и как хранятся приватные ключ корневых серверов. Там всё как надо организовано.
Вижу что за этим форсированием темы DNS-over-HTTPS вместо, казалось бы, самого логичного DNS-over-TLS, стоит тот же Google который хочет завернуть весь мир в свой Chrome (OS).
Процитирую цели документа:
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 больше не работает).
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.
Сложнее кому? Браузеру? Да, возможно.
Софту не использующему HTTP? Вряд ли.
Вместо того, чтобы внедрить DNS-over-TLS, что будет незаметно для клиентского софта, предлагается втащить DoH куда только руки дотянутся путём перелопачивания всего и вся.
Бред.
DNSCrypt
После изучения этого протокола у меня возникло стойкое ощущение, что его лепили из того, что было на тот момент под рукой. Жуткая смесь из прокси, кусков DNSSEC, TLS и HPKP. Спасибо, не надо.
DNSSEC'a не будет, пока Микрософт не станет поддерживать записи DNS в своем модуле DNS Server, необходимых для его работы, а если меня не глючит, то самая новая запись по типу, из того, что умеет вообще Microsoft DNS, это SRV, где-то 2003 года выпуска. Пихать последовательность октетов, может, и можно, но совершенно неподдерживаемо.
DNSSEC'a не будет, пока Микрософт не станет поддерживать записи DNS в своем модуле DNS Server
Вообще-то они его поддерживают очень давно. Начиная с Windows Server 2008R2.
Более того, даже если кто-то всё-таки научится определять категорию QUIC-трафика или выцарапывать хостнейм, Гугл может просто обновить протокол, обновить все Хромы и андроидные приложения в течение пары недель, и снова обломать кайф операторам связи.
И это ещё сейчас обыгрывается упрощённая ситуация, когда QUIC-трафик может ходить только по 443 порту (не пытайтесь поднимать тестовые серверы на других портах, в Хроме это ограничение прибито гвоздями). Когда они уберут это ограничение, будет гораздо веселее.
Только вряд ли это будет именно шейпинг по IP сервиса, т.к. владелец сервиса может перенаправлять клиента куда угодно, и связать два подключения друг с другом провайдер не сможет. Скорее уж будут ограничивать весь трафик пользователя целиком. А это уже серьёзный костыль, который испортит жизнь массе людей.
Хм, а как там реализован SNI?
multipath-quic.org
Multipath TCP в Linux в плохом состоянии, патчи еще далеки от сливания с основным ядром, поддержка Multipath TCP есть только у Apple на iOS (не на десктопной macOS), и у Samsung, вроде бы. А Multipath QUIC позволит без обновления устройств использовать несколько каналов одновременно, что не получилось у Multipath TCP за все эти годы.
А при чем тут 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) сетевого уровня для балансировки трафика (данных) при прохождении через сеть
— прикладной уровень (приложения получают нужные данные и работают с ними)
— уровень пользователей для работы с приложениями.
На каждом уровне свои методы обеспечения безопасности и балансировки. Зачем смешивать разные уровни?..
1) Речь идет о том, что бы балансировать трафик TCP или другого протокола транспортного уровня упомянутой модели OSI через каналы IP с разной (случайной) задержкой, джиттером, шириной, нагрузкой?Да.
А при чем тут multipath TCP?Потому что это единственная работающая и стандартизированная на текущий момент технология для объединения нескольких каналов без необходимости особых настроек на оборудовании пользователя или провайдера пользователя.
Насколько я понимаю, по правильному эта задача решается упорядоченной буферизацией принимаемых пакетов и использованием 2 маршрутов на уровне IP. Т. е. использовать два destination или source ip-адреса, доступных по разным маршрутам.Это и делает Multipath TCP, только еще и делает так, чтобы для приложения это выглядело обычным одним TCP-соединением.
На каждом уровне свои методы обеспечения безопасности и балансировки. Зачем смешивать разные уровни?..Они не работают через интернет, без дополнительных настроек на стороне провайдера или клиента. А Multipath TCP и Multipath QUIC — работают.
Хотя так даже лучше будет выглядеть.
Зафиксировал тут, может когда-нибудь пригодится.
Вот если бы можно было делать DH в тех же TCP пакетах, где ходит SYN, SYN/ACK, ACK — было бы очень круто.
Мы имеем сертификат DNS сервера с его открытым ключом.
Отправляем серверу запрос шифруя его открытым ключом. В запросе домен и пароль для ответа.
DNS отвечает шифруя пакет полученным ключом и подписывает его своим закрытым ключом.
Всё. Что ещё нужно?
DNSSEC почти так и работает, как вы описали. Если не считать того что он не шифрует данные, только подписывает. Основные протоколы интернета вообще слабо приспособлены для борьбы с намеренными блокировками.
Ну, а вот DNSCurve работает именно как описано.
> Стандарты 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, по вашему опыту?
Крупные корпорации посылают своих людей на живые встречи, где финализируются решения. Это уже финальный кулуарный этап, на котором может быть принято совсем не то, что ожидалось по консенсусу обсуждений в рассылках. Боюсь, тут возникает «естественным» путём предпочтение решений, оптимальных для гигантов. Есть какая-то статистика по этому вопросу?
Отсутствие процедуры выпуска обновлённых версий спецификаций с учётом найденных багов [...] Переусложнённость спецификаций, чрезмерная любовь к грамматикализации
Ну это было в принципе характерно для индустрии в определенное время, особенно в 80-е. Последнее десятилетие в спецификациях такое не выражено.
Поэтому думаю, про «железобетонность» было художественным преувеличением, рассчитанным на дальнейшее восприятие доклада :)
Многие авторы вполне себе закладываются именно на это. Например, автор BearSSL (втащенного в базу FreeBSD) писал, что не будет имплементить TLS 1.3, пока он в стадии драфтов — дождется "ожелезобетонивания". Так что, вообще говоря, "отсутствие процедуры" можно рассматривать и как плюс. Тем не менее, понятие Errata таки ввели — уже 8-тысячных RFC на них бывают отсылки.
Я не понял вообще в их дизайне (начиная с HTTP/2), зачем им принципиальное отсутствие переиспользования потоков. По-моему, это усложнение кода.
Такое впечатление, что в Google в принципе не умеют в реюз. Сначала вот этот ужас с нечетными и четными потоками в SPDY, который так и перекочевал в QUIC. Потом использование внутри потока в его фреймах смещения в нём — т.е. поток теперь не только ограничен сверху 2^62 байтами, но и дополнительная головная боль с буфером пересборки фрагментов. Наконец, они почему-то сначала не смогли в стандартный sequence number arithmetics (RFC 1982) и сделали абсолютный 62-битный номер пакета (ну ладно, это еще туда-сюда, в такой потолок действительно сложно упереться на практике в рамках одного соединения).
Так после этого они захотели эти 62 бита, во-первых, скомпрессировать — до 1, 2 или 4 байт. При том, что в другом месте минимальный поддерживаемый MTU аж 1200 байт. Во-вторых, еще и зашифровать! Отдельным ключом, да. Что вообще непонятно, какую задачу они решают этим header protection.
В результате, понятно, такая компрессия передачей младших бит — весьма чревата при reordering и дубликатах пакетов. Поэтому в подпись пакета они включают полный номер. В итоге возможна ситуация, когда пакет — который, надо напомнить, будет не менее 1200 байт (это для защиты от DDoS amplification типа) — будет расшифрован, подпись не сойдется, он будет отброшен. См. RFC 9001, Section 5.3, 5.5 — и они там вовсе не считают это проблемой, хотя очевидно, что это достаточно простой вектор DoS-атаки на имплементацию: просто запоминаем проходящие через нас транзитом пакеты и через некоторое время выплёвываем их endpoint'ам повторно (возможно, не один раз).
Как посчитали в обсуждении в профильном чате телеги по DNS Security, всё это от этого, что компании размера Google не считают DDoS проблемой — у них слишком много ресурсов.
вообще мобильные сети — проблема. Я наблюдаю, что при быстром движении (например, телефон в поезде) происходит неограниченное накопление пакетов: пинг доходил до 150 секунд. Радиомодуль пытается перепосылать одно и то же по многу раз и не имеет нормального дропа пакетов, что сбивает логику всех протоколов транспортного уровня и выше, обычно рассчитанных на то, что IP не накапливает, а дропает.
А зачем они так делают? И делают ли до сих пор? Недавно (в связи с небезызвестными политическими тенденциями) задумался о соседней проблеме, туннелей вида tcp over tcp — оные всегда считались "плохо" как раз из-за ретрансмита обоими сразу. Вариант решения: что, если имплементации, которая "внутри", мы сообщаем просто дополнительную константу, которую надо добавлять к RTO (оставляя всю остальную логику exponential backoff) — будет ли это работать? Можно ли придумать что-то лучше?
QUIC, TLS 1.3, DNS-over-HTTPS, далее везде