forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS, opennews (??), 04-Май-22, (0) [смотреть все]

Никогда не было, и вот опять, Аноним (1), 14:40 , 04-Май-22, (1) +4 //

Опять детский сад и школа виноваты 128064 , Аноним (43), 22:46 , 04-Май-22, (43)

Скрыто модератором, Аноним (2), 14:43 , 04-Май-22, (2) –6 //

Скрыто модератором, Аноним (7), 15:04 , 04-Май-22, (7) +3 //

Скрыто модератором, НяшМяш (ok), 15:18 , 04-Май-22, (13) +6

Скрыто модератором, Аноним (10), 15:10 , 04-Май-22, (10)

Скрыто модератором, Аниме (?), 14:44 , 04-Май-22, (3) //

Скрыто модератором, Аноним (7), 15:06 , 04-Май-22, (8)

Не, ну с printf было забавнее, я так понимаю у них у всех качество кода примерно, Аноним (4), 14:48 , 04-Май-22, (4) +2
OpenWRT же на musl переезжал, нет , timur.davletshin (ok), 14:54 , 04-Май-22, (5) +1 //

Деды-пердуны на 19 07 могут иметь uClibc, Мохнатый пись (?), 15:11 , 04-Май-22, (11) //

Там тоже musl , timur.davletshin (ok), 15:47 , 04-Май-22, (16) +1

Там же тоже какие-то застаревшие проблемы с сетью, с тем же DNS, нет , Аноним (18), 16:19 , 04-Май-22, (18) //

Нет , timur.davletshin (ok), 16:20 , 04-Май-22, (19) //

А пишут, что musl based but still immature with a lot of network issues, glibc, Аноним (18), 16:31 , 04-Май-22, (21)

Ты накидывай лучше сразу ссылки на уязвимости в DNS, а не языком по широкому хол, timur.davletshin (ok), 16:37 , 04-Май-22, (22) +3

Есть и musl, и glibc https openwrt org releases 22 03 notes-22 03 0-rc1, Nr (?), 17:03 , 04-Май-22, (27)

Это тулчейн Как оно компиляется по большому счёту никому нет дела А libc в сам, timur.davletshin (ok), 18:23 , 04-Май-22, (33)

ага, например, musl не умеет в DNS через TCP, Аноним (29), 17:56 , 04-Май-22, (29) //

То есть DoT DoH в Alpine Linux не будет работать , Аноним (18), 19:32 , 04-Май-22, (36) –1

DoT DoH не через libc работают, ilyafedin (ok), 06:45 , 06-Май-22, (55)

UDP маздай , Аноним (6), 15:02 , 04-Май-22, (6) –3 //

Однако, NAT он пробивает лучше, чем TCP , Аноним (7), 15:07 , 04-Май-22, (9) //

NAT не нужен, но UDP ещё и канал лучше утилизирует , Мохнатый пись (?), 15:13 , 04-Май-22, (12) –1 //

Он использует те же алгоритмы управления потоком, что и TCP Просто напулять пак, timur.davletshin (ok), 15:52 , 04-Май-22, (17)

QUIC может использовать свои алгоритмы для проверки доставки , Мохнатый пись (?), 16:31 , 04-Май-22, (20) –1

Проверка доставки или всё же управление потоком Так-то в подавляющем большинств, timur.davletshin (ok), 16:42 , 04-Май-22, (23)

QUIC - синдром NIH Гугли , Аноним (7), 16:47 , 04-Май-22, (25) +1
Потому что это разные задачи Разным задачам, разные решения Ты не знал об этом, Аноним (-), 18:02 , 04-Май-22, (30) –1

Господин, вы бредите Когда-нибудь на досуге попробуй джиттер померять в userspa, timur.davletshin (ok), 18:16 , 04-Май-22, (31)

Нет ты Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи Если ты, Аноним (-), 18:37 , 04-Май-22, (34) –1

Читай внимательно, что я написал Мне до твоего HTTPS дела нет, я писал про упра, timur.davletshin (ok), 19:42 , 04-Май-22, (37)

Вирегад в ядро вытащен только по одной причине, по той же, по которой опенжпн св, Онаним (?), 09:40 , 06-Май-22, (56) –1

Т е QUIC в таком случае не должен существовать Спасибо, что хоть на таком уров, timur.davletshin (ok), 10:14 , 06-Май-22, (57)
Клюк в ядре не нужен Он вполне может существовать в юзерспейсе - пакеты приходя, Онаним (?), 13:49 , 06-Май-22, (58)
А чё он тогда на 30 жручее до CPU В чём профит тогда В обновляемости congesti, timur.davletshin (ok), 15:43 , 06-Май-22, (59)
Жручее по сравнению с чем , Онаним (?), 17:06 , 06-Май-22, (60)
В сравнении с TCP , timur.davletshin (ok), 18:56 , 06-Май-22, (62)
Э, а ничего, что там SSL сверху Тогда уж с HTTPS сравнивай , Онаним (?), 19:21 , 06-Май-22, (63)
Сравнивали и не один раз https www fastly com cimages 6pk8mg3yh2ee 495gZP7ZprK, timur.davletshin (ok), 21:45 , 06-Май-22, (64)
Опять какое-то тёплое с мягким Можно CPU usage при одинаковом throughput, а не с, Онаним (?), 22:04 , 06-Май-22, (65)
Можно https conferences sigcomm org sigcomm 2020 files slides epiq 0 20QUIC 2, timur.davletshin (ok), 22:25 , 06-Май-22, (67)
Опять какие-то сферические гуглы в вакууме Но даже если попытаться из этой ахине, Онаним (?), 18:20 , 08-Май-22, (68)
Но кстати вот эта смузи-презенташка моё предположение подтвердила неожиданно, ра, Онаним (?), 18:22 , 08-Май-22, (69)
К слову, в том, что кряк - говно, я не сомневаюсь ни разу Но там дело не в том, , Онаним (?), 22:06 , 06-Май-22, (66)
И да, всё правильно В обновляемости алкоритмов, написанных с бодуна под смузи , Онаним (?), 17:06 , 06-Май-22, (61)

Разрабы Google, выходит, у тебя лохи печальные, а в Wireguard ну просто гении Д, timur.davletshin (ok), 19:47 , 04-Май-22, (38)

Скажи это провайдерам , Аноним (7), 16:44 , 04-Май-22, (24)

Говорю каждый раз, пора бы уже ipv6 внедрять Внедрение ipv6 во всём постсовсовк, Мохнатый пись (?), 17:20 , 04-Май-22, (28)

Открою тебе секрет - и не только в постсовке У нас есть полтора пользователя IPv, Онаним (?), 23:58 , 04-Май-22, (45)
нет, мы можем всем выдать по 64 автоматом, и даже пробовали на все серверы его, Онаним (?), 00:00 , 05-Май-22, (46)

А не зашло потому, что какому-то beep пришло в дурную голову AAAA при резолве , Онаним (?), 00:02 , 05-Май-22, (47)

Кулстори какие-то Сижу через туннель, ибо провайдер дебил, пинг из-за европейск, Мохнатый пись (?), 00:34 , 05-Май-22, (49) +1

Эдак у вас число пользователей уменьшаться начнёт, а не вырастет , Онаним (?), 22:05 , 05-Май-22, (51) +1
Ну а чего кулстори Есть провайдеры в местных ну, не местных, соседние страны , Онаним (?), 22:21 , 05-Май-22, (52)

Это сейчас ещё хецнеровские туннели убились - стало полегче, раньше можно было л, Онаним (?), 22:22 , 05-Май-22, (53)

Теперь народ начнёт понимать, почему glibc такая жирная 128578 , pashev.ru (?), 15:40 , 04-Май-22, (15) +1 //

Думаешь в glibc нет бэкдоров Поверь мне, их там еще больше , Аноним (32), 18:20 , 04-Май-22, (32) –1 //

Системы с glibc обычно не проблема обновить А вот то, где uclibc - многое из это, Онаним (?), 19:53 , 04-Май-22, (39) //

Обновишь и получишь еще больше бэкдоров, руткитов, вирусов, телеметрии, малвари , Аноним (41), 22:31 , 04-Май-22, (41)

Всё ещё сидишь на ядре 2 0 , Онаним (?), 22:33 , 04-Май-22, (42) +1

Все кто любят юникс, первым делом выпиливают юниксовые убства в первую очередь, Аноним (-), 18:44 , 04-Май-22, (35)

Гордый суффикс -ng прикрутили, а на прикрутить рандом не в состоянии исправит, Аноним (40), 21:30 , 04-Май-22, (40) +1

Сообщения [Сортировка по времени | RSS]

12. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." –1 +/–

Сообщение от Мохнатый пись (?), 04-Май-22, 15:13

NAT не нужен, но UDP ещё и канал лучше утилизирует.

Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от timur.davletshin (ok), 04-Май-22, 15:52

Он использует те же алгоритмы управления потоком, что и TCP. Просто напулять пакетов без проверки доставки можно больше, но кому такое нужно? Даже realtime видео нафиг не упало, если оно рассыпается на кашу из квадратов.

Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." –1 +/–

Сообщение от Мохнатый пись (?), 04-Май-22, 16:31

QUIC может использовать свои алгоритмы для проверки доставки.

Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от timur.davletshin (ok), 04-Май-22, 16:42

> QUIC может использовать свои алгоритмы для проверки доставки.
Проверка доставки или всё же управление потоком? Так-то в подавляющем большинстве реализаций обычный CUBIC стоит в дефолте. Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей? Вам не кажется, что где-то в одном из двух случаев логика даёт сбой и создатели протокола просто "залечивают" без должного обоснования.

Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +1 +/–

Сообщение от Аноним (7), 04-Май-22, 16:47

QUIC - синдром NIH Гугли.

Ответить | Правка | Наверх | Cообщить модератору

30. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." –1 +/–

Сообщение от Аноним (-), 04-Май-22, 18:02

> Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей?
Потому что это разные задачи. Разным задачам, разные решения. Ты не знал об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

31. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от timur.davletshin (ok), 04-Май-22, 18:16

> Потому что это разные задачи. Разным задачам, разные решения. Ты не знал
> об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда.
Господин, вы бредите. Когда-нибудь на досуге попробуй джиттер померять в userspace реализациях и в kernel. Гарантирую, ты прозреешь. Как ресэмплинг звука в userspace вынесли, так все начали ныть про кривой pulseaudio, хотя он просто старые алгоритмы вынес в пользовательское пространство. В сетевых протоколах есть абсолютно идентичный негативный эффект от подобного переноса и не важно, это VPN или CUBIC/Reno, реализованные поверх UDP.

Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." –1 +/–

Сообщение от Аноним (-), 04-Май-22, 18:37

Нет ты.
Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи. Если ты говоришь, что они принципиально не отличаются по своим требованиям к реализации, то давай обосновывай нам, почему они принципиально не различаются. Давай-давай.
Во-вторых, разработка чего-либо в ядре гораздо дороже. Строчка кода ядра обходится дороже, чем строчка кода юзерспейса. Поддержка этой строчки кода обходится резко дороже. Это ещё помножается на то, что ядерная разработка будет работать только с одним ядром, и если ты хочешь кроссплатформенности, то тебе придётся вести несколько разработок под разные ядра. OpenVPN тоже исходно разрабатывался в юзерспейсе, несмотря на весь этот твой бла-бла-бла про джиттер. Почему? Разработчики, что тупее тебя были? Нет, они как раз были умнее. Они знали, что разработка в ядре дорого, и поэтому нащупывать правильную архитектуру для реализации VPN, правильные структуры данных, правильные алгоритмы, структуру конфига, и всё остальное лучше в юзерспейсе. В юзерспейсе дешевле разрабатывать код, дешевле его мейнтейнить, дешевле дебажить, дешевле профайлить, ошибки (как архитектурные так и вида use-after-free) обходятся и исправляются дешевле, и поэтому в юзерспейсе было возможно разработать OpenVPN, в ядре практически невозможно. Вот теперь, когда накоплен опыт разработки VPN, опыт использования VPN, когда можно профайлить работу VPN со всех сторон, выясняя где и какие бутылочные горлышки возникают, вот теперь можно запилить и ядерную реализацию, причём сразу отливая её в граните так, чтобы потом не перелопачивать каждый год, когда очередная гениальная идея в голову пришла, или когда какое-нибудь важное наблюдение о строчке кода-источнике джиттера было сделано.
Ты, как заурядный опеннетовец, вслепую ощупываешь слона и говоришь, что слон похож на столб. Глаза разуй и посмотри на проблему во всей её неповторимой сложности. Тогда ты, возможно, прекратишь бредить своими деревьями джиттеров, и начнёшь говорить дельные вещи о лесе в целом.
QUIC -- это сырой протокол. Из которого хрен знает, что выйдет, и выйдет ли. Вероятно гугл применил кучу теории, для того, чтобы предсказать результат, но теория на то и теория, чтобы проверяться практикой. Только опеннетовец может ратовать за то, чтобы вбухивать сотни нефти в разработку этого QUIC прям сразу в ядре. Любой разумный человек будет разрабатывать его в юзерспейсе поверх стандартного для многих платформ API сокетов, внедрять на все платформы в юзерспейс, собирать данные с практического применения, и вот только после этого ставить вопрос: а не занести ли QUIC в ядро?

Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от timur.davletshin (ok), 04-Май-22, 19:42

> Нет ты.
> Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи. Если
> ты говоришь, что они принципиально не отличаются по своим требованиям к
> реализации, то давай обосновывай нам, почему они принципиально не различаются. Давай-давай.
Читай внимательно, что я написал. Мне до твоего HTTPS дела нет, я писал про управление потоком в QUIC как пример корявости, т.к. данное действие является задачей близкой к realtime'у. А ведь именно уменьшение накладных расходов на операции подобного приоритета стали обоснованием для выноса протокола Wireguard в ядро. Будто до этого VPN'ов на уровне ядра не было...

Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." –1 +/–

Сообщение от Онаним (?), 06-Май-22, 09:40

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

Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от timur.davletshin (ok), 06-Май-22, 10:14

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

Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 06-Май-22, 13:49

Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе - пакеты приходят всё тому же адресату, который занимается и управлением потоком.
В случае вирегада и прочих впн - пакеты идут через декодер, и снова уходят в ядро - следующему получателю. Разница ощутима?

Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от timur.davletshin (ok), 06-Май-22, 15:43

> Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе -
> пакеты приходят всё тому же адресату, который занимается и управлением потоком.
А чё он тогда на 30% жручее до CPU? В чём профит тогда? В обновляемости congestion control'а? Так фуфло это. Гуглу одинаково легко обновить что bbr.ko, что код веб-сервера. А сторона клиента значения не имеет от слова вообще (если ты только не загружаешь что-то). Я уже не говорю про конкретные реализации QUIC с их конкретными глюками и затупами. Чего только в 2-5 раз более медленная загрузка на Firefox/QUIC стоит.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

60. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 06-Май-22, 17:06

Жручее по сравнению с чем?

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

62. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от timur.davletshin (ok), 06-Май-22, 18:56

> Жручее по сравнению с чем?
В сравнении с TCP.

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

63. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 06-Май-22, 19:21

Э, а ничего, что там SSL сверху?
Тогда уж с HTTPS сравнивай.

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

64. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от timur.davletshin (ok), 06-Май-22, 21:45

> Э, а ничего, что там SSL сверху?
> Тогда уж с HTTPS сравнивай.
Сравнивали и не один раз:
https://www.fastly.com/cimages/6pk8mg3yh2ee/495gZP7ZprKQUsEj...
Если сравнивать BBR vs CUBIC, то первый сливает везде, кроме линий с большим дропом и большой задержкой.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

65. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 06-Май-22, 22:04

Опять какое-то тёплое с мягким.
Можно CPU usage при одинаковом throughput, а не сферических коней в вакууме?
Впрочем я уверен, у QUIC он будет больше - разбирать подобие DTLS (мелкими блоками) - так себе затея.
Другое дело, что он не для передачи гигабит в секунду, он больше для контроля latency на куче смузи-опилок, из которых современные говносайты построены.

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

67. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от timur.davletshin (ok), 06-Май-22, 22:25

> Можно CPU usage при одинаковом throughput, а не сферических коней в вакууме?
Можно: https://conferences.sigcomm.org/sigcomm/2020/files/slides/ep...
Советую почитать выводы. Протокол, который обещал при создании обновления алгоритма без вмешательства в систему, требует сетевое оборудование с GSO и нужно патчить реализацию UDP sendmsg для обеспечения более-менее сравнимой скорости. Я нахожу это ироничным.
> Другое дело, что он не для передачи гигабит в секунду, он больше
> для контроля latency на куче смузи-опилок, из которых современные говносайты построены.
Посмотри обоснование для его создания.

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

68. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 08-Май-22, 18:20

> Можно: https://conferences.sigcomm.org/sigcomm/2020/files/slides/ep...
Опять какие-то сферические гуглы в вакууме.
Но даже если попытаться из этой ахинеи какие-то выводы сделать - то оно реально колышется где-то на уровне HTTPS ныне, плюс минус вечность в зависимости от имплементации.

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

69. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 08-Май-22, 18:22

Но кстати вот эта смузи-презенташка моё предположение подтвердила неожиданно, разбирать и слать DTLS - очень накладно.
Но я вангую что с клюком нас ждёт огромная масса смешного секса, и в итоге оно будет о полутора землекопах. Не потому, что там с производительностью плохо. Я тут погуглил на тему интеропа имплементаций этого счастья, и мне поплохело.

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

66. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 06-Май-22, 22:06

К слову, в том, что кряк - говно, я не сомневаюсь ни разу.
Но там дело не в том, что он не в ядре.
Дело в попытке соплями и скотчем примотать L4 к L7.

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

61. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 06-Май-22, 17:06

И да, всё правильно. В обновляемости алкоритмов, написанных с бодуна под смузи.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

38. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от timur.davletshin (ok), 04-Май-22, 19:47

> Почему? Разработчики, что тупее тебя были? Нет, они как раз были умнее.
> QUIC -- это сырой протокол. Из которого хрен знает, что выйдет, и
> выйдет ли. Вероятно гугл применил кучу теории, для того, чтобы предсказать
> результат, но теория на то и теория, чтобы проверяться практикой.
Разрабы Google, выходит, у тебя лохи печальные, а в Wireguard ну просто гении. Дружище, научись писать внутренне непротиворечивые тексты для начала. А там, может, и до деталей реализации RTP дойдём.

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

24. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Аноним (7), 04-Май-22, 16:44

Скажи это провайдерам.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

28. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Мохнатый пись (?), 04-Май-22, 17:20

Говорю каждый раз, пора бы уже ipv6 внедрять. Внедрение ipv6 во всём постсовсовке на уровне стран африки.

Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 04-Май-22, 23:58

Открою тебе секрет - и не только в постсовке.
У нас есть полтора пользователя IPv6, Европа, причём западная.
Они даже им вроде как пользуются.
Но абсолютное и подавляющее большинство им не интересуется вообще.
Не взлетело.

Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 05-Май-22, 00:00

(нет, мы можем всем выдать по /64 автоматом, и даже пробовали на все серверы его развесить (не зашло, поубирали) - и после бодро отрапортоваться о 100% пенетрации, но клиентам от этого будет только хуже - жалобы на откровенно хреновую работу при попытке подобное делать были, есть, и будут есть)

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

47. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 05-Май-22, 00:02

А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA при резолве DNS сделать приоритетным.
В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика иметь 80-120, а то и вообще ничего не иметь, и начинают жаловаться.

Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +1 +/–

Сообщение от Мохнатый пись (?), 05-Май-22, 00:34

> А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA
> при резолве DNS сделать приоритетным.
> В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика
> иметь 80-120, а то и вообще ничего не иметь, и начинают
> жаловаться.
Кулстори какие-то. Сижу через туннель, ибо провайдер дебил, пинг из-за европейского сервера выше на 80мс до яндекса. И знаешь что? Различий вообще почти не вижу, может у вас такая реализация была классная? А чтобы колическо пользователей выросло, то надо свои роутеры через TR-69 настраивать и пользователям говорить, чтобы ipv6 включали, либо (что менее вероятно из-за кривых приложений с захардкоженным ipv4 адресом) сразу отрубать ipv4, выпускать только с ipv6 и NAT64. Так кстати некоторые новые провайдеры делают и мобильные операторы, ибо ipv4 уже на вес золота.

Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +1 +/–

Сообщение от Онаним (?), 05-Май-22, 22:05

> отрубать ipv4, выпускать только с ipv6 и NAT64
Эдак у вас число пользователей уменьшаться начнёт, а не вырастет.

Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 05-Май-22, 22:21

Ну а чего кулстори. Есть провайдеры в местных (ну, не местных, соседние страны) залупищенсках, трасса по IPv6 от которых идёт через такие дрындыня, что закачаешься. И вот когда на сервере вывешиваешь IPv6, из этой страны начинают ходить по болотам вприпрыжку, потому что академичные дятлы заприорили AAAA, всем по IPv6 и нивалнуед, что там потери, и лейтенси двукратный. А между странами всего 150 км расстояния, и они друг к другу в магазины ходят :D

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

53. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..." +/–

Сообщение от Онаним (?), 05-Май-22, 22:22

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	12. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	–1 +/–
	Сообщение от Мохнатый пись (?), 04-Май-22, 15:13
	NAT не нужен, но UDP ещё и канал лучше утилизирует.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от timur.davletshin (ok), 04-Май-22, 15:52
	Он использует те же алгоритмы управления потоком, что и TCP. Просто напулять пакетов без проверки доставки можно больше, но кому такое нужно? Даже realtime видео нафиг не упало, если оно рассыпается на кашу из квадратов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	–1 +/–
	Сообщение от Мохнатый пись (?), 04-Май-22, 16:31
	QUIC может использовать свои алгоритмы для проверки доставки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от timur.davletshin (ok), 04-Май-22, 16:42
	> QUIC может использовать свои алгоритмы для проверки доставки. Проверка доставки или всё же управление потоком? Так-то в подавляющем большинстве реализаций обычный CUBIC стоит в дефолте. Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей? Вам не кажется, что где-то в одном из двух случаев логика даёт сбой и создатели протокола просто "залечивают" без должного обоснования.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+1 +/–
	Сообщение от Аноним (7), 04-Май-22, 16:47
	QUIC - синдром NIH Гугли.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	–1 +/–
	Сообщение от Аноним (-), 04-Май-22, 18:02
	> Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей? Потому что это разные задачи. Разным задачам, разные решения. Ты не знал об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда.
	Ответить \| Правка \| К родителю #23 \| Наверх \| Cообщить модератору


	31. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от timur.davletshin (ok), 04-Май-22, 18:16
	> Потому что это разные задачи. Разным задачам, разные решения. Ты не знал > об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда. Господин, вы бредите. Когда-нибудь на досуге попробуй джиттер померять в userspace реализациях и в kernel. Гарантирую, ты прозреешь. Как ресэмплинг звука в userspace вынесли, так все начали ныть про кривой pulseaudio, хотя он просто старые алгоритмы вынес в пользовательское пространство. В сетевых протоколах есть абсолютно идентичный негативный эффект от подобного переноса и не важно, это VPN или CUBIC/Reno, реализованные поверх UDP.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	–1 +/–
	Сообщение от Аноним (-), 04-Май-22, 18:37
	Нет ты. Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи. Если ты говоришь, что они принципиально не отличаются по своим требованиям к реализации, то давай обосновывай нам, почему они принципиально не различаются. Давай-давай. Во-вторых, разработка чего-либо в ядре гораздо дороже. Строчка кода ядра обходится дороже, чем строчка кода юзерспейса. Поддержка этой строчки кода обходится резко дороже. Это ещё помножается на то, что ядерная разработка будет работать только с одним ядром, и если ты хочешь кроссплатформенности, то тебе придётся вести несколько разработок под разные ядра. OpenVPN тоже исходно разрабатывался в юзерспейсе, несмотря на весь этот твой бла-бла-бла про джиттер. Почему? Разработчики, что тупее тебя были? Нет, они как раз были умнее. Они знали, что разработка в ядре дорого, и поэтому нащупывать правильную архитектуру для реализации VPN, правильные структуры данных, правильные алгоритмы, структуру конфига, и всё остальное лучше в юзерспейсе. В юзерспейсе дешевле разрабатывать код, дешевле его мейнтейнить, дешевле дебажить, дешевле профайлить, ошибки (как архитектурные так и вида use-after-free) обходятся и исправляются дешевле, и поэтому в юзерспейсе было возможно разработать OpenVPN, в ядре практически невозможно. Вот теперь, когда накоплен опыт разработки VPN, опыт использования VPN, когда можно профайлить работу VPN со всех сторон, выясняя где и какие бутылочные горлышки возникают, вот теперь можно запилить и ядерную реализацию, причём сразу отливая её в граните так, чтобы потом не перелопачивать каждый год, когда очередная гениальная идея в голову пришла, или когда какое-нибудь важное наблюдение о строчке кода-источнике джиттера было сделано. Ты, как заурядный опеннетовец, вслепую ощупываешь слона и говоришь, что слон похож на столб. Глаза разуй и посмотри на проблему во всей её неповторимой сложности. Тогда ты, возможно, прекратишь бредить своими деревьями джиттеров, и начнёшь говорить дельные вещи о лесе в целом. QUIC -- это сырой протокол. Из которого хрен знает, что выйдет, и выйдет ли. Вероятно гугл применил кучу теории, для того, чтобы предсказать результат, но теория на то и теория, чтобы проверяться практикой. Только опеннетовец может ратовать за то, чтобы вбухивать сотни нефти в разработку этого QUIC прям сразу в ядре. Любой разумный человек будет разрабатывать его в юзерспейсе поверх стандартного для многих платформ API сокетов, внедрять на все платформы в юзерспейс, собирать данные с практического применения, и вот только после этого ставить вопрос: а не занести ли QUIC в ядро?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от timur.davletshin (ok), 04-Май-22, 19:42
	> Нет ты. > Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи. Если > ты говоришь, что они принципиально не отличаются по своим требованиям к > реализации, то давай обосновывай нам, почему они принципиально не различаются. Давай-давай. Читай внимательно, что я написал. Мне до твоего HTTPS дела нет, я писал про управление потоком в QUIC как пример корявости, т.к. данное действие является задачей близкой к realtime'у. А ведь именно уменьшение накладных расходов на операции подобного приоритета стали обоснованием для выноса протокола Wireguard в ядро. Будто до этого VPN'ов на уровне ядра не было...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	–1 +/–
	Сообщение от Онаним (?), 06-Май-22, 09:40
	Вирегад в ядро вытащен только по одной причине, по той же, по которой опенжпн свой ядерный модуль пилит. Если подавать данные для декодирования через юзерспейс - это лишняя смена контекста на каждый долбаный пакет. В случае клюка совершенно не актуально, потому что тот, кто его танцует, его и ужинает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от timur.davletshin (ok), 06-Май-22, 10:14
	> Вирегад в ядро вытащен только по одной причине, по той же, по > которой опенжпн свой ядерный модуль пилит. > Если подавать данные для декодирования через юзерспейс - это лишняя смена контекста > на каждый долбаный пакет. Т.е. QUIC в таком случае не должен существовать. Спасибо, что хоть на таком уровне со мной согласились.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 06-Май-22, 13:49
	Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе - пакеты приходят всё тому же адресату, который занимается и управлением потоком. В случае вирегада и прочих впн - пакеты идут через декодер, и снова уходят в ядро - следующему получателю. Разница ощутима?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	59. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от timur.davletshin (ok), 06-Май-22, 15:43
	> Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе - > пакеты приходят всё тому же адресату, который занимается и управлением потоком. А чё он тогда на 30% жручее до CPU? В чём профит тогда? В обновляемости congestion control'а? Так фуфло это. Гуглу одинаково легко обновить что bbr.ko, что код веб-сервера. А сторона клиента значения не имеет от слова вообще (если ты только не загружаешь что-то). Я уже не говорю про конкретные реализации QUIC с их конкретными глюками и затупами. Чего только в 2-5 раз более медленная загрузка на Firefox/QUIC стоит.
	Ответить \| Правка \| К родителю #58 \| Наверх \| Cообщить модератору


	60. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 06-Май-22, 17:06
	Жручее по сравнению с чем?
	Ответить \| Правка \| К родителю #59 \| Наверх \| Cообщить модератору


	62. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от timur.davletshin (ok), 06-Май-22, 18:56
	> Жручее по сравнению с чем? В сравнении с TCP.
	Ответить \| Правка \| К родителю #60 \| Наверх \| Cообщить модератору


	63. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 06-Май-22, 19:21
	Э, а ничего, что там SSL сверху? Тогда уж с HTTPS сравнивай.
	Ответить \| Правка \| К родителю #62 \| Наверх \| Cообщить модератору


	64. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от timur.davletshin (ok), 06-Май-22, 21:45
	> Э, а ничего, что там SSL сверху? > Тогда уж с HTTPS сравнивай. Сравнивали и не один раз: https://www.fastly.com/cimages/6pk8mg3yh2ee/495gZP7ZprKQUsEj... Если сравнивать BBR vs CUBIC, то первый сливает везде, кроме линий с большим дропом и большой задержкой.
	Ответить \| Правка \| К родителю #63 \| Наверх \| Cообщить модератору


	65. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 06-Май-22, 22:04
	Опять какое-то тёплое с мягким. Можно CPU usage при одинаковом throughput, а не сферических коней в вакууме? Впрочем я уверен, у QUIC он будет больше - разбирать подобие DTLS (мелкими блоками) - так себе затея. Другое дело, что он не для передачи гигабит в секунду, он больше для контроля latency на куче смузи-опилок, из которых современные говносайты построены.
	Ответить \| Правка \| К родителю #64 \| Наверх \| Cообщить модератору


	67. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от timur.davletshin (ok), 06-Май-22, 22:25
	> Можно CPU usage при одинаковом throughput, а не сферических коней в вакууме? Можно: https://conferences.sigcomm.org/sigcomm/2020/files/slides/ep... Советую почитать выводы. Протокол, который обещал при создании обновления алгоритма без вмешательства в систему, требует сетевое оборудование с GSO и нужно патчить реализацию UDP sendmsg для обеспечения более-менее сравнимой скорости. Я нахожу это ироничным. > Другое дело, что он не для передачи гигабит в секунду, он больше > для контроля latency на куче смузи-опилок, из которых современные говносайты построены. Посмотри обоснование для его создания.
	Ответить \| Правка \| К родителю #65 \| Наверх \| Cообщить модератору


	68. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 08-Май-22, 18:20
	> Можно: https://conferences.sigcomm.org/sigcomm/2020/files/slides/ep... Опять какие-то сферические гуглы в вакууме. Но даже если попытаться из этой ахинеи какие-то выводы сделать - то оно реально колышется где-то на уровне HTTPS ныне, плюс минус вечность в зависимости от имплементации.
	Ответить \| Правка \| К родителю #67 \| Наверх \| Cообщить модератору


	69. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 08-Май-22, 18:22
	Но кстати вот эта смузи-презенташка моё предположение подтвердила неожиданно, разбирать и слать DTLS - очень накладно. Но я вангую что с клюком нас ждёт огромная масса смешного секса, и в итоге оно будет о полутора землекопах. Не потому, что там с производительностью плохо. Я тут погуглил на тему интеропа имплементаций этого счастья, и мне поплохело.
	Ответить \| Правка \| К родителю #67 \| Наверх \| Cообщить модератору


	66. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 06-Май-22, 22:06
	К слову, в том, что кряк - говно, я не сомневаюсь ни разу. Но там дело не в том, что он не в ядре. Дело в попытке соплями и скотчем примотать L4 к L7.
	Ответить \| Правка \| К родителю #64 \| Наверх \| Cообщить модератору


	61. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 06-Май-22, 17:06
	И да, всё правильно. В обновляемости алкоритмов, написанных с бодуна под смузи.
	Ответить \| Правка \| К родителю #59 \| Наверх \| Cообщить модератору


	38. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от timur.davletshin (ok), 04-Май-22, 19:47
	> Почему? Разработчики, что тупее тебя были? Нет, они как раз были умнее. > QUIC -- это сырой протокол. Из которого хрен знает, что выйдет, и > выйдет ли. Вероятно гугл применил кучу теории, для того, чтобы предсказать > результат, но теория на то и теория, чтобы проверяться практикой. Разрабы Google, выходит, у тебя лохи печальные, а в Wireguard ну просто гении. Дружище, научись писать внутренне непротиворечивые тексты для начала. А там, может, и до деталей реализации RTP дойдём.
	Ответить \| Правка \| К родителю #34 \| Наверх \| Cообщить модератору


	24. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Аноним (7), 04-Май-22, 16:44
	Скажи это провайдерам.
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	28. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Мохнатый пись (?), 04-Май-22, 17:20
	Говорю каждый раз, пора бы уже ipv6 внедрять. Внедрение ipv6 во всём постсовсовке на уровне стран африки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 04-Май-22, 23:58
	Открою тебе секрет - и не только в постсовке. У нас есть полтора пользователя IPv6, Европа, причём западная. Они даже им вроде как пользуются. Но абсолютное и подавляющее большинство им не интересуется вообще. Не взлетело.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 05-Май-22, 00:00
	(нет, мы можем всем выдать по /64 автоматом, и даже пробовали на все серверы его развесить (не зашло, поубирали) - и после бодро отрапортоваться о 100% пенетрации, но клиентам от этого будет только хуже - жалобы на откровенно хреновую работу при попытке подобное делать были, есть, и будут есть)
	Ответить \| Правка \| К родителю #28 \| Наверх \| Cообщить модератору


	47. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+/–
	Сообщение от Онаним (?), 05-Май-22, 00:02
	А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA при резолве DNS сделать приоритетным. В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика иметь 80-120, а то и вообще ничего не иметь, и начинают жаловаться.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."	+1 +/–
	Сообщение от Мохнатый пись (?), 05-Май-22, 00:34
	> А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA > при резолве DNS сделать приоритетным. > В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика > иметь 80-120, а то и вообще ничего не иметь, и начинают > жаловаться. Кулстори какие-то. Сижу через туннель, ибо провайдер дебил, пинг из-за европейского сервера выше на 80мс до яндекса. И знаешь что? Различий вообще почти не вижу, может у вас такая реализация была классная? А чтобы колическо пользователей выросло, то надо свои роутеры через TR-69 настраивать и пользователям говорить, чтобы ipv6 включали, либо (что менее вероятно из-за кривых приложений с захардкоженным ipv4 адресом) сразу отрубать ipv4, выпускать только с ipv6 и NAT64. Так кстати некоторые новые провайдеры делают и мобильные операторы, ибо ipv4 уже на вес золота.
	Ответить \| Правка \| Наверх \| Cообщить модератору