QUIC, TLS 1.3, DNS-over-HTTPS, далее везде

    Хабр, привет! Это транскрипция доклада Артема ximaera Гавриченкова, прочитанного им на BackendConf 2018 в рамках прошедшего фестиваля РИТ++.



    — Здравствуйте!

    В названии доклада приведён длинный список протоколов, мы по нему пройдемся постепенно, но давайте начнем с того, чего в названии нет.

    Это (под катом) заголовок одного из блогов, в интернете вы могли таких заголовков видеть очень много. В том посте написано, что HTTP/2 — это не какое-то отдаленное будущее, это наше настоящее; это современный протокол, разработанный Google и сотнями профессионалов из многих продвинутых компаний, выпущенный IETF в качестве RFC в далеком 2015 году, то есть уже 3 года назад.

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



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

    HTTP/2 должен был быть адаптирован для продвинутого веба, готов к использованию в современных сервисах и приложениях, фактически быть drop-in replacement для старых версий протокола HTTP. Он должен был повышать производительность сайта, параллельно снижая нагрузку на бэкенд.



    Даже SEO-шники говорили, что им нужен HTTP/2.



    И его, вроде как, было очень просто поддержать. В частности, Нил Крейг из BBC писал в своем блоге, что достаточно «просто включить» его на сервере. Еще можно найти множество презентаций, где написано, что HTTP/2 включается следующим образом: если у вас Nginx, то можно в одном месте поправить конфигурацию; если нет HTTPS, нужно ещё дополнительно поставить сертификат; но, в принципе, это вопрос одного токена в конфигурационном файле.

    И, естественно, после того, как вы пропишете этот токен, вы сразу начинаете получать бонусы от повышения производительности, новых доступных фич, возможностей – в общем, всё становится замечательно.


    Ссылки со слайда:
    1. medium.com/@DarkDrag0nite/how-http-2-reduces-server-cpu-and-bandwidth-10dbb8458feb
    2. www.cloudflare.com/website-optimization/http2


    Дальнейшая история основана на реальных событиях. Компания имеет некоторый онлайн-сервис, обрабатывающий порядка 500-1000 HTTP-запросов в секунду. Сервис этот находится под DDoS-защитой Cloudflare.

    Существует множество бенчмарков, которые подтверждают, что переход на HTTP/2 снижает нагрузку на сервер вследствие того, что при переходе на HTTP/2 браузер устанавливает уже не 7 соединений, а по плану вообще одно. Ожидалось, что при переходе на HTTP/2 и памяти используемой станет меньше, и процессор будет менее нагружен.

    Плюс к этому в блоге Cloudflare и на сайте Cloudflare предлагается включить HTTP/2 просто одним кликом. Вопрос: почему бы так не сделать?



    1 февраля 2018 года компания включает HTTP/2 этой самой кнопочкой в Cloudflare, и на локальном Nginx тоже его включает. Месяц собираются данные. 1-го марта происходит замер потребляемых ресурсов, и потом sysops'ы смотрят число запросов в логах, которые приходят по HTTP/2 на стоящий за Cloudflare сервер. На следующем слайде будет процент запросов, пришедших на сервер по HTTP/2. Поднимите руки, кто знает, какой будет этот процент?

    [Из зала: «1-2%!»]



    — Ноль. По какой причине?



    Cloudflare, а так же другие сервисы по защите от атак, MSSP и облачные сервисы, работают в режиме reverse proxy. Если в нормальной ситуации браузер напрямую соединяется с вашим Nginx, то есть соединение идет напрямую от браузера до вашего HTTP-сервера, то вы можете использовать тот протокол, который браузер поддерживает.

    В случае, если между браузером и вашим сервером стоит облако, пришедшее TCP-соединение терминируется в облаке, TLS тоже там терминируется, и HTTP-запрос сначала попадает на облако, далее облако фактически обрабатывает этот запрос.

    У облака есть собственный HTTP-сервер, в большинстве случаев тот же самый Nginx, в редких случаях это «самописный» сервер. Этот сервер парсит запрос, как-то его обрабатывает, консультируется с кэшами и, в конечном итоге, формирует новый запрос и отправляет его уже на ваш сервер по тому протоколу, который он поддерживает.

    Все существующие облака, заявляющие о поддержке HTTP/2, поддерживают HTTP/2 на стороне, смотрящей в браузер. Но не поддерживают его на стороне, смотрящей к вам.



    Почему?

    Простой и не совсем правильный ответ: «Потому что в большинстве случаев у них развёрнут Nginx, а Nginx не умеет ходить по HTTP/2 к апстриму». Окей, хорошо, это ответ правильный, но не полный.



    Полный ответ нам дают инженеры Cloudflare. Дело в том, что в фокусе спецификации HTTP/2, написанной и выпущенной в 2015 году, было повышение производительности браузера на специфичных, например, для Google сценариях использования.

    Google использует собственные технологии, не использует reverse proxy перед своими production-серверами, поэтому о reverse proxy никто не подумал, и именно поэтому HTTP/2 от облака до апстрима не используется. Там, на самом деле, и профита мало, потому что в режиме reverse proxy, из того, что описано в протоколе HTTP/2, например, Server Push не поддерживается, потому что непонятно, как он должен работать, если у нас pipelining.

    То, что HTTP/2 экономит соединения – это круто, но reverse proxy сам по себе их экономит, потому что он не открывает по одному соединению на каждого пользователя. Смысла поддерживать здесь HTTP/2 мало, а накладные расходы и проблемы связанные с этим – большие.



    Что важно: reverse proxy – это технология, которая начала активно использоваться порядка 13 лет назад. То есть это технология середины 2000 годов: я еще в школу ходил, а она уже использовалась. В стандарте, выпущенном в 2015 году, она не упоминается, не поддерживается и работа по ее поддержке, на данный момент, в рабочей группе httpbis в IETF не ведется.

    Это один пример тех вопросов, которые возникают, когда люди начинают внедрять HTTP/2. На самом деле, когда разговариваешь с людьми, которые развернули и имеют уже какой-то опыт работы с ним, постоянно слышишь примерно одни и те же слова.



    Лучше всего их сформулировал Максим Матюхин из Badoo в посте на Хабре, где он рассказывал о том, как работает HTTP/2 Server Push. Он написал, что его сильно удивило, насколько отличается взаимодействие конкретно этой функциональности с браузерами, ведь он думал, что это полностью отработанная фича, готовая к использованию в продакшене. Эту фразу в отношении HTTP/2 я слышал уже очень много раз: думали, что это протокол, который «drop-in replacement» – то есть включаешь его, и все нормально – почему же на практике всё так сложно, откуда возникают все эти проблемы и недоработки?

    Давайте разберемся.



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

    Протоколы использовались следующие: так как мы говорим про Интернет, а не про локальную сеть, то на нижнем уровне начинаем с протокола IPv4. Выше него использовался протокол TCP – или UDP, но для 90% случаев (так как 80-90% трафика в интернете – это Web) дальше был TCP, – затем SSL (который потом заменили на TLS), а выше уже был гипертекстовый протокол HTTP. Постепенно сложилась ситуация, что, по плану, к 2020 году архитектура интернета должна была в корне поменяться.



    Протокол IPv6 с нами уже очень давно. TLS недавно обновили, мы еще обсудим, как это происходило. И протокол HTTP/2 тоже обновился.

    У замечательного отечественного фантаста Вадима Панова в цикле «Анклавы» была такая прекрасная фраза: «Вы ждали будущего. Вы хотели будущего? Оно наступило. Вы его не хотели? Оно все равно наступило». Единственное, что осталось практически нетронутым — по состоянию на пару лет назад – это протокол TCP.

    Люди, которые занимаются дизайном интернета, не могли пройти мимо такой вопиющей несправедливости и решили протокол TCP выкинуть тоже.

    Ладно, это, конечно же, шутка. Проблема не просто в том, что протокол слишком старый. В протоколе TCP есть недостатки. Особенно многих беспокоило, что протокол HTTP/2 уже написан, стандарт 2015 года уже внедряется, но вот конкретно с TCP он работает не всегда хорошо, и неплохо бы под него подложить какой-нибудь другой транспорт, более подходящий для того, что когда-то называлось SPDY, когда пошли те разговоры, а потом и для HTTP/2.



    Протокол решили назвать QUIC. QUIC – это ныне разрабатываемый протокол для транспорта. Он основан на UDP, то есть это датаграммный протокол. Первый черновик стандарта был выпущен в июле 2016 года, и текущая версия черновика…

    [Докладчик проверяет почту на телефоне]

    —… да, всё ещё 12-я.

    На данный момент QUIC еще не является стандартом — его активно пишут. Если я не ошибаюсь – я не стал писать на слайде, потому что боялся ошибиться – но на IETF 101 в Лондоне говорилось, что где-то к ноябрю 2018 года планируется выпустить его уже как окончательный документ. Именно сам стандарт QUIC, потому что в рабочей группе документов ещё восемь штук.



    То есть стандарта еще нет, но уже идет активный хайп. Я перечислил только те конференции, где я был за последние полгода, где про QUIC была хотя бы одна презентация. О том, «какой он крутой», «как нам нужно на него переходить», «что делать операторам», «перестаньте фильтровать UDP — через него сейчас QUIC будет работать». Весь этот хайп длится уже достаточно давно — я уже видел много статей, которые призывали игровую индустрию переходить на QUIC вместо обычного UDP.


    Ссылки со слайда:
    1. conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf
    2. blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop


    В ноябре 2017 года в рассылке рабочей группы QUIC появляется вот такая ссылка: верхняя на whitepaper, а нижняя для тех, кому тяжело читать whitepaper — это ссылка на блог APNIC с кратким содержанием.

    Исследователи решили сравнить производительность TCP и QUIC в текущем его виде. Для сравнения, чтобы не разбираться с тем, кто в чем виноват и где может быть вина Windows, со стороны клиента взяли Chrome под Ubuntu, а также взяли 2 мобильных устройства: какой-то Nexus и какой-то Samsung (прим. ред.: Nexus 6 и MotoG) с Android 4 и 6 версий, и в них тоже запустили Chrome.

    Со стороны сервера они поставили Apache для того, чтобы видеть, как работает TCP-сервер, а для того, чтобы отслеживать QUIC, они выдрали кусок опенсорсного кода, который имеется в проекте Chromium. Результаты benchmark'ов показали, что, хотя во всех тепличных условиях QUIC действительно выигрывает у TCP, есть некоторые краеугольные кейсы, по которым он проигрывает.



    Например, реализация QUIC от Google работает существенно хуже TCP, если в сети происходит packet reordering, то есть пакеты прилетают не в том порядке, в котором были отправлены сервером. В 2017-2018 годах, в век мобильных и беспроводных сетей, вообще нет никакой гарантии, что пакет в принципе долетит, не говоря уже о том, в каком порядке. QUIC отлично работает на проводной сети, но кто сейчас пользуется проводной сетью?



    Вообще, разработчики этого кода в Google, видимо, очень не любят мобилки.

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

    Всего 2 кейса использования: первый – беспроводная сеть, второй – мобильное устройство; и QUIC работает либо как TCP, либо существенно хуже. Естественно, это оказалось в рабочей группе IETF, посвященной QUIC и, естественно, на это отреагировал Google. Реакция Google была следующая:


    mailarchive.ietf.org/arch/msg/quic/QktVML_qNDfqjIGirj4t5D0JRGE

    Ну, мы посмеялись, но на самом деле это абсолютно логично.

    Почему? Потому что дизайн QUIC – хотя мы говорим уже о внедрении в production, но – на самом деле дичайший эксперимент.

    Вот, скажем, семиуровневая модель ISO/OSI. Кто ее помнит здесь? Помните уровни: физический, канальный, сетевой, транспортный, какая-то чушь, какой-то бред и прикладной, да?

    Да, оно было разработано очень давно, и как-то мы жили с этой уровневой моделью. QUIC – это эксперимент по устранению самой по себе уровневой системы сети. Он объединяет в себе шифрование, транcпорт, надежную доставку данных. Все это не в уровневой структуре, а в комбайне, где каждый компонент имеет доступ к API других компонентов.



    Цитируя одного из дизайнеров протокола QUIC Кристиана Гюитема: «Одно из главных преимуществ QUIC с архитектурной точки зрения – это отсутствие уровневой структуры». У нас есть и acknowledgement, и flow control, и шифрование, и вся криптография, – все это полностью в одном транспорте, и наши транспортные инновации подразумевают доступ всего этого напрямую к сетевому API, поэтому уровневую архитектуру в QUIC'е мы не хотим.



    Разговор в рабочей группе об этом пошел из-за того, что в начале марта другой дизайнер протокола QUIC, а именно Эрик Рескорла, решил предложить на обсуждение вариант, в котором из QUIC убирается все шифрование, вообще. Остается только транспортная функция, которая работает поверх DTLS. DTLS, в свою очередь, – это TLS поверх UDP, в сумме получается: QUIC поверх TLS поверх UDP.

    Откуда возникло такое предложение? Кстати, Рескорла написал большой документ, но вовсе не для того, чтобы это стало стандартом — это был предмет для обсуждения потому, что в процессе дизайна архитектуры QUIC, в процессе тестирования интероперабельности и реализации, возникло очень много проблем. В основном, связанных с «потоком 0».

    Что такое «поток 0» в QUIC? Это такая же идея, как и в HTTP/2: у нас есть одно соединение, внутри него у нас есть несколько мультиплексируемых потоков. По дизайну QUIC, напоминаю, шифрование обеспечивается тем же протоколом. Сделано это было следующим образом: открывается «магический» поток номер 0, который отвечает за установку соединения, рукопожатие и шифрование, после чего этот поток 0 шифруется и все остальные шифруются тоже. С этим возникло достаточно много проблем, они перечислены в списке рассылки, там 10 пунктов, я не буду на каждом останавливаться. Выделю только один, который мне очень нравится.


    www.ietf.org/mail-archive/web/quic/current/msg03498.html

    Проблема, связанная с потоком 0, – одна из – состоит в том, что в случае, если у нас идет потеря пакетов, нам нужно их перепосылать. А при этом, например, на стороне сервера соединение уже может быть отмечено, как шифрованное, а потерянный пакет относится ещё ко времени, когда оно было незашифровано. В этом случае при перепосылке реализация может случайно шифровать пакеты.

    Ещё раз:



    Случайно шифровать пакеты.

    Это довольно сложно прокомментировать, кроме того, чтобы рассказать, как это все на самом деле дизайнится. В разработке QUIC фактически используется эрзац-agile-подход. То есть не то, чтобы кто-то написал железобетонный стандарт, который через пару итераций можно официально выпустить. Нет.



    Работа происходит следующим образом:
    1. Запускается черновик стандарта, например, номер 5;
    2. В списках рассылки, а также на IETF-встречах – три штуки в год — проходит обсуждение, потом на хакатонах проходит реализация, interop testing, собирается обратная связь;
    3. Google внедряет какие-то из изменений в Chrome, в собственной инфраструктуре, анализирует последствия и далее счетчик инкрементируется и появляется стандарт 6.

    Сейчас, напоминаю, 12 версия.
    Прим. ред.: по состоянию на 10 июля 2018 г. уже 13-я.

    Что здесь важно?

    Во-первых, минусы мы только что увидели, но есть и плюсы. В этом процессе, на самом деле, можно участвовать. Feedback собирается со всех вовлеченных сторон: если вы занимаетесь gaming'ом, если вы думаете, что вы в игровой индустрии можете просто взять и поменять UDP, поставить вместо него QUIC, и все будет работать – нет, не будет. Но на данный момент вы можете на это повлиять, с этим можно как-то работать.



    И это, на самом деле, общая история. Feedback от вас ожидается, все хотят его видеть.

    Google разрабатывает протокол, в него какие-то идеи вкладывает – для своих целей. Компании, которые занимаются другими вещами (если это не совсем типичные Web, gaming или мобильные приложения, SEO то же самое), они не могут по умолчанию рассчитывать, что протокол будет учитывать их интересы: не только потому, что это никого не интересует, а потому, что никто просто не знает про эти интересы.

    Это, кстати, явка с повинной. Конечно же, вопрос ко мне, почему мы, как Qrator Labs, в частности, не участвовали в разработке протокола HTTP/2 и не сказали никому про reverse proxy. Но те же Cloudflare и Nginx тоже там не участвовали.

    Пока в этом не участвует индустрия, разработкой занимаются Google, Facebook, какие-то еще компании и академики. Чтобы вы знали, в около-IETF'ной тусовке слово «академик» – оно, скажем так, не похвальное. Оно звучит наподобие эпитетов «шизофреник» и «ипохондрик». Люди часто приходят без каких-либо практических целей, без понимания реальных задач, но вписываются туда, потому что так проще на докторскую диссертацию наработать.

    В этом всём, конечно, нужно участвовать и вариантов других нет.



    Возвращаясь к QUIC: итак, протокол реализован в user space, на мобильных устройствах существует… Бла-бла. «Реализован в user space». Давайте поговорим об этом.

    Как у нас вообще был устроен транспорт до того, как начали придумывать QUIC? Как он устроен сейчас в продакшене? Есть протокол TCP, если мы говорим про Web.



    В протоколе TCP есть такая штука, как тройное рукопожатие: SYN, SYN/ACK, ACK. Оно нужно для целого ряда вещей: чтобы не позволять использовать сервер для атак на других, чтобы успешнее фильтровать определенные атаки на протокол TCP, такие, как SYN-флуд. Только после того, как 3 сегмента тройного рукопожатия прошли, у нас начинается отправка данных.



    При этом тут 4 действия, 3 из которых происходят в ядре, происходят они достаточно эффективно, а в user space попадают уже данные, когда соединение установлено.



    В ситуации с QUIC всё это счастье – в юзерспейсе. Тут звездочка стоит, потому что там терминология не совсем «SYN, SYN/ACK», но, по сути, это тот же самый хендшейк, только переехавший полностью в user space. Если летит 20 Гбит/с флуда и раньше в TCP их можно было обработать в ядре SYN-куками, то теперь их нужно обрабатывать в user space, так как они пролетают все ядро и через вcе context switch'и. И там их нужно как-то поддерживать.

    Почему сделано так? Почему QUIC – это протокол user space'овый? Хотя транспортный, казалось бы, самое место ему где-то на системном уровне.



    Потому что, опять же, в этом интерес Google и других участников рабочей группы. Они хотят видеть новый протокол внедренным, они не хотят ждать, пока все операционные системы в округе обновятся. Если он реализован в user space, его можно использовать (в частности, в браузере, но не только) уже сейчас.

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


    www.ietf.org/mail-archive/web/quic/current/msg03736.html

    На экране буквальная цитата из рассылки QUIC, где проходило обсуждение как раз о том, что протокол планируется к реализации в user space. Это буквальная цитата: «Мы хотим деплоить QUIC на любую машину без поддержки операционной системы. Если у кого будут проблемы с производительностью, то они унесут это все в ядро». QUIC уже настолько развесистый, что уносить это в ядро с шифрованием и со всем остальным уже страшновато, но рабочая группа на эту тему тоже особо не запаривается.



    Причем почему этот подход используется на стороне клиента – я могу понять. Но тот же подход используется на стороне сервера. Теоретически, в этом случае QUIC действительно стоило бы уносить в ядро, но, опять же, работа над этим не ведется, а когда она будет закончена, мы уже в лучшем случае все седыми будем, и я не планирую жить вечно. И когда это произойдет – не очень понятно.

    Говоря про ядро Linux, нельзя не упомянуть, что одним из главных смыслов существования QUIC было то, что он реализован поверх легковесного протокола UDP, и благодаря этому работает более эффективно, более быстро… и вообще зачем тогда нам TCP, такой большой и громоздкий.


    vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf

    Тут представлена другая ссылка на бенчмарк. Выясняется, что отправка UDP-датаграмм в Linux дороже, чем отправка TCP-потока, причем существенно дороже, заметно дороже. Там есть 2 главных момента (то есть много моментов, но только два главных):

    1. Поиск по таблице маршрутизации занимает больше времени в случае UDP-датаграммы;
    2. Штука под названием «large segment offload». В TCP мы большой поток данных можем просто сгрузить в передачу, не обязаны его разбивать по сегментам на CPU, в то время как в UDP нам нужно подготовить каждую датаграмму, у нас нет потока. В данный момент разработчики ядра думают, что с этим делать, но, по большому счету, на данный момент, TCP работает на посылке больших данных, не влезающих в один пакет, эффективнее, чем UDP, на котором основан QUIC.


    www.ietf.org/mail-archive/web/quic/current/msg03720.html

    Вот это опять же цитата сотрудника Google, я, в частности, тоже задавал ему этот вопрос. Ведь мы можем просто попытаться обвинить Linux, сказать, что под Windows, может быть, не так все плохо, но нет. Утверждается, что на любой платформе, на которой Google деплоил QUIC, есть проблема с повышенной стоимостью (с точки зрения центрального процессора) отправки UDP-пакета против TCP-потока. То есть это не просто Linux такой, а это общий подход.



    Что приводит нас к одной простой мысли.

    Хватит говорить про QUIC. Достаточно. Простая идея, которую нужно отсюда вынести – это то, что перед внедрением любого нового протокола вместо старого: HTTP/2 против HTTP/1.1, QUIC вместо TCP, шифрование DNS, IPv6 вместо IPv4… первое, что нужно сделать, перед принятием решения и выкладкой на production – это, естественно, benchmarking.

    Не верьте никому, кто говорит, что протокол «можно просто поменять/включить/нажать кнопку» – нет! Никогда такого не будет – и не было никогда, и не будет в будущем, и никто такое не гарантирует.

    Поэтому только бенчмарк, и, естественно, что если вы этого не сделаете, а просто развернете что-нибудь, то, конечно, гарантию качественной работы вам никто не предоставит.



    Кстати, про IPv6. Дело в том, что во времена IPv6, когда он разрабатывался, протоколы разрабатывались как-то более прямолинейно, то бишь без agile-технологий. Но их адаптация в интернете всё равно заняла очень большое существенное время. И, на данный момент, все еще продолжается, и все еще висит на уровне 10-20% в случае IPv6. Причем в зависимости от страны, потому что в России еще ниже.

    На пути внедрения IPv6 было решено очень много проблем. Кто знает, что такое «Happy Eyeballs»? В общем, было очень много проблем, связанных с IPv6, причём таких, когда жаловались живые пользователи. Скажем, ты закрываешь ноутбук, выходишь из дома, где у тебя есть IPv6, приходишь в кафе, где IPv6 нет, открываешь лэптоп – ничего не работает, потому что кэши браузера и операционной системы – все это продолжает смотреть в IPv6, а локальной связности нет.

    Был придуман подход под названием «Happy Eyeballs» (тоже являющийся стандартом, выпущенным IETF): если в течении 0,3 с мы не нашли IPv6-связности, не смогли соединиться, мы откатываемся на IPv4.

    Костыль, но работает, вроде бы, почти всегда, но! Постоянно возникают мистические проблемы с реализацией. В частности, одна из самых популярных проблем почему-то была почему-то с iPad, которые из IPv6 в IPv4 и обратно переключались существенно медленнее, чем за 0,3 секунды: около 1 секунды – а то и 1 минуты.

    Даже в какой-то момент возникло безумное предложение на IETF 99 в Праге: «а давайте Happy Eyeballs будет в каждой сети по syslog'у на централизованный сервер, если проблемы, – что-нибудь отправлять». Собирать syslog со всех подключенных устройств – никто, конечно, на это не согласился. Но это показатель того, что проблем достаточно много.

    Другие проблемы – это борьба со всякими злонамеренными активностями, потому что локальная сеть в IPv6 – это /64 и очень много адресов, которые атакующий может начать перебирать, защите нужно их вовремя агрегировать, и все такое. Этим нужно как-то заниматься, это все должно быть реализовано.

    В результате мы все равно получили проблемы с внедрением, которые не только выражаются в том, что кто-то IPv6 медленно внедряет. Нет, его начали отключать обратно. Обратно переходить в IPv4. Потому что и без проблем тяжело было обосновать менеджменту преимущества перехода, но если после включения ещё и пользователи начали жаловаться — сразу всё. Это такой пример, когда даже протокол, который разработан был с видом на внедрение, всё равно вызывает дичайшие проблемы с внедрением, которые выражаются в головомойке техническому департаменту.

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


    blog.apnic.net/2018/02/26/peak-dnssec

    Другой пример на эту тему – DNSSEC. Я не буду просить вас поднять руки, чтобы узнать, у кого оно есть, потому что знаю, что ни у кого нет.

    Развёртывание IPv6, с одной стороны, развивается, с другой стороны, с ним есть проблемы, но оно хотя бы идет. Начиная с конца прошлого года, внедрение DNSSEC в мире замедлилось и пошло в обратном направлении.

    На этом графике мы видим ежедневное количество интернет-пользователей (по замерам APNIC Labs), использующих резолверы, которые валидируют DNSSEC. Здесь очень четко виден медвежий тренд: вот он, стартует после последнего пика, и этот пик – октябрь 2016 г.

    У DNSSEC есть цель, есть правильные задачи, но его развертывание фактически остановилось и пошел какой-то обратный процесс, и еще предстоит расследовать, откуда этот процесс взялся.


    datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01

    Вообще с DNS очень много проблем. В рабочей группе IETF dnsop сейчас 3 председателя, 15 черновиков, что называется, «в полете»: готовятся к выходу как RFC.

    DNS, в частности, научились передавать поверх всего. Поверх TCP он работал давно (но еще нужно людям показать, как это правильно делать). Теперь его начали пускать поверх TLS, поверх HTTPS, поверх QUIC.

    Все это выглядело совершенно замечательно, пока люди не начали это реализовывать, и у них не начало болеть в пятой точке. В марте 2017 г. разработчики OpenDNS привезли на IETF презентацию под названием «DNS Camel», или «верблюд DNS». Презентация сводится к следующей мысли: насколько еще мы можем нагрузить этого верблюда (aka протокол DNS), прежде чем очередная хворостинка сломает ему хребет?

    Это общий подход к тому, как мы видим сейчас дизайн. Фичи добавляются, фич очень много, они друг с другом интерферируют по-разному. И не всегда предсказуемым образом, и не всегда авторы реализации понимают все возможные точки интерференции. Внедрение каждой такой новой фичи, реализация, внедрение в production – добавляют набор потенциальных точек отказа в каждом месте, где происходит такая интерференция. Без бенчмарка, без мониторинга – никуда.



    Почему важно участвовать во всем этом процессе? Потому что стандарт IETF – «RFC» – это все-таки стандарт. Есть вот такая хорошая статистика: сроки разработки различных версий протоколов шифрования SSL и TLS.

    Обратите внимание, что версионирование SSL начинается с номера 2, потому что версии 0.9 и 1.0 никогда не были выпущены в production, они были более дырявыми, чем Netscape мог позволить себе выпустить. Поэтому история началась с протокола SSL 2.0, который разрабатывался год. Потом SSL 3.0 разрабатывался ещё один год.

    Затем TLS 1.0 разрабатывался 3 года; версия 1.1 – 7 лет; 1.2 разрабатывался только 2 года, потому что там не такие большие изменения были; но последняя версия, которая была выпущена в марте этого года – 27-й черновик, кстати – разрабатывалась 10 лет.

    В соответствующей рабочей группе в определенный момент на эту тему была большая паника, потому что выяснилось, что TLS 1.3 ломает очень много use case'ов, в частности, в финансовых организациях, с их мониторингом и файрволлами. Но изменить это, придя к осознанию уже на стадии восемнадцатого черновика, не смогли даже такие крупные компании, как U.S. Bank. Они ничего не успели с этим сделать, потому что, когда ты приходишь на вечеринку в момент, когда всем уже раздают счет, ты не можешь ожидать, что к твоему предложению продолжить веселье отнесутся с пониманием.

    Поэтому, если в каком-то протоколе – это опять вопрос к обратной связи – есть/будут/появляются фичи, которые вам не подходят, единственным вариантом является вовремя это отследить и вовремя в это вмешаться, потому что в противном случае оно так и будет выпущено, и придется строить костыли вокруг этого.



    Здесь на слайде, собственно, три главных вывода из всего этого процесса.

    Первый: как я говорил, внедрение нового протокола – это не просто в конфигурации «что-то подкрутить». Это расписанный план внедрения, оценка целесообразности с обязательными бенчмарками, как в реальности это все себя поведет.

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

    И третье, действительно: фидбэк нужен. Самое главное, что тот же Google, он не злой, он просто преследует свои собственные цели, у него нет задачи разрабатывать протокол для вас и за вас, это можете сделать только вы.

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

    Спасибо!
    Qrator Labs
    214,00
    DDoS Attacks Mitigation & Continuous Availability
    Поделиться публикацией

    Похожие публикации

    Комментарии 65

      +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
                У cloudflare dnssec поддерживается.
                  0

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

                –3

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

                  +6
                  поднявший DANE сервер у себя на ноутбуке

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

                    –1

                    Проблема с 3-rd party authority в принципе не решается ни dnssec, ни dane, никакими техническими средствами — если у вас нет shared secret, которым вы обменялись out-of-band (например, сертификатов предустановленных в системе). Если у вас нет корневых сертификатов/любого другого секрета — у вас нет возможности проверить, что ответы dnssec — это действительно авторитетные сервера, а не кто-то встроившийся в канал и подменяющий "секьюрные" ответы своими. Вы можете нагородить хоть 10 слоев протоколов — но это будет security through obscurity, фундаментальная проблема будет — как максимум — смягчена, а не решена — до тех пор, пока у вас не будет хотя бы одного стартового "корневого сертификата". Если бы эту проблему можно было решить иначе — никто бы не заморачивася с диффи-хеллманом, PKI и другими ухищрениями. Собственно, хорошая часть криптографии как науки была бы не нужна =)


                    Но легче, конечно же, пытаться затыкать рот мнимым авторитетом, чём разобраться в вопросе

                      +5

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


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

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


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

                        –1

                        trust anchor не "известен", он должен быть распространён — аналогично root CA, что не позволяет говорить о полной свободе от 3rd party authority. Ну и "уязвимости" типа protocol downgrade тоже никуда не денутся — пока что, как указано выше, мы не в идеальном мире и клиенты не могут работать исключительно по dnssec.


                        Да, это лучше того, что есть, но не надо изображать dnssec этакой панацеей, которая всех спасёт и "позволит отказаться от CA" — проблемы и ограничения у этой технологии также есть


                        Если вы, впрочем, не готовы говорить по сути — я тоже не вижу смысла.

                          +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

                          Кроме режима когда "всё красивое и зелёное" есть ещё переходные режимы — например, режимы совместимости (interoperability) со старыми резолверами, которые не умеют DNSSEC


                          Конкретный сценарий: что произойдёт, если "Вася" ARP-спуфингом в wi-fi сети кафе перехватит dnssec-запрос и сфорджит свой ответ, без DNSSEC и с/без DANE? Клиенту придётся либо:
                          1.Показывать пользователю ошибку. Но тогда этот клиент не сможет работать с "легаси" dns-серверами вообще (strict dnssec)
                          2.Показывать сайт как есть, с самоподписанным сертификатом (allow downgrade). Но тогда вышеупомянутый Вася может подменить страницу. Получается даже хуже, чём с pki.


                          Но конечно же это всё бред с Geektimes. Зачем только про него в книжках пишут...

                            +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

                                          Кстати, радостная новость: cloudflare поддерживает TLSA.

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

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

                                              0
                                              Ага, я там не зря написал в скобках, что это само по себе проблема.
                                          0

                                          Ну как видите в обоих сценариях получается плохо — если клиент проигнорирует фейковую DANE-запись (или злоумышленник ее не пошлёт), сертификат сервера всё равно останется самоподписанным, со всеми вытекающими.


                                          Про корневые сервера — хороший поинт.

                                            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
                                            Спасибо за транскрипцию. It's a good read!
                                              0
                                              Я присоединяюсь, читается очень интересно, интересные цитаты и примеры.
                                              +2
                                              Если абстрагироваться от технических аспектов, можно прийти к интересному выводу, что QUIC — это отличный способ для Гугла полностью исключить возможность какой-либо выборочной приоритизации трафика к своим сервисам, поскольку для провайдера это просто поток шифрованного UDP-мусора, и никакого хостнейма в текстовом виде там не передаётся. Соответственно, голубые мечты операторов связи резать Ютуб на мобильных подключениях уже накрылись медным тазом, и процент трафика по 443/udp только растёт.

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

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

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

                                                    А что отвалятся? Письмам много не нужно, а что софт по часу обновляется, так это сам гугл обвинять будут, ведь у пользователя 5G и 4 палки.
                                                  0

                                                  Хм, а как там реализован SNI?

                                                    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
                                                      Это же очень медленно. Там же сейчас вроде UDP запрос, ответ. Можно было сразу эти пакеты шифровать, подписывать. А так нужно будет соединение устанавливать, обмениваться ключами. В десять раз время запроса увеличится.
                                                        +1
                                                        Чтобы начать шифровать пакеты, надо сначала установить общий секрет. Да и аутентифицировать противоположную сторону было бы неплохо. Поэтому и надо сначала поперекидываться хендшейками. Собственно, TLS стремится свести размер хендшейка к минимуму.

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

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

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

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое