Web-системы, в которых фронтэнд принимает соединения по HTTP/2 и передаёт бэкенду по HTTP/1.1, оказались подвержены новому варианту атаки "HTTP Request Smuggling", позволяющей через отправку специально оформленных клиентских запросов вклиниваться в содержимое запросов других пользователей, обрабатываемых в том же потоке между фронтэндом и бэкендом. Атака может быть использована для подстановки вредоносного JavaScript-кода в сеанс с легитимным сайтом, обхода систем ограничения доступа и перехвата параметров аутентификации...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55601
Ой, ну надо же, http взломали, как удивительно. (Нет.)
> Атака может быть использована для подстановки вредоносного JavaScript-кодаОй, ну надо же отключать JS.
Идея хорошая, но вебмакаки понаделали js-only крапа. И кстати это не поможет от приколов когда бэкэнд сливает вам ответ для совсем другого юзера, например. Так что кто-то может стырить кучу инфо о посторонних юзерах и их запросах. Судя по описанию - при удачном раскладе могут даже номера чужих кредиток или какие-нибудь секретные коды присылать на раз.p.s. LOL! LOL! LOL! LOL! TROLL! TROLL! TROLL! TROLL!
Исследователей с их рыготой самих в процессе поимели, как и пентестеров с этим нечто :)
We have updated Burp Suite's embedded browser to fix a clickjacking-based remote code execution bug in Burp Suite
интересно кто самый дырявый - си или js
прокладку не рассматриваешь?
а ник у тебя - просто "лэйбла" такая?
Скорее всего проблема в помойке node репо библиотек для JS и культуре коммерческой разработки.За что чмырят JS, это часто даёт похожее на сабж: дописали "клёвую" дублирующую функциональность не имея опыта и желания. Дубляж функциональности и разделение/трансформирование старого-нового - хороший и известный признак для поиска уязвимости.
А может быть проблема в том что не надо код писать ж@пой, качая половину интернета, от хрен знает кого, писаного хрен знает как? А еще неплохо бы использовать мозг при написании программ.Это касается вообще любого ЯП. И даже как видим не только яп. Упомянутая проблема на ЯП не завязана и возникает из-за гейтования протоколов. Свойства протоколов довольно разные, и на их стыке случается весьма интересное взаимодействие, когда первые понимают вторых не так как задумано. Это очень старый класс багов, не очень известный, но потенциально очень мощный по эффектам. Подобный класс багов позволяет обмануть системы на тему того с кем они имеют дело и левай Вася может быть на раз принят за админа, например.
Http на rust надо переписать очевидно же.
как же вы затрахали со своими шуточками, которые заходят через раз местному хомячью
Согласен, это уже похоже на шутеечки от Вася с 6 класса из школы интерната Подольского района где такие же... Ну вы поняли.
При чем тут шутеечки? Rust - современный язык программирования с безопасным управлением памятью, мультитаймингом, гиперинжинирингом и овертрейдингом. Скоро все на ruste перепишут, вот увидишь
Тебя бы тоже не мешало на Rust переписать
Уродство HTTP/2 таки выстрелило.
То ли ещё будет с HTTP/много, которые вообще не HTTP.
Так-то выстрелило уродство HTTP1, если почитать новость.
Выстрелило уродство трансляции полубинарного уродства SPDY в HTTP.
О да, лучше нормальный plain-text HTTP, от которого, правда, все отказались в пользу HTTPS, в котором из текста только вызов метода CONNECT.
Да-да-да, стройными колоннами побежали и отказались, никто не "стимулировал".
А кто стимулировал? Серваки заимплементившие фичу и повышение скорости загрузки сайтов? Вот уж зло вселенское.
> Серваки заимплементившие фичу и повышение скорости загрузки сайтов?Verisign, без вопросов отбирающий домены у оппозиционных СМИ.
Cloudflare, который немного навязчиво продвигает свои услуги (на предыдущей работе нам сначала прилетела DDoS-атака, а через пару дней - коммерческое предложение от этой милой компании).
> Verisign, без вопросов отбирающий домены у оппозиционных СМИ.Это как? И что этим СМИ мешает хостить сайты где-нибудь подальше от такой фирмы, особенно после зашквара? С соответствующим уроном кошельку оной, бонусом. Общая тупизна реднеков, если это про трампистов?
> Cloudflare, который немного навязчиво продвигает свои услуги
Клауд спайварь конечно та еще дрянь, но вот именно прийти с пистолетом и потребовать их юзать она не может.
> (на предыдущей работе нам сначала прилетела DDoS-атака,
> а через пару дней - коммерческое предложение от этой милой компании).Ну, если вы сколь-нибудь крупные и не умеете нанимать нормальных архитектов, кодеров и админов - мир жесток, да. А DDOS может даже школьник сэкономиший на завтраках закахать, и если у вас на этот счет совсем плана не было - у вас херовая инфраструктура, что для чего-то похожего на компанию гребаный стыд.
Внутри хытыпысы внезапно всё тот же гипертекстовый фидонет.
То есть, если внутри бинарного кода буквы, то он уже не бинарный? Ну тогда и HTTP/2 тоже небинарный (аки гендер у гражданина свободной страны).
Ты не понял.
SSL при обработке 1:1 разворачивается до исходного протокола, являясь только трансформацией.
То есть, если я в SNI напишу левое имя хоста, это никак не повлияет на работу HTTP?
Нет. Только на согласование соединения.
HTTP внутри декриптится до исходного в любом случае - БЕЗ изменений.
Получается, SNI на практике ни на что не влияет, а значит - вообще не нужен?
Вот это новость!
Сфейспалмил.
SNI к HTTP - ВНЕЗАПНО - не имеет никакого отношения :D
> Сфейспалмил.
> SNI к HTTP - ВНЕЗАПНО - не имеет никакого отношения :DВеб сервак может иметь свое мнение на этот счет. И кстати интересно, не вылезет ли там где-нибудь desync на тему того что поимело приоритет в фронте и бэке. Выглядит как еще одно необтоптаное поле для грабель.
>> Сфейспалмил.
>> SNI к HTTP - ВНЕЗАПНО - не имеет никакого отношения :D
> Веб сервак может иметь свое мнение на этот счет. И кстати интересно,
> не вылезет ли там где-нибудь desync на тему того что поимело
> приоритет в фронте и бэке. Выглядит как еще одно необтоптаное поле
> для грабель.Веб сервак обычно только правильный сертификат подбирает, смотря на SNI.
> SSL при обработке 1:1 разворачивается до исходного протокола, являясь только трансформацией.Не обязательно. См. пример на том сайте как это bitbucket делал, там могли бэку подшить еще сервисные хидеры с данными TLS, типа сертификата клиента и прочих "внутренних" вещей. Кроме того оно умеет всякие вещи типа ALPN. А heartbleed так то показал что оно умеет и много чего еще кроме "только трансформаций".
Подшивать к TLS можно чего угодно - проблемы ССЗБ шерифа не волнуют.
Важно то, что контент из TLS сдекриптится до исходного неизменного HTTP, SMTP или чего там у вас завёрнуто, т.е. исходный контент TLS не видоизменяет.
> Подшивать к TLS можно чего угодно - проблемы ССЗБ шерифа не волнуют.Однако вон те хаксоры вполне себе стырили внутренние хидеры и в конце концов тоже отымели.
> Важно то, что контент из TLS сдекриптится до исходного неизменного HTTP, SMTP
> или чего там у вас завёрнуто, т.е. исходный контент TLS не видоизменяет.Однако дополнительных свойств и параметров отрастает и то что к суммарной обработке этого сервером нельзя DESYNC применить - да в общем то не факт. Скажем с SNI можно наверное попытаться и посмотреть, где что приоритетнее. Например, Host: vs SNI наверное может быть использовано для unexpected реакции софта типа фронтов, прокси, ssl терминаторов и проч.
А вот из H2 H1 простой трансформацией уже не получить, что и есть источник проблемы - при преобразовании H2 в H1 "есть один нюанс".
Для преобразования HTTP/2 же в HTTP/1 по сути требуется полная реконструкция, простой трансформации нет - и как раз это и вызывает обсуждаемую проблему.
Именно. А разрабы попытались таки не делать нормально и попробовали частично 2 обратно превратить в 1.1Типа время экономят, что ли... Для скорости.
Ну да, казалось бы должна была быть просто трансформация, потому что "разработано с учётом мнения ведущих собаководов". А на деле разработано без обратной совместимости, и поэтому особенностей исходного протокола не учитывает совсем.
> plain-text HTTP, от которого, правда, все отказались в пользу HTTPSвсех отказали тогда уж.
не переживай, будет и 3-я, и 4-я волна.
это же удобно.
Это рукожопость разработчиков прокси ибо такие атаки очевидны и им сразу же нужно было уделять должное внимание.
Это рукожопость разработчиков бинарного протокола, которые решили, что те же CRLF в хедерах теперь новая нормальность. С фига бы.
(упреждая: угу, бинарному протоколу фиолетово. но забыли о сути HTTP - передача собственно текстовых сообщений, в которых переводы строк - неизбежное зло. за бинарным протоколом ещё серверы этих текстовых сообщений сидят, которым тот же CRLF внутри одного хедера тоже не особо спёрся)
Для эпичного ламо намекну: там упомянуты варианты этих атак работающие на чистом HTTP/1, который они не первый год практикуют. В случае HTTP/2 они просто попробовали по аналогии - и это прокатило, с превышением.
Если уж совсем просто - H2 не стоило называть HTTP/2, это не HTTP.
> Уродство HTTP/2 таки выстрелило.Вообще-то там текстовость HTTP/1.1 дурят жестко и это проблема HTTP1.
А если тот сайт еще и почитать, да еще используя мозги, можно узнать, что они там оказывается рядом атаковали и чистый HTTP/1.1 похожими методами, вообще без участия HTTP/2. Используя разное понимание фронтом и бэком длины запроса, например. Что в HTTP/1 сделано довольно дурно и дальше кому-то что-то совершенно левое в запрос врезается, потому что бэк уверен что все уже сжевал, а там какая-то добавка, которая может быть принята за новый запрос например, или префикс к нему.
Последнее позволяет пришить совершенно постороннему лоху какой-нибудь интересный редирект на свой сервак, а он какое-нибудь инфо утечет. Или скрипт ему подгрузить. Вариантов много.
H2 на бэках конкретно у нас упорно не приживается.
Основная причина - возможность в пределах одного коннекта открыть овердохера произвольных процессов/тредов в динамике, это всё приходится зажимами лимитировать, и честно говоря - проще вынести на фронт, вынеся все лимиты на стык, где потоки уже преобразованы в последовательные на H1.
> H2 на бэках конкретно у нас упорно не приживается.Жирные корпы тоже, вот, думали сэкономить. Некоторые даже конопатили эти CVE раза по 3, демонстрируя уровень компетентности своих вебмакак.
> Основная причина - возможность в пределах одного коннекта открыть овердохера произвольных
> процессов/тредов в динамике,Я правильно понимаю идею, что в кретинской архитектуре вашего бэка виноват HTTP/2? :) КМК, это барахло и при первом же ддосе скончается жесточайше, и вы пойдете клаудспайварь любить, или какую там еще "крышу" костылящую вашу ламерство.
Да, вы знаете, форкать по процессу и даже треду на запрос, и тем более без лимитов - не было сильно удачной идеей с самого начала. А pipelining позволяющий базовую версию того самого - вообще-то фича HTTP/1 еще. И вон те извращения с chunked они судя по всему с своих технологий атак HTTP/1 "бэкпортировали", или типа того.
> это всё приходится зажимами лимитировать, и честно говоря
> - проще вынести на фронт, вынеся все лимиты на стык, где
> потоки уже преобразованы в последовательные на H1.Когда у вас есть два неэквивалентных набора фич - вы таки нарываетесь на проблему. Я еще цать лет назад видел как разное понимание одного и того же может нагнуть - и это всегда было очень деструктивным видом проблем, позволяющим сильно нагнуть задуманую логику работы с массой веселых последствий.
Т.е. они одним сплошным потоком байтов слали подряд разные запросы а потом надеялись что смогут разбить их обратно на части?
Они похоже не читали статей где говорится о важности выбора разделителя и что самым надёжным будет разделять записи через набор символов !йух! .
они читали много статей где п-делось о страшных и ужастных ЗАДЕРЖКАХ при открытии tcp сессии (особенно в рамках одного и того же локалхоста).
И героически поебдили ненужную проблему.
так разве для HTTP 1.0 не открывается новое соединение на каждый запрос?или это особенность всякие reverse-proxy?
Открытие соединения по сравнению с ожиданием ответа от серверов - копеечная операция, на самом деле. Ну и 1.0 давно почит, в 1.1 в пределах одного соединения может быть несколько операций.
> Открытие соединения по сравнению с ожиданием ответа от серверов - копеечная операция,
> на самом деле. Ну и 1.0 давно почит, в 1.1 в
> пределах одного соединения может быть несколько операций.ну тогда либо прокси должен валидировать HTTP заголовки либо пусть форсит открытие нового соединения, странно что такие ребята типа nginx проморгали
Многие проморгали, потому что гугели свой SPDY в виде H2 запихивали в индустрию ломиком, не оставляя времени на масштабное тестирование. Следующая итерация неадекватизма под названием QUIC - на подходе, и её пытаются впихнуть ещё быстрее, чем H2. На деле же оба по сути не нужны, keepalive от 1.1 вполне достаточно. За спидами-кваками лежит только одно: желание сократить число открытых портов на фронтах у обленившихся.
Дело тут не в открытых сессиях (сессии надо и в QUIC отслеживать, то есть это не даёт экономии). Дело именно в задержках. И да, QUIC действительно позволяет сократить задержки. Особенно у всяких мобильных пользователей.
причем и то и другое копеечные операции по сравнению с ожиданием модного-современного gpu рендеринга и тонны скриптов.
Не, ну там основной идеей вмазывалось "мыжыможым статический коньтент подгрузить асинхронно пока сервер кушает". А второй коннект открыть в походе за статическим контентом - это уже всё, немодномолодёжно, обязательно надо ещё что-то внутри протокола херовертить.
> А второй коннект открытьЗАДЕРЖКИ!!!! ("уминядвепалоски!")
(то что они миллисекундные на фоне _секунд_ как минимум на собственно скачивание - смузижорам неведомо - у них внутри гугля везде уже 100G прямо до ноута обезьянки-разработчика)
> (то что они миллисекундные на фоне _секунд_ как минимум на собственно скачиваниеИ тем не менее, кпд канала может получиться довольно издевательским. Особенно если вон там еще 20 скриптов на разных CDN распихано. Надо же все хайповые либы прицепить, или где?
> - смузижорам неведомо - у них внутри гугля везде уже 100G
> прямо до ноута обезьянки-разработчика)Умничать о мобильном вебе с жирного проводного линка так то это эксперт уровня бох^W пох...
Самое же прекрасное, что у этих же почитателей смузи в итоге статический коньтент ныне размазан по десятку CDN'ов, и одним коннектом они так и так не обходятся.
и вот там уже задержки вполне видны, поскольку это новая tls сессия на каждый jquery.js с каждого особенного cdn
(хотя, разумеется, они ничто по сравнению с тем что начнется, когда оно его наконец-то скачает и запустит)
> Открытие соединения по сравнению с ожиданием ответа от серверов - копеечная операция,Не совсем. Ведет к выделению ресурсов на сокет в операционке, а закретие соединения далеко не мгновенное и при большом количестве запросов сокеты ожидающие закрытия могут основательно подвыжрать лимит числа файлов/сокетов, пригрузить conntrack, если он есть, etc.
> пределах одного соединения может быть несколько операций.
Да, там рядом клевые примеры что с chunked можно делать. И как можно фронты и бэки на-о-бывать. Даже без HTTP2 вообще, чего уж.
Ну я как бы в курсе, в практике и 1000 запросов в секунду на динамику - не предел.
Другое дело, что там, где начинается хайлоуд, это всё по уму горизонтально масштабируется, и не надо извращаться с мультиплексированием внутри простого как доска протокола.
> Другое дело, что там, где начинается хайлоуд, это всё по уму горизонтально
> масштабируется, и не надо извращаться с мультиплексированием внутри простого как доска
> протокола.Теоретически да. Практически - установка и завершение TCP все же не халявные, и это создает некий оверхед. Если мультиплексировать и не делать форк/старт треда на каждое это вот, оверхед заметно экономится. И если обратить внимание, изначально атака была на HTTP/1. И да, если делать как выше, прямая атака становится проблемой, однако если их статью посмотреть, в случае если фронт и бэк видят мир по разному, они все же придумали странные извращения с cache poisoning и проч. Разное видение мира разными компонентами - в любом случае остается проблемой, которую можно эксплуатировать газилионом странных способов.
А если фронт будет работать как вон то, это будет хтонически неэффективно и весьма атакуемо ддосами.
Про chunked пожалуй соглашусь, данное счастье требует некоторой аккуратности.
С другой стороны то, что с H2->H1 происходит, рядом с chunked не лежало и не ползало.
> Про chunked пожалуй соглашусь, данное счастье требует некоторой аккуратности.
> С другой стороны то, что с H2->H1 происходит, рядом с chunked не
> лежало и не ползало.Это судя по виду лишь усиленная и заапгрейженая версия атак которые они на HTTP/1 практиковали, используя разное видение мира фронтом и бэком и там.
Полное вымирание сайтов http - вопрос времени
> Полное вымирание сайтов http - вопрос времениОни как умные клавы решили смухлевать и прицепить HTTP/1 бэк малой кровью. При том на этом погорели весьма жирные конторы.
Слишком много букав!
Погодите, через недельку для специально для олдовых админов выйдет хайпово-клиповая версия на тиктоке.
Радует пока одно: у меня на фронтах немолодёжный haproxy, новый парсер которого по-человечески разбирает и перебирает запросы перед отдачей в бэкенды. В старом парсере до 2.0.6 были проблемы, ну так старый парсер для h2 в здравом уме юзать было сложно.
нет ножек (ненужно/2) - нет проблемы.P.S. обратить внимание на нашествие в комменты м-ков "экспертов" борцунов с http.
Я бы им вместо http sip с rtp посоветовал, но жалко бедняжек.
> P.S. обратить внимание на нашествие в комменты м-ков "экспертов"Фига, пох сам себя, затарил, не в бровь а в глаз.
Переходи на Traefik
Пасибо, я столько смузи в одно рыло не сожру.
тогда переходи на Envoy
Не, там думать надо.
Когда смузихлёбы добираются до C - у них выходит ещё хуже, чем если бы они на своих гошечках писали.Ну и вообще, какой смысл на что-то переходить, если haproxy отлично справляется со своей задачей? Модность и молодёжность? Всякие борингэсэсэли, люфты и прочее нечитаемое? См. выше - очень радует, что не модно, и не молодёжно.
> haproxy отлично справляется со своей задачейРазработчики haproxy с вами не согласятся, судя по тому, что они пилят dataplaneapi (попытка сделать аналог envoy из haproxy, обмазанного дендрофeкальными материалами).
Абсолютно угрёбищный конфиг умноженный на абсолютно угрёбищную документацию - да, это то, о чём я всю жизнь мечтал. По ним можно примерно предположить, что там внутри в архитектуре этого барбершопа.
Когда-нибудь вы уйдёте в High Load и в такой, где нужны submillisecond ответы от сервиса, и тут вы поймёте почему haproxy вам уже не хватает. И почему TCP вам не подходит by design.
Не жрите больше столько, умоляю. High Load - это не субмиллисекундные ответы, далеко нет.
И если у вас для нормальной работы сервиса требуются субмиллисекундные ответы - я бы уже посоветовал начать руковыпрямительную машинку собирать.
Но да, раз уж мы заговорили о хайлоудах - я прекрасно знаю как оно у смузихлёбов происходит.
Сначала плодятся модные микросервисы в докерах, и оно даже как-то работает в продакшне на хайлоуде внезапно. Стильно, модно, молодёжно.
По мере развития сервиса этих микросервисов становится over 9000, и вот тут выясняется, что нам теперь на один запрос надо их подёргать полсотни минимум, причём часто последовательно. А поскольку сеть при такой растопырке начинает роль играть, начинается вытьё про необходимость субмиллисекундных ответов, tcp не tcp, и прочий истероз. Это не хайлоуд, это лоумаржин, обильно сдобренный неумением видеть процессы далее одной сущности (особенно для снежинок характерно ныне).И нет понимания того, что юзеру без разницы, что у вас там в колхозе - ему важно, чтобы ему за его 100 мс ожидания, на которые он готов, ответ пришёл, а что вы там внутри дёргаете - сугубо фиолетово.
Рецепт в данном случае прост, но он покатит только в случае, если у вас не лоумаржин, а нормальное рентабельное. Смузихлёбам оставляется смузи (да и самих их остаётся половина), на критичные места берутся (дорогие) спецы, которые умеют вместо 100500 обмылков собрать полтора нормальных масштабируемых монолита, и их поддерживать. Ворочаться будет тоже не валко, но куда шустрее, чем подёргать сотню микрообмылков.
Всё это ещё дополнительно умножается на то, что ваш тезис про субмс работает только пока у вас георазнесения нет. Как только появляется георазнесение - забудьте про субмс, там от сервиса до сервиса будет десяток мс, и блокирующая синхронизация.
Короче, субмиллисекундные ответы оставьте жёсткому реалтайму и телеметрии - там да, это очень суровая тема, и действительно с tcp бывают проблемы. Но это не Web, и даже не около. А там, про что вы вещаете - проблема совершенно другого характера.
У микросервисов есть ряд очевидных плюсов. Как то декомпозиция задачи и перевод оной к некоторому количеству маленьких простых программ. В которых, в лучшем случае будет не так уж много багов. Сложность написания программы, видите ли, растет квадратично от ее размера. Поэтому и багов в большом монолите по идее будет больше, а поддерживать его будет хуже.Другое дело что хипстеры с жидким мозгом, как ни садитесь, а в программисты не годитесь.
Да, большой монолит сложнее поддерживать.
Но жесть в том, что менять рост сложности на не менее экспоненциальный рост требований к инфраструктуре получится только до определённого предела. А после и tcp не tcp, и всё остальное :)Баланс где-то посередине, а на старте проекта заметить потенциальную проблему с масштабируемостью по инфраструктуре тем самым хипстерам не просто очень сложно, а близко к импоссибл. Хуже всего то, что свернуться назад требует затрат многократных к изначальной балансировке в сторону группы монолитов.
> Да, большой монолит сложнее поддерживать.Он склонен превращаться в большое месиво. Которое к тому же скорее всего больше оверхеда на конкретно вон тот запрос.
> Но жесть в том, что менять рост сложности на не менее экспоненциальный
> рост требований к инфраструктуре получится только до определённого предела.Само по себе вон то - не обязывает повышать требования к инфраструктуре вроде. Откуда это следует? Другое дело что вебмакаки могут любую идею довести до маразма.
> А после и tcp не tcp, и всё остальное :)
У TCP есть свои long standing issues, а в мире с беспроводными линками он работает "не очень".
> по инфраструктуре тем самым хипстерам не просто очень сложно, а близко к импоссибл.
В этом месте некоторые начинают догадываться почему хорошие архитекты дороги и редки...
> Хуже всего то, что свернуться назад требует затрат многократных
> к изначальной балансировке в сторону группы монолитов.Факапы на уровне архитектуры никогда не были простыми и дешевыми. Но да, довольно многие узнают это сложным - и дорогим - способом, подорвавшись "что-нибудь накодить, а потом подумаем" :)
(короче я мыслью по древу растёкся, но основная мысль была в том, что овердекомпозиция - зло :D )
Для проектов уровня ~приветмир~ интернет-магазина "Васян сейлз" - да. Как говорится, "специализация - удел насекомых".А сложные проекты в сотни тысяч строк кода разбивать на модули можно и нужно, потому что одна команда со всем проектом банально не справится.
Можно сколько угодно ныть про "оверинжиниринг" и "овердекомпозицию", но лес удобнее валить бензопилами, запчасти к которым могут делаться на нескольких разных заводах в различных странах, чем каменным топором, который Ыых единолично соорудил за полчаса.
В конечном счете все эти речи, сдобренные словами "оверинжиниринг", "овердекомпозиция", а также "комбайн", "блоатварь", "блоб", "вендорлок" - воспринимаются абсолютно так же, как любой другой bullsh1t от манагера-продавана - "дайте мне вилку, у меня на ушах повисло много лишнего".
>Как то декомпозиция задачи и перевод оной к некоторому количеству маленьких простых программПрограмма перестаёт быть простой и маленькой ровно тогда, когда она становится сервисом или делает то, что можно было сделать через stdin/stdout по сети. Можно было нашлёпать простых процессов и не вымучивать из себя архитектуру, где простой фильтр становится сервером.
Не ясно, в чём разница со стороны логики приложения, сравнивая stdin/stdout между процессами и tcp между микро-серверами.Проблема в связности процессов и микро-с. и она совершенно отдельная от выбора stdin/stdout или tcp.
Разница как раз в той самой latency, с которой потом героически начинают бороться (перед этим создав себе этот самый героический геморрой).
До декомпозиции на микросервисы была декомпозиция на отдельные взаимодействующие процессы, как в Postfix, например. А до этого была декомпозиция на модули с явно объявленными интерфейсами, в обход которых нельзя ходить. Примеров в разных ЯП много своих, взять хотя бы Java и Modula. А до этого было примерно то же самое, но с динамическими библиотеками. А до этого то же самое, но со статическими библиотеками.Угадайте, что будет быстрее работать: микросервисы или статически собранные в монолитный исполняемый файл модули-библиотеки?
Угадайте, что будет проще поддерживать: тысячу микросервисов, каждый из которых может взаимодействовать с каждым по принципу графа, или тысячу статически собранных в монолит модулей, между которыми связи выстраиваются в дерево?
Угадайте, можно ли будет при необходимости вынести модуль из статически собарнного монолита в отдельный сетевой сервис?
Микросервисы - это механизм принуждения для тех, кто не способен вырабатывать и следовать политике. В хорошо сделанном монолите масштабируемости больше, чем в наугад сделанных микросервисах. Проблема в том, что делать монолит хорошо умеют "не только лишь все".
> Угадайте, что будет проще поддерживать: тысячу микросервисов, каждый из которых может взаимодействовать с каждым по принципу графа, или тысячу статически собранных в монолит модулей, между которыми связи выстраиваются в дерево?Сам вопрос уже некорректен, потому что из тысячи мелконедосервисов получится два десятка самостоятельых монолитов.
> Микросервисы - это механизм принуждения для тех, кто не способен вырабатывать и следовать политике.Микросервисы - это попытка хоть как-то разрулить поделки обезьянок-неосиляторов ("тех, кто не способен" видеть более одной сущности сразу в разрезе сервиса) до рабочего состояния.
>нормальных масштабируемых монолитаЭто надо внести в луддитско-свитеро-бородные анналы.
Монолиты разные бывают.
Можно каждые 2*2 в микросервис вытягивать.
А можно целый кусок логики, за свой _набор_ сущностей отвечающий, и взаимосвязи между ними.
Только это уже не микросервис будет, а монолит, который не вся правда система, а часть.
> Когда-нибудь вы уйдёте в High Load и в такой, где нужны submillisecond ответы от сервиса, и тут вы поймёте почему haproxy вам уже не хватает. И почему TCP вам не подходит by design.Вот только envoy тут не при чем. Он - в основном про возможность конфигурирования в runtime. Пожалуй, один из двух прокси-серверов, которые это реально умеют (второй - caddy).
Да и haproxy в рантайме нормально реконфигурится, если уж честно-то.
Кое-что можно через API, хосты вообще можно в динамике через DNS, а так там reload процессы в усмерть не блокирует даже под тысячами коннектов, разве что phaseout для удалённого бывает длинный.
> Да и haproxy в рантайме нормально реконфигурится, если уж честно-то.Нет. Достаточно переконфигурировать хотя бы несколько раз в секунду (вполне типичная ситуация в динамичных окружениях), чтобы "дорабатывающие" экземпляры основательно забили память.
> Кое-что можно через API
А нужно не кое-что, а полноценное изменение конфигурации.
> хосты вообще можно в динамике через DNS
Одна А-запись = один server - крайне уныло. Чтобы банально поменять количество бэкендов - нужно лезть в API, причем их количество ограничено заранее созданными слотами.
s/бэкендов/серверов в бэкенде/, конечно же.
> s/бэкендов/серверов в бэкенде/, конечно же.Количество слотов да, но вот это как раз дёргается через реконфиг, если ОЧЕНЬ надо (у вас точно количество нод каждую секунду растёт?).
А так SRV с 2019 года уже поддерживается.
> А нужно не кое-что, а полноценное изменение конфигурации.Раз в секунду.
Как правило если такое начало требоваться - самое время что-то в канцелярии подправить.
> Одна А-запись = один server - крайне уныло. Чтобы банально поменять количество
> бэкендов - нужно лезть в API, причем их количество ограничено заранее
> созданными слотами.А зачем это менять раз в секунду? Чтобы прострелить себе пятку, а потом продать всем вокруг пластырь от тупости?
> Абсолютно угрёбищный конфиг умноженный на абсолютно угрёбищную документациюМогли бы и не повторять, выше же написано
> Не, там думать надо.
Если что-то по своей сложности превосходит табуретку и не может быть осмыслено одной извилиной - всё, атас, "угребищность" и другие нехорошие слова.
В новости про атаки - примерно так. Чем сложнее и оверинженернутее нечто, тем больше там будет багов, включая и вулны. Грубо говоря, если вы везде и всюду будете летать исключительно на новой, клевой ракете - ваше прибытие, конечно, будет вызывать фурор. Но не долго. В силу сложности конструкции и малоизученности проблем ваша удача довольно быстро закончится. С другой стороны, сидение на табуретке не грозит развеянием праха в атмосфере...
Примерно да. Оверинжениринг и овердекомпозиция кажутся простыми на этапе первичной сборки, но выстреливают в ногу далее, на развитии и эксплуатации, зачастую потому, что особенности тьмы тьмущею сущностей целиком удержать даже документация уже не помогает. "Не помнишь - запиши. Записал. Забыл, где записал" :)
> Примерно да. Оверинжениринг и овердекомпозиция кажутся простыми на этапе первичной сборки,
> но выстреливают в ногу далее, на развитии и эксплуатации, зачастую потому,
> что особенности тьмы тьмущею сущностей целиком удержать даже документация уже не
> помогает. "Не помнишь - запиши. Записал. Забыл, где записал" :)Сам по себе HTTP/2 в этом плане кстати не такой уж оверинженернутый, хотя mandatory сжатие хидеров они наверное все же зря. А идея убрать special meaning у всяких закорючек и байтиков как раз таки сама по себе очень неплоха. Чистый HTTP/2 не получится левыми хидерами так по наглому кормить как HTTP/1 по жизни кормят, да и размер запроса юзеру сильно менее подконтролен. Другое дело, что красиво было на бумаге, но пришли чуваки с HTTP/1 бэками и вырыли себе овраг...
> С другой стороны, сидение на табуретке не грозит развеянием праха в атмосфере...Но эволюция, а впоследствии - и прогресс, почему-то упорно порождают все более усложнённые системы. Да, упрощённые тоже порождают, но далеко не все ниши ими закрываются.
Поэтому когда я вижу, когда носитель килограммового шмата нейронов ноет о переусложнённости - хочется посоветовать ему деградировать обратно до амёбы.
> Но эволюция, а впоследствии - и прогресс, почему-то упорно порождают все более
> усложнённые системы....состоящие из простых систем. Отказ каждой из которых в отдельности вообще похрен. У вас каждый день мрет куча клеток но вы вообще не замечаете это. Может ли похвастаться этим ваш бэк?
> Поэтому когда я вижу, когда носитель килограммового шмата нейронов ноет о переусложнённости
> - хочется посоветовать ему деградировать обратно до амёбы.Вы не правильно поняли эволюцию. Там случилось примерно то же что у хороших программистов. Каждая клетка сама по себе - не сильно сложнее амебы. Более того, глобальная архитектура с массовым параллельным процессингом и избыточностью так то сильно получше того что может большая часть вебмакак изобразить. А вот штуки типа гугла эти идеи неплохо прочухали так то...
Оно именно что не по сложности превосходит, а по угрёбищности.
То есть мнимая сложность, героически себе созданная, чтобы героически гордиться её преодолением.
> Оно именно что не по сложности превосходит, а по угрёбищности.Ну, для вас, похоже, 1+1 - норм, 2+2 - сложно, а 2+3 - угрёбищно.
А уж 5*6 вообще только смузихлёбы могут посчитать, нормальному человеку такое не понадобится, ибо "оверинжиниринг".
В случае смузихлёбов я бы поставил на скачивание лефтпада для 1+1 и 2+2, а в случае 5*6 - уже целый докер с микросервисом будет.
> В случае смузихлёбов я бы поставил на скачивание лефтпада для 1+1 и
> 2+2, а в случае 5*6 - уже целый докер с микросервисом будет.---
От учащихся старших школ (high schools, аналог наших старших классов средней школы) штата Орегон отныне не будут требовать, чтобы они демонстрировали в тесте перед выпуском определенный уровень навыков в чтении, письме и математике. А ежели кто попробует с такими нелепыми требованиями выступить, тот будет наказан по всей строгости закона.Достичь этого важного этапа в развитии народного образования местным энтузиастам удалось путём напряжённой и слаженной работы разных слоёв общества. Сначала прогрессивная общественная организация «Фонд за лучший Орегон» добилась того, что в сенат штата был внесён соответствующий законопроект, который — внимание! здесь цитата, в которой каждое слово драгоценно — «отражает те подлинные ценности, которые необходимы каждому учащемуся, чтобы добиться преуспевания в XXI веке». Ключевое слово здесь, разумеется — «подлинные». А ценности ложные — то есть бессмысленные умения читать, писать да считать, которые навязывались школьникам ретроградами из древнего века XX, а то как бы и не из XIX — не отражает.
--- http://a-nikolov.livejournal.com/531242.html (achtung, RT!)
Ссылка на производное ботофермы, которое маскируется под другого пользователя - это пять.
Уровень тот.
> тогда переходи на EnvoyОхренеть, плюсовики хайпуют. Явно покусаные гуглем - #include <stdbullshit> и даже, вау, тот укуреный гуглокрап как билдсистема.
> Радует пока одно: у меня на фронтах немолодёжный haproxy, новый парсер которого по-человечески разбирает и перебирает запросы перед отдачей в бэкенды.Поздравляю вас с этим, и рекомендую немедленно обновиться
https://git.haproxy.org/?p=haproxy-2.4.git;a=commit;h=9e0c2b...
https://git.haproxy.org/?p=haproxy-2.4.git;a=commit;h=6c6b9a...
https://git.haproxy.org/?p=haproxy-2.4.git;a=commit;h=b4934f...
https://git.haproxy.org/?p=haproxy-2.4.git;a=commit;h=e9f1f1...
У меня за фронтом такой же не менее немолодёжный H1, поэтому меня эти пляски с угрёбищным H2 тоже не затронули :)Кроме https://git.haproxy.org/?p=haproxy-2.4.git;a=commit;h=e9f1f1...
Но в данном случае на стороне серверов строгая валидация, поэтому пох.
Тем более что рутинное обновление haproxy делается буднично, и да, скоро обновлюсь, спасибо :)
Хотя конечно да, есть определённый мысли вообще убрать ALPN h2 с фронтов, ибо нефиг.
// определённый позыв / определённые мысли
Оверинженеринг в действии
Это как раз недоинженеринг, т.е. когда осилили работу с простым протоколом HTTP/2 и не осилили бинарно более сложный HTTP/1.x
> Это как раз недоинженеринг, т.е. когда осилили работу с простым протоколом HTTP/2
> и не осилили бинарно более сложный HTTP/1.xHTTP/1 вообще более сложен в проверках и sanity check. В том числе и из-за специальной трактовки символов, что ведет к рискам срыва парсинга.
> Оверинженеринг в действииБольше похоже на идиотизм: тащить части старого протокола в новый протокол. Нарушили инкапсуляцию и огребли. О чём олды даааавно уже понимали.
> Больше похоже на идиотизм: тащить части старого протокола в новый протокол. Нарушили
> инкапсуляцию и огребли. О чём олды даааавно уже понимали.Они настолько понимали, что по#%ывали даже и чистый HTTP/1.1 используя разное его понимание на границе между фронтом и бэком :P
> на границе между фронтом и бэкомМежду фронтом и бэком и на ф. и на б. как раз не было знавших и понимавших, или их задавил лидер разработки.
Есть вещи, которые не стоит даже затевать. Но многие непробовали сами результата и соблазняются.
> Между фронтом и бэком и на ф. и на б. как раз
> не было знавших и понимавших, или их задавил лидер разработки.Более вероятно что...
1) Это были 2 тотально разные команды, плохо или никак взаимодействующие между собой.
2) В HTTP/1 есть несколько мест которые можно сделать по разному и довольно много мест где можно лохануться в парсинге. HTTP/2 в этом несколько лучше, кстати. Но если его в HTTP/1 перегнать, проблемных мест становится даже больше.
3) Архитект мог быть лох, а безопасТник возможно умел только кошмарить хомячков во имя луны. Вон там красавы, с 3-4 попыток зачинить не смогли местами. То-есть они сами вообще толком не поняли проблему и закостылили конкретное проявление. За что получили еще 3-4 успешных эксплойтирования, обходом конкретной затычки.
Ну так нгингс подвержен или нет? Где исправления?
Если я правильно прочитал changelog к 1.21.1, то это как раз оно:
http://nginx.org/en/CHANGES
Немного смущает, что эта версия вышла месяц назад (впрочем, CVE-2021-21295 вообще от марта, так что известно об этой уязвимости давно)
Тут просто написано «NGINX is not affected by this security exposure», без указания конкретных версий:
https://support.f5.com/csp/article/K97045220
Проверил на Nginx 1.20 (не включающем правки от 6 июля): заголовок Transfer-Encoding на сервер, указанный в proxy_pass, не отправляется вообще (до nginx доходит, а дальше - не уходит), Content-Length устанавливается в нужное значение, исходя из реального объёма переданных данных. Попытки вклинить перенос на новую строку внутри заголовка приводят к закрытию соединения. Попытки дважды использовать Content-Length - к ошибке 400. Получается, добавленные в 1.21.1 исправления - это ради перестраховки.
чем генерировали запросы? curl'ом у меня не всё получается
На скорую руку отредактировал бинарник курла и libcurl-4.dll, заменив там первую букву во всех вхождениях строки Transfer-Encoding, дабы этот заголовок в нём не имел специального значения и отправлялся на сервер, как и остальные пользовательские заголовки. На придумывание чего-то хитрого не стал тратить время, но через Wireshark убедился, что нужные заголовки в запросах к nginx на месте, а от nginx уже нет (curl запускал с переменной окружения SSLKEYLOGFILE).
Ммм... хакир! :) Т.е. HTTP/2 стал внаглую рассылать Transfer-Encoding как HTTP/2 хидер? Мсье эстет, мне это нравится. Пойду тоже что-нить пропатчу, только, пожалуй, в сорце :]
Теперь все будут топить за "закопать" http и перейти на websocket?
WebSocket работает поверх HTTP
Не волйнутесь, сейчас Гугл быстренько придумает HTTP3...ой, нет, наверное уже HTTP4.
Хуавей уже замену TCP/IP придумал. Этакий зомбоящик получается.
мертворожденная шляпа
это тебе, живущему в свободной стране, так кажется.
а в Китае взлетит.
Ну так там цели иные, нежели связность и удобство.
А в условиях адекватных целей не взлетит.
> Хуавей уже замену TCP/IP придумал. Этакий зомбоящик получается.Так же как они "заменили" Андроид?
Такими темпами скоро перейдут на 6-недельные релизы, синхронно с Хромом. Циферки будут меняться как в одометре.
Вообще-то у них уже 4-недельный цикл
KeepAlive Off на бэкенде спасет отца русской демократии :)
Да, Жа спасет, можешь спать спокойно =)
HTTP2 нинужно
javascript макак как обычно взламывают даже без использования уязвимостей неправильной работы с памятью.
Несомненно у них ошибка в днк
А тут, внезапно, не в js макаках проблема.
Ну, если бы они осилили http2.createServer, то последствий их рукоблудия перечисленные уязвимости не коснулись бы.
Как раз в них. Фронт и бэк - две группы разработки, работающие в тесном сотрудничестве. Родили вместе.Various people believe in JavaScript crypto, unfortunately. This small
example helps them fuel their poor taste.https://github.com/WireGuard/wireguard-tools/blob/3ac679e7a1...
Везде чмырят...
> Как раз в них.Эта проблема может возникнуть даже в проектах никак не использующих JS, и вообще, достаточно концептуальна.
Root cause - разное видение мира разными частями системы, ЯП в формулу факапа вообще не входит. Я вообще видел это в совсем других протоколах и ЯП, но оно тоже жгло напалмом по примерно тем же failure modes. Это довольно мощный - и довольно недооцененный - класс багов.
> Various people believe in JavaScript crypto, unfortunately.
Я даже согласен, но это все же вообще совсем полностью другой класс проблем. Хотя если свести все проблемы к "програмер/архитект идиот", тогда будет что-то общее конечно. Но это довольно упрощенная картина мира.
>Root cause - разное видение мира разными частями системыА то, что видение мира у JS-смузихлёбов отбито по самое не балуй, тебя не смущает?
> А то, что видение мира у JS-смузихлёбов отбито по самое не балуй,
> тебя не смущает?Так оно же не только у них отбито. Вон какие-нибудь питонисты или даже хрустики с их серебряными пулями из слегка приукрашеного материала.
вебня такая вебня
Надо было на расте писать.
В соседнюю ветку загляни, там в твоём расте дыреней наделали мама не горюй.
> Надо было на расте писать.Точняк, надо запилить что-нибудь с этой уязвимостью и на хрусте. Нужно больше CVE, милорд!
Это называется не "уязвимость", а "заставили обезьян веб проектировать"!
Бэкенду вообще никаким боком не нужен HTTP! Связать фронт и бэк можно сотней РАЗНЫХ способов, где запросы разных клиентов вообще не пересекаются.
Есть ещё кстати fastcgi. Можно было бы использовать его.
К разработчикам SPDY, из которого произошёл HTTP/2 первое предложение относится на 100%. В той конторе вменяемость запрещается проносить на территорию.
Мамкины "иксперты" даже не поняли о чем идет речь в статье, говорят за JS, Rust :D
Подумали, что под фронтом имеют ввиду JS, а не прокси-сервер на бэке с проблемой общения между протоколами, а-а-а-а-ахахах.
А почему бы просто не общаться с бэкендами по http/2? Ведь это бинарный протокол, а значит парсинг и сериализация в него идёт эффективнее. Заодно и встроенные в парсер проверки всех размеров внутри сообщения.
Если в HTTP/2 указана длина, зачем допускается Content-Length? Даже если это не прокси, а просто сервер, ему на какое значение ориентироваться?