Общесистемный TLS MITM Proxy

Для других протоколов, например DNS, такого не происходит

В браузерах вполне себе происходит, если использовать DoH.

И это печально.

Для других протоколов, например DNS, такого не происходит

В браузерах вполне себе происходит, если использовать DoH.

Это какой-то всратый костыль. У меня DoH через системный ресолвер работает.

Хотя то, что браузер пытается быть ОС внутри себя, тоже не слишком радует.

А можно смежный вопрос задать: почему вообще исторически провайдеры предоставляют собственные кеширующие DNS-резолверы (и никакая операционная система из коробки даже не умеет обращаться рекурсивно к DNS самостоятельно), а для веба был выбран другой путь, с прямыми запросами?

а для веба был выбран другой путь, с прямыми запросами

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

Я не про DNS-запросы, а про отсутствие некого централизованного прокси-сервера у провайдера для веба в качестве стандартной услуги, как с DNS, либо локального кеширующего сервиса в ОС (как это с DNS).

Иными словами, для работы DNS-резолва должен либо использоваться резолвер в интернете (провайдерский или сторонний), либо специальное ПО, выполняющее рекурсивный резолвинг. ОС этого не умеет.

Почему веб исторически устанавливал соединение к запрашиваемым ресурсам напрямую, а не требовал установки общесистемного или провайдерского (или стороннего) прокси-сервера?

Слишком жирный трафик? Плюс, в последние лет 15 с повсеместным HTTPS это просто неактуально. Но в эпоху домовых локалок и наколеночных провайдеров вроде у некоторых были в том числе кеширующие прокси, я что-то такое точно припоминаю.

Это троллинг ОПа?

1. ДНС «исторически» вообще не было. Был файлик hosts. Потом несколько конкурирующих решений, среди которых победил ДНС.

2. Во времена isdn / dial-up’а почти все «серьёзные» провайдеры предоставляли клиентам бесплатно свои прокси-сервера для http / ftp / nntp.

3. Абсолютно любой протокол из прошлого тысячелетия подразумевал, что два компьютера ходят напрямую к друг другу. В т. ч. ДНС. «Не напрямую» - это наты и прочие STUN/TURN.

Кеширующий Squid был довольно популярен на заре интернета, его добил массовый переход на HTTPS.

Тем не менее, он не был «стандартным» сервисом у провайдеров.

LamerOk

Потом несколько конкурирующих решений, среди которых победил ДНС.

Хорошо, но вопрос не об этом.

Вопрос в том, почему ОС/браузер исторически не умеют работать с DNS напрямую (рекурсивно резолвить, начиная с корневых серверов), требуя указать адрес либо провайдерского, либо публичного стороннего, либо локального ПО для этой цели. При этом стандартная библиотека почти любого языка имеет фунции резолва с поддержкой кеширования, кеширование также предоставляется некоторыми ОС.

Это, по моему мнению, сильно перекликается с вопросом ОПа: почему для HTTP нет более «общей» инфраструктуры в ОС и языках программирования, какая есть, например, для DNS?

Во времена isdn / dial-up’а почти все «серьёзные» провайдеры предоставляли клиентам бесплатно свои прокси-сервера для http / ftp / nntp.

NNTP у проайдеров видел, прокси — ни разу. Может, не обращал внимания, или у моих провайдеров не было.

Это, по моему мнению, сильно перекликается с вопросом ОПа: почему для HTTP нет более «общей» инфраструктуры в ОС и языках программирования, какая есть, например, для DNS?

Здесь речь не только и не столько о HTTPS, сколько о шифрованных соединениях в принципе.

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

почему этого ещё вроде как никто не делал.

Такое есть во многих антивирусах/продвинутых файрволлах.

Простота управления сертификатами;

Так она есть, хранилище-то общее.

Возможность централизованно выключать небезопасные алгоритмы;

Так она есть (в некоторых дистрах)

Сильно упрощает дебаг софта с TLS позволяет следить за передаваемыми данными без ptrace.

Так она есть, SSLKEYLOGFILE и вперед

Ничего нового и полезного бы не добавил, одни минусы.

Вопрос в том, почему ОС/браузер исторически не умеют работать с DNS напрямую (рекурсивно резолвить, начиная с корневых серверов)

Чтоб не дай $DEITY не теребили корневые сервера.

почему этого ещё вроде как никто не делал.

Такое есть во многих антивирусах/продвинутых файрволлах.

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

почему ОС/браузер исторически не умеют работать с DNS напрямую (рекурсивно резолвить, начиная с корневых серверов), требуя указать адрес либо провайдерского, либо публичного стороннего,

Потому что таковы были требования при создании DNS - к корневым серверам обращаться нельзя. (Перегруз / разрыв связи). Теоретически трафик к ним мог быть вообще заблочен, кроме белого списка.

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

Гугли Arch Wiki DNS Over TLS. Линупс его поддерживает

❯ cat /etc/NetworkManager/conf.d/dns.conf
[main]
dns=none
❯ cat /etc/systemd/resolved.conf
...
[Resolve]
DNS=94.140.14.14
FallbackDNS=94.140.14.15
DNSSEC=yes
DNSOverTLS=yes
...
❯ cat /etc/resolv.conf
nameserver 127.0.0.53

Ест-но все затронутые сервисы нужно перезапустить

Простота управления сертификатами;

Так она есть, хранилище-то общее.

Нет. У браузеров своё. Некоторые проги так же свои сертификаты пытаются юзать.

Возможность централизованно выключать небезопасные алгоритмы;

Так она есть (в некоторых дистрах)

В каких? В NixOS нету.

Сильно упрощает дебаг софта с TLS позволяет следить за передаваемыми данными без ptrace.

Так она есть, SSLKEYLOGFILE и вперед

На эту хрень многие болт кладут. Плюс, она требует перезапуска софта и не работает назад во времени (лол).

Ничего нового и полезного бы не добавил, одни минусы.

Какие?

Нет. У браузеров своё. Некоторые проги так же свои сертификаты пытаются юзать.

Так люлей им, и за дело. На уровне дистра выпатчи.

В каких? В NixOS нету.

В Fedora/RHEL/… есть crypto-policies. В NixOS такого действительно нету.

На эту хрень многие болт кладут.

Как ты на это положишь болт, когда она в openssl/gnutls/nss/…? Свой TLS-стек забубенишь чисто ей назло?

Плюс, она требует перезапуска софта и не работает назад во времени (лол).

Воистину лол.

Тем не менее, он не был «стандартным» сервисом у провайдеров.

Провайдеры продавали пакеты трафика, какой смысл кэшировать его? Вот потребители squid вовсю ставили.

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

Ну DoH то не нужен, это маркетинг инет-гигантов которые хотят ещё больше монополизировать ситуацию.

Вопрос в том, почему ОС/браузер исторически не умеют работать с DNS напрямую (рекурсивно резолвить, начиная с корневых серверов)

Потому что корневые серверы не хотят чтоб их кто попало рекурсивно резолвил, и авторы ОС, как приличные люди, не стали встраивать этот вредоносный (в точки зрения корневых днс) функционал в них. Такой негласный договор: к корневым днсам обращаются только провы и кешируют у себя их ответы на всех своих клиентов.

Это, по моему мнению, сильно перекликается с вопросом ОПа: почему для HTTP нет более «общей» инфраструктуры в ОС и языках программирования, какая есть, например, для DNS?

Аналогия не уместна - http-сервера не подвергаются нагрузке от всего мира сразу, у них обычно мало клиентов. А те, у кого много - такую систему частично сами реализовали (ютуб), но она требует затрат, кто-то должен оплачивать.

Провайдеры вполне ставили squid и рекомендовали юзерам его использовать для экономии трафика. Финансовых и учётных подробностей не знаю.

Так люлей им, и за дело. На уровне дистра выпатчи.

А говоришь, нет улучшений.

Смотри. Генеришь системный CA-серт, заворачиваешь все соединения на 80 и 443 порты на проксю с этим сертом, прямые соединения блокируешь. Уже профит.

В Fedora/RHEL/… есть crypto-policies. В NixOS такого действительно нету.

Отлично, NixOS говно ещё по одной причине.

Как ты на это положишь болт, когда она в openssl/gnutls/nss/…? Свой TLS-стек забубенишь чисто ей назло?

Легко? Это переменная окружения, её не проблема дропнуть.

Ну DoH то не нужен, это маркетинг инет-гигантов которые хотят ещё больше монополизировать ситуацию.

DoH нужен чтобы твой провайдер не читал твой DNS-трафик. Просто не надо ресолверы от CF или гугла использовать. Используй нормальный.

Отлично, NixOS говно ещё по одной причине.

Так 90+% дистров будут говно, потому что там нет нашего эксклюзивчика.

Легко? Это переменная окружения, её не проблема дропнуть.

Еще можно яйца…

Я уже писал где-то и тут повторю: прятать от провайдера dns-трафик затея глупая и бесполезная. Туда же отправляется и мода на ESNI, преследующая те же цели.

Провайдер и так видит к каким хостам (ip) ты подключаешься. В норме, когда сайт хостится в нормальном месте, по ip адресу легко определяется и домен. Домен может быть сложно определить только в случае если сайт либо спрятан за вредительским митмфларом, либо хостится у ещё какого-то интернет-монополиста, который за один айпи-адрес вешает кучу несвязанных друг с другом сайтов.

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

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

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

Я уже писал где-то и тут повторю: прятать от провайдера dns-трафик затея глупая и бесполезная.

Ты много чего пишешь, но половина из этого – ересь. Ты ещё и в сишечке мимо стека любишь посрать.

Туда же отправляется и мода на ESNI, преследующая те же цели.

Да нет, ESNI вполне полезен и хорошо работает.

Провайдер и так видит к каким хостам (ip) ты подключаешься.

Ичо? Если это жирный CDN, то провайдер видит только подключение к жирному CDN. Что и требуется.

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

Конечно следует. А ещё следует бороться с провайдерами, сливающими инфу о моём трафике налево.

В принципе, тут можно написать, что весь существующий стек протоколов TCP/IP – неадекватные наслоения говна, обоссаные сверху, и это всё надо выкинуть. Но увы и ах, мы существуем в неидеальном мире вещей и приходится пользоваться тем, что нам доступно.

Ичо? Если это жирный CDN, то провайдер видит только подключение к жирному CDN. Что и требуется.

Я же дальше пояснил: жирные cdn следует демонополизировать, так что опираться на их функционал и поощрять их существование нельзя.

А ещё следует бороться с провайдерами, сливающими инфу о моём трафике налево.

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

Ты ещё и в сишечке мимо стека любишь посрать.

И опять балабольство, кстати, пруфы ты так и не привёл.

Я же дальше пояснил: жирные cdn следует демонополизировать, так что опираться на их функционал и поощрять их существование нельзя.

Как одно следует из другого?

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

Пока что законодательные меры обязывают провайдеров так же перехватывать и сохранять весь трафик. Что-то твой подход не работает.

В принципе, по части враждебности между теми CDN и твоим провайдером особой разницы нет вообще. Единственная разница – твой провайдер охотнее сдаст тебя твоим же ментам, чем заморский CF.

Как одно следует из другого?

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

Пока что законодательные меры обязывают провайдеров так же перехватывать и сохранять весь трафик. Что-то твой подход не работает.

Сохранять - норм. Надо чтобы не сливали налево.

В принципе, по части враждебности между теми CDN и твоим провайдером особой разницы нет вообще.

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

Единственная разница – твой провайдер охотнее сдаст тебя твоим же ментам, чем заморский CF.

Что значит «сдаст»? У него нечего сдавать ментам, посещение каких бы то ни было интернет-доменов (в том числе тех что в ркн списках, хотя их через прова напрямую посетить и не получится) не может являться преступлением.

Сохранять - норм. Надо чтобы не сливали налево.

Одно всегда следует за другим. Вообще всегда. No exceptions. Твои данные могут просто утечь.

Провайдер находится в юрисдикции, которая декларирует защиту моих прав, cf - нет.

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

Что значит «сдаст»? У него нечего сдавать ментам, посещение каких бы то ни было интернет-доменов (в том числе тех что в ркн списках, хотя их через прова напрямую посетить и не получится) не может являться преступлением.

Что будет в твоём случае являться преступлением, решит товарищ майор. Твоё мнение здесь не играет роли вообще.

Ладно, всё, завязываем с нацполом.

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

А вообще, все описываемые тобой плюсы даёт libssl.so, равно как и минусы, впрочем. Но по крайней мере вариант с libssl.so не провоцирует идеи типа «а давайте разгрузим наши клиентские машины, перенеся работу по шифрованию на корпоративный сервер, всё равно же если на сервак попал зловред, то всё уже слишком плохо».

Но по крайней мере вариант с libssl.so не провоцирует идеи типа «а давайте разгрузим наши клиентские машины, перенеся работу по шифрованию на корпоративный сервер, всё равно же если на сервак попал зловред, то всё уже слишком плохо».

У меня локальный прокси таких идей тоже не провоцирует почему-то.

Ну тут есть 2 варианта, возможно ты просто недостаточно креативен, и тебе такая оптимизация в голову не пришла. Или у тебя нет довольно мощного сервера + кучи старых тормозящих клиентских машин (ssl развивался давно, когда в CPU не было специальных инструкций для ускорения шифрования).

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

Очень интересную тему затронули, весело было читать комментарии, хотя я вообще не понял даже из комментов, что именно хочет автор.
То есть я примерно понимаю про ДНС, но шо тут обсуждается про TLS – не разобрал.
Приглашаю общественность в мой тред Бесплатный PEM-сертификат https для 10-15-и имен. Сейчас использую CF ))

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

Это не оптимизация.

Или у тебя нет довольно мощного сервера + кучи старых тормозящих клиентских машин (ssl развивался давно, когда в CPU не было специальных инструкций для ускорения шифрования).

Хахахахахахахахах! Это каких? Что-то типа Pentium 200 mmx? Ну да, нету.

Сохранять - норм. Надо чтобы не сливали налево.

Правоохранительные структуры – самый большой источник утечек персональных данных.

Лулз в том что оно по сути так и работает, потому что настройки openssl общие, ca-certificates общие. Проблемы начинаются когда в дело вступает какой-нибудь флатпак.

Это не оптимизация.

Это оптимизация. Ты придумал мега-(ну или говно-)идею, а я придумал как добиться того же, но лучше :)

Хахахахахахахахах! Это каких? Что-то типа Pentium 200 mmx? Ну да, нету.

Ты в курсе когда разрабатывалась SSL? Вики говорит, что спецификация 2й версии вышла в 1995.

Так что да, не Pentium 200mmx, скорее мощный сервер будет с Pentium 133, а клиентские машины вроде 486 для тех, кому повезло, и 386 для остальных.

Это оптимизация. Ты придумал мега-(ну или говно-)идею

Заметь, нигде в моём изначально посте вопрос производительности не стоит в принципе. Здесь исключительно об удобстве управления.

а я придумал как добиться того же, но лучше :)

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

Так что да, не Pentium 200mmx, скорее мощный сервер будет с Pentium 133, а клиентские машины вроде 486 для тех, кому повезло, и 386 для остальных.

Ты в музее работаешь? В любом случае, это говно настолько неактуально, что на него даже оглядываться не стоит.

Я уже писал где-то и тут повторю: прятать от провайдера dns-трафик затея глупая и бесполезная.

Ну кроме провайдеров есть ведь более гнусные люди. Школоло с соответствующими прогами по перехвату трафика. Раньше рекомендовали даже впн использовать в местах общественного пользования. Но потом, правда «была доказана его неэффективность» Мне провайдеры как то поровну - я всегда проголосую кошельком при смене оного.

Заметь, нигде в моём изначально посте вопрос производительности не стоит в принципе.

И каким боком это возражение мне? Ты не думал, поэтому неоптимально. А я вот подумал, стало оптимально.

Ну и я писал не об оптимизации производительности, а скорее об оптимизации затрат. Чем апгрейдить весь парк лучше 1 мощный сервер, который возьмёт на себя задачу. Не все же машины одновременно шифруют трафик, так что 1 сервер мог оказаться выгоднее чем массовый апгрейд.

Здесь исключительно об удобстве управления.

Это же удобство достигается работой с системным libssl.so.

В принципе идея городить сервер имеет смысл либо в случае если подразумевается вынос этого сервера на другую машину (что для SSL абсурдно), либо если есть какая-то необходимость обращения из одного процесса.

В остальных случаях это просто дурная работа. Потребуется протокол для этого сервера, клиентская библиотека. Чтоб файрвол мог исполнять правила вида «этой проге нельзя на этот IP» нужно будет либо дублировать в конфиге твоего прокси, либо дополнительный протокол для подключения файрвола.

Да и почему только SSL? Например, почему бы не вынести в сервер FP-арифметику? Напоминаю, мы мысленно в 1995 году, когда FPU были не в каждом процессоре, а ещё был баг с делением на пентиуме, так что центральный FP-сервер в системе можно было оправдать твоими же текущими аргументами, включая оперативное наложение заплаток.

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

И что за проблема? Ethernet по коаксиалу уже давно не делают, витая пара, все соединения точка-точка, маршрутизаторы пакеты посылают на тот порт, на который надо, снифферы как бы не страшны. Почему бы сисадмину не вынести на отдельный, защищённый сервер? Ну т.е. если ты предлагаешь уважать твою уверенность в надёжности локального компа, то почему отказываешься уважать такую же уверенность нашего гипотетического сисадмина?

Смотри, он в твою схему добавил только провода локалки, маршрутизатор и сервер. Если он во всём этом уверен, почему нет?

Ты в музее работаешь? В любом случае, это говно настолько неактуально

В тебе находится блуждающий нерв, который примерно полмиллиарда лет назад у предка рыбы обогнул артерию не с той стороны и с тех пор проходит так что его назвали блуждающим. Чё там какой-то 1995 год. Архитектура SSL формировалась в то время, поэтому разумно смотреть, как бы всё развернулось, если бы спроектировали как ты предлагаешь. Сейчас всё переделывать никто не будет, разве что ты сам запилишь drop-in замену libssl.so и соответствующий сервер. Но ввиду того что все в общем-то ожидают честной работы libssl, половина софта окажется со статически прилинкованной, часть с собственной реализацией, в общем перехват тебе обломают.

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

Админообслуга не может не лезть в чужую жизнь, лол.

почему, собственно, каждая программа, лезущая в сеть, сама занимается разруливанием сертификатов, шифрованием и так далее?

Так сложилось исторически.

Для других протоколов, например DNS, такого не происходит и в DNS используется системный ресолвер

Далеко не всегда.

Есть ли смысл городить по аналогии общесистемный TLS Proxy?

Нет смысла. Никто на него не перейдёт.

Прокся может стать узким местом по производительности (вряд ли сильно актуально);

Почему ты считаешь, что не актуально? Сколько-то сожрёт. Тебе не актуально, а за всех ты это не решишь.

Кстати подумал ещё и здравое зерно в этой идее есть.

На старых компьютерах есть проблема с использованием интернета. Куча сайтов нормально или со скрипом, но работают под старыми браузерами. Но всё портит TLS. Старые браузеры в современные стандарты не умеют.

Поэтому можно сделать такую прокси. Проще всего это реализовать как HTTP прокси. В этот стандарт умеют практически все. Запускается на локалхосте и решает проблемы с TLS. Такую программу можно скомпилировать и так, что она хоть на Windows 95 будет работать.

Подозреваю, что есть люди, которым это может пригодиться.

У меня тут навязчивые мысли в голову бредут. А почему, собственно, каждая программа, лезущая в сеть, сама занимается разруливанием сертификатов, шифрованием и так далее? Для других протоколов, например DNS, такого не происходит и в DNS используется системный ресолвер.

Ну это, мягко говоря, не так. Программа, которой нужен, DNS, вызывает функцию типа gethostbyname() из libc, а libc смотрит в resolv.conf. Программа, которой нужен TLS, вызывает функции из SSL-библиотеки, которые смотрят в /etc/ssl. Единственная разница в том, что SSL-библиотек несколько на выбор. Частично это объясняется неудобными лицензиями у OpenSSL и GnuTLS.

проголосую кошельком

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