- комментарий 0:
From: kmeaw
Date: 2020-08-16 18:27:45Z
А как ещё прикладная программа может аутентифицировать DNS ответы, при
условии, что используются системный резолвер? Было бы странно
реализовывать рекурсию и валидацию DNSSEC в браузере, поэтому
предполагается, что это делает рекурсор. Поскольку у 99% пользователей
он будет находиться в той сети, которой они не доверяют и не
контролируют, то надо как-то защитить канал до рекурсора.
Или есть какие-то более простые способы решить эту проблему?
- комментарий 1:
From: Sergey Matveev
Date: 2020-08-16 18:46:50Z
*** kmeaw [2020-08-16 21:25]:
>А как ещё прикладная программа может аутентифицировать DNS ответы, при
>условии, что используются системный резолвер?
Это не её задача. Она не должна этого делать. Как прикладная программа
аутентифицирует DNSSEC? Никак, ибо не её дело.
>Было бы странно реализовывать рекурсию и валидацию DNSSEC в браузере,
>поэтому предполагается, что это делает рекурсор. Поскольку у 99%
>пользователей он будет находиться в той сети, которой они не доверяют и
>не контролируют, то надо как-то защитить канал до рекурсора.
Категорически не согласен и против подобного подхода. Программа хочет
получить имя какое-то из DNS? Ok, для этого давным давно есть
интерфейсы/вызовы в ОС. Как обеспечивается безопасность получения этих
имён? А какое дело прикладной программы до этого? Может быть resolver у
меня на этой же машине находится. Может быть DNSCrypt. Может быть
DNSCurve аутентифицированные ответы я получаю. Может быть IPsec у меня
поднят, который вообзе прозрачен для прикладного уровня. Это моё дело,
как пользователя своей системы, как я обеспечиваю безопасность. API для
resolve-а не предусматривает галочки "requires to be authenticated"? Так
добавьте её, чтобы ОС видела хотелку прикладного уровня и, в зависимости
от настроек, отвечала всё ли хорошо было с аутентификацией запроса или
нет.
>Или есть какие-то более простые способы решить эту проблему?
Это не решение проблемы, а грубый костыль, к тому же вовсю по умолчанию
нарушающий приватность (я помню что изначально всё это автоматически
включалось и использовало только вроде бы CloudFlare сервера).
Например если я хочу обезопасить трафик какого-то сокета, то я для этого
могу использовать IPsec и PF_KEY интерфейс, который и Linux и BSD
системы поддерживают. В нём прикладная программа может сказать ОС что
надо бы обеспечить вот такие вот параметры безопасности. В этом PF_KEY
не хватает возможностей для передачи таких параметров как "я хочу
обезопасить весь TCP трафик, предполагая что на том конце будет хост с
FQDN=банк.ру, а я при этом представлюсь как DN=stargraveWhatever" --
добавили это в виде расширений в PF_KEY интерфейс/API. Вот это
продуманное и хорошее решение проблемы, на мой взгляд. Прикладная
программа не должна заниматься такими вещами. Более того, эти вещи и
делаются на уровне ОС чтобы пользователь мог глобально управлять своими
пожеланиями как должны себя вести программы. А DNSCrypt в броузере это
прям недолгий путь до того, что весь сетевой стэк в прикладной уровень
скоро засунут... тогда ОС то зачем нужна? Управление памятью в
броузерах. вроде бы, давно уже своё (malloc сделали, а дальше
собственные allocator-ы внутри крутят). От ОС, получается, нужна только
прослойка с железом. Нет, но мне такого прикладного софта и вообще
полностью монолитного подхода, когда скоро чуть ли не весь сетевой стэк
будет внутри, не нужно.
А простой способ защитить канал связи до resursive DNS это, очевидно,
использовать средства для защиты канала связи, имеющиеся в каждой major
OS: IPsec, который полностью и затачивался под подобные задачи. Без IPv6
(без большого количества IP-адресов на руках) с IPsec-ом проблематично
работать, но так может они бы тратили, если бы реально хотели решать
подобные проблемы, на более ускоренное внедрение IPv6?
- комментарий 2:
From: kmeaw
Date: 2020-08-16 22:11:30Z
> Это не её задача. Она не должна этого делать. Как прикладная программа
> аутентифицирует DNSSEC? Никак, ибо не её дело.
Всё верно, но браузеры в современном мире часто выходят за рамки тех
задач, которые непосредственно относятся к web browsing. Скачивание
файлов, управление закладками, окнами/табами, кеширование DNS-ответов,
механизм установки и обновления всевозможных расширений.
Все уже привыкли к тому, что типичный браузер — это такая маленькая
(только внешне, на самом деле не очень) операционная система.
Я не говорю, что это хорошо, но это давно уже случилось, и ни один из
крупных участников рынка браузеров не способен легко это изменить.
> API для resolve-а не предусматривает галочки "requires to be
> authenticated"? Так добавьте её, чтобы ОС видела хотелку прикладного
> уровня и, в зависимости от настроек, отвечала всё ли хорошо было с
> аутентификацией запроса или нет.
> А простой способ защитить канал связи до resursive DNS это, очевидно,
> использовать средства для защиты канала связи, имеющиеся в каждой major
> OS: IPsec, который полностью и затачивался под подобные задачи.
Поскольку это всё ещё прикладная программа, да ещё и кроссплатформенная,
то она не может добавить такой интерфейс, и вынуждена использовать то,
что есть в текущих ОС.
По той же (хотя и не только) причние QUIC стали делать в виде костыля,
энкапсулированного в UDP, а не новый стек протоколов. Так гораздо проще
пропихнуть новый протокол, чем заставлять всех добавлять новый драйвер
во все ОС.
Если популярный браузер начнёт заставлять своих пользователей
настраивать IPsec, то он очень быстро потеряет почти всех своих
пользователей. Вариант с DNS-over-HTTPS лучше варианта с отправкой всех
запросов на рекурсор провайдера (не поддерживающий DNSSEC-валидацию
ответов) без шифрования и проверки подлинности ответа тем, что сужает
набор потенциальных атакующих, которые легко смогут провернуть атаку,
нацеленную на подмену IP-адреса целевого ресурса.
Мне больше нравится вариант с поднятием своего собственного рекурсора,
обеспечением защиты трафика до него (чего вовсе не потребуется, если он
локальный; иначе wireguard или IPsec) и неперекладыванием функций ОС и
сетевых сервисов туда, куда не следает. Но основная масса целевой
аудитории не захочет этого делать, и браузер вынужден ориентироваться на
них.
В целом я согласен, что лучше всем вместе (разработчикам ОС, браузеров,
API-стандартов, сетевых протоколов, сетевым администраторам) выработать
правильную стратегию и придерживаться её. Но тогда будет как с IPv6 —
разработан и внедряется уже давно, а сказать, что мир захвачен до сих
пор нельзя.
> тогда ОС то зачем нужна?
Это интересный вопрос. Есть несколько экспериментальных (и не очень)
направлений, которые рассматривают снижение роли классической ОС на
компьютере и переносе ряда её функций в другое ПО.
Есть сетевые задачи, которые эффективнее выполнять как можно ближе к
прикладному приложению. Например, балансировка, маршрутизация и анализ
трафика на скоростях выше миллиононв пакетов в секунду. Для этого
придумали такие штуки, как DPDK.
Виртуализация storage. iSCSI, NVMe-OF — SPDK.
Можно достичь снижения поверхности атаки сетевого сервиса, если
превратить его в отдельную ОС, которая умеет только то, что нужно
сервису (includeOS). Если такой сервис взломают, то не получат всего
богатства runtime-возможностей для реконфигурации, которые предоставляют
типичные ОС.
Ещё более сильная изоляция прикладных приложений друг от друга, как в
Qubes OS.
Все эти направления возникли оттого, что типичная ОС не может
предоставить интерфейс, который бы подходил идеально под любые задачи.
> Без IPv6 (без большого количества IP-адресов на руках) с IPsec-ом
> проблематично работать, но так может они бы тратили, если бы реально
> хотели решать подобные проблемы, на более ускоренное внедрение IPv6?
Не понял. Как связаны IPsec и большое количество IP-адресов на руках?
- комментарий 3:
From: Sergey Matveev
Date: 2020-08-17 07:13:23Z
*** kmeaw [2020-08-17 01:09]:
>Всё верно, но браузеры в современном мире часто выходят за рамки [...]
>Я не говорю, что это хорошо, но это давно уже случилось, и ни один из
>крупных участников рынка браузеров не способен легко это изменить.
Согласен что по факту всё так и есть. Просто я и ни считаю что
современные броузеры это хоть на йоту хоть сколько-то приемлемое для
использования ПО. Крупным участникам вообще нет смысла делать что-то "по
нормальному" -- в их руках (в их софте, единственном броузере) полное
управление (всё возрастающее) почти всем что происходит у пользователя
на компьютере. Уже давно броузеры это чуть ли ни не номер один из всего
софта что сливает кучу данных и проводит слежку.
Я то возмущаюсь тем, что риторика всех этих броузеро-строителей это
"security, privacy", но именно они то из года в год всё страдают и
страдают ещё больше.
>Если популярный браузер начнёт заставлять своих пользователей
>настраивать IPsec, то он очень быстро потеряет почти всех своих
>пользователей.
Как и наоборот :-). У создателей броузеров (а это, насколько понимаю,
всего лишь 1.5 компании: Google и "пока ещё вроде как при деле" Mozilla)
задача одна: делать деньги. Деньги делаются легко и эффективно чем
больше есть контроля и чем больше есть средств, например сбором данных,
для их заработка. Техническое совершенство, продуманность, разумность и
адекватность вообще роли никакой нигде не играют.
>Вариант с DNS-over-HTTPS лучше варианта с отправкой всех
>запросов на рекурсор провайдера(не поддерживающий DNSSEC-валидацию
>ответов)
Только если посмотреть на это с инженерной точки зрения, то этот вариант
является адом overhead-а сложности и переусложнённости. Ok, IPsec пока
(надеюсь что пока) это сложно и всё такое. Но придуман же давным давно
DNSCrypt -- просто оборачиваем в крипто-envelope запросы/ответы. Это
относительно красивое и очень простое решение. А DoH это TCP-based
решение требующее очень нехилого HTTP/2 стэка ещё, плюс PKI для TLS
валидации. Броузеры понятно почему DoH используют -- весь этот стек у
них есть на руках, но это, с моей точки зрения, маразм так делать. Я
точно так же считаю полным маразмом WebSocket технологию: костыль,
созданный потому что броузер не может предоставить просто TCP или SCTP
(чтобы на сообщения бить) соединения. А SCTP не может предоставить
потому что NAT у большинства.
Всё это не только проблема броузеров, но вообще подходов написания
софта. Сейчас мы поэтому и имеем приложения "фонарика", занимающего
больше чем Win95 и всякие поднимания разработчиками распределённых
Hadoop/Cassandra кластеров для задач которые может выполнить один
Atom-based ноутбук на одном небольшом жёстком диске. Но это всё на тему
ff1d0be750ab73518138fe8f04b423822081d5d1. Броузеры это просто яркие
представители как любую простейшую задачу можно сделать невероятно
сложно, только потому что "у нас на руках сейчас вот только такие
возможности".
>Мне больше нравится вариант с поднятием своего собственного рекурсора,
>обеспечением защиты трафика до него (чего вовсе не потребуется, если он
>локальный; иначе wireguard или IPsec) и неперекладыванием функций ОС и
>сетевых сервисов туда, куда не следает. Но основная масса целевой
>аудитории не захочет этого делать, и браузер вынужден ориентироваться на
>них.
Это всё я понимаю и согласен. И большинству людям и Интернет то не нужен
по факту (сидят же большинство за NAT-ом и не замечают) и безопасность с
приватностью (сами же ставят централизованные IM-ы зарубежные, хотя
никто не заставляет). И броузеры уже давно исключительно только для
таких людей и делаются. Для меня поэтому "современный Web" это закрытый
мир: http://www.stargrave.org/WebForbidden.html
Но, повторюсь, бесит риторика броузеро-строителей, которые могли бы и
молчать про security/privacy/performance/experience и прочем :-)
>В целом я согласен, что лучше всем вместе (разработчикам ОС, браузеров,
>API-стандартов, сетевых протоколов, сетевым администраторам) выработать
>правильную стратегию и придерживаться её. Но тогда будет как с IPv6 —
>разработан и внедряется уже давно, а сказать, что мир захвачен до сих
>пор нельзя.
Согласен. Но так всегда и бывает: либо более долгий, сложный и тернистый
путь, зато (технически) разумный, адекватный, эффективный и больше
profit-а дающего в будущем, либо сиюминутный быстрый хак (но не
эффективный и ужасный с технической точки зрения), зато дающий сразу же
профит для разработчика софта. Просто подобные хаки на десятилетия могут
тормозить внедрение и прогресс чего-то нормального, как это например
было/есть с NAT-ом, после изобретения которого вот до сих пор
оттягивается IPv6 повсеместный (благо, темпы его внедрения уже
значительно растут).
>Есть сетевые задачи, которые эффективнее выполнять как можно ближе к
>прикладному приложению. Например, балансировка, маршрутизация и анализ
>трафика на скоростях выше миллиононв пакетов в секунду. Для этого
>придумали такие штуки, как DPDK.
Ну это уже особые нишевые задачи, где действительно general-purpose ОС
может существенно мешать. Тут, я считаю, простительно так делать :-).
>Виртуализация storage. iSCSI, NVMe-OF — SPDK.
Ммм, тут не очень понял как это относится к "OS vs ...". iSCSI всё же
придуман просто для того чтобы стандартизовать как бы нам передавать
SCSI поверх IP-сетей, вместо FC/SAS/Infiniband/whatever решений, которые
просто тупо стали более дорогими (точнее многогигабитный Ethernet стал
сильно дешёвым) решениями. Но сам iSCSI же это не отдельный стэк блочных
устройств в user-space: iSCSI-демоны в user-space, но почти всё всё
равно же на уровне ядра просасывается.
>Можно достичь снижения поверхности атаки сетевого сервиса, если
>превратить его в отдельную ОС, которая умеет только то, что нужно
>сервису (includeOS). Если такой сервис взломают, то не получат всего
>богатства runtime-возможностей для реконфигурации, которые предоставляют
>типичные ОС.
>
>Ещё более сильная изоляция прикладных приложений друг от друга, как в
>Qubes OS.
>
>Все эти направления возникли оттого, что типичная ОС не может
>предоставить интерфейс, который бы подходил идеально под любые задачи.
Описанные выше примеры (сужение attack surface) возникли (с моей точки
зрения, конечно же) потому что не доверяют ОС в плане безопасности.
Qubes OS это такая попытка быстрого хака чтобы сильнее изолировать друг
от друга софта -- она стоит того, если действительно на разработку Qubes
потрачено мало средств, он не сильно мешает работе, зато уменьшает
attack surface. Но это всё равно костыль, не от хорошей жизни. Если
Qubes дешёв в разработке, то простительно. Но если компании больше
тратят средств на изобретение костылей, чем на решение реальных проблем
из-за чего эти костыли возникают, то ничего хорошего не выйдет (и не
выходит, как я вижу с броузерами). Всему нужна разумная мера. А уж для
броузера вообще не много чего нужно от ОС. И, повторюсь, задачи
аутентификации DNS не должно стоять в броузере вообще -- не его это дело.
>Не понял. Как связаны IPsec и большое количество IP-адресов на руках?
Не от хорошей жизни, не от совершенства ОС :-): на практике у меня
получается поднимать и работать с IPsec-ом только когда терминируются
многочисленные IP-шники между собой. Например вот у меня есть VPS-ка на
которой slave DNS и recursive DNS подняты. И мне хочется, очевидно,
чтобы от моего компьютера до них был трафик зашифрован. Но я хочу чтобы
эти две задачи (master<->slave и local recursive DNS<->remote recursive)
ходили по двумя разным ESP SPI. Хочется потому что просто удобно видеть
в трафике два разных SPI. Возможно я просто не умею работать с
strongSwan (что очень вероятно), но вроде ему никак нельзя сказать чтобы
он делал два разных SPI для трафика дифференцируя его (например) по
портам TCP/UDP. Он всё равно увидит одинаковые endpoint-ы "туннелей"
(хотя я транспортный режим по факту для этого использую) и сделает один
SPI. А authoritative DNS у меня ещё и за DNSCurve, но мне хочется иметь
возможность стукнутся в DNSCurve-wrapped версию authoritative DNS и в
"чистую" версию, сразу же в NSD демон. Для этого можно поднять их на
разных портах, но геморрой. Или я хотел бы делать per-socket IPsec
туннель. Одно TCP соединение с каким-то сервером, предоставляя один
X.509 сертификат для аутентификации, а другое с другим. Это
полувыдуманный use-case, который на FreeBSD (например) всё равно не
будет работать, потому что PF_KEY не держит в ней передачу ID, но на
данный момент штатно никто не позволит из коробки легко делать два
туннеля с одними и теми же endpoint-ами. То есть, с точки зрения
ISP/IKEv2 нет никаких ограничений на это, но реализации не могут. Их
тоже можно понять: strongSwan вообще только некий subset IKEv2
возможностей использует, упрощая жизнь администратору и, с без того не
простым, IPsec стэком. Первые мои примеры в принципе то к IPsec никак не
относятся -- но по ним я на практике вижу насколько же упрощается жизнь!
Если чего-то хочется поднять более чем одного на одном IP, то в "legacy
Internet" (IPv4) вынуждены дифференцировать демонов по
TCP/UDP/SCTP/whatever портам, а тут можно просто по IP-шникам, что,
лично для меня, в стократ удобнее. Просто раз IPsec терминирует не
TCP/UDP-порты, как это делают большинство других "VPN" решений (IPsec
это всё же не только VPN), а IP-адреса, то при желании поднять более чем
один ESP-канал, возникают проблемы/ограничения, хотя сам ESP и позволяет
их дифференцировать по SPI.
- комментарий 4:
From: Sergey Matveev
Date: 2020-08-17 08:29:45Z
*** Sergey Matveev [2020-08-17 10:13]:
>>Виртуализация storage. iSCSI, NVMe-OF — SPDK.
>iSCSI-демоны в user-space, но почти всё всё равно же на уровне ядра просасывается.
Я понял про что ты, спустя время :-). Часть iSCSI стэка в ядре это же
тоже костыль придуманный уже позже, как придумывают же TLS-in-kernel. А
так то да, iSCSI это обычное TCP userspace приложение. Просто с iSCSI
или каким-нибудь ATA-over-Ethernet (совсем уж простым) нормально можно
как с IPsec: часть в ядре (транспорт весь), ну а управление/согласование
в userspace, как я понял в Linux SCST так и делает по сути. Я iSCSI
трогал почти лет десять назад и уже мало что помню про него.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF