Однажды при аудите безопасности в хипе приложения нашли пароль пользователя:)

Товарищи, из меня плохой гуглер. Подскажите, пожалуйста, годный RPC.
Требования очень простые:
— на базе UDP (чтоб быстро по мобильным сетям), но с гарантией доставки и последовательности
— адаптивная избыточность (Соломон-Рид, например)
— шифрование, проверка подлинности (AES-GCM, например)

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

Так а зачем UDP, если с гарантией доставки и последовательности?)

Основная проблема TCP на мобильных сетях, да и, на самом деле, на любых сетях, которые работают по радио и теряют пакеты из-за помех в процессе своей нормальной работы — это то, что большинство используемых алгоритмов congestion control воспринимают потери пакетов как сигнал о том, что канал забит и надо снизить скорость. В итоге получаем, что на том же EDGE оно выглядит как "интернета нет совсем".

Гугл попробовал решить эту проблему с помощью TCP BBR, который предполагается накатывать на сервер, и который на потери пакетов смотрит не особо, зато смотрит на увеличение RTT при увеличении количества отправляемых пакетов в единицу времени. Использует его, например, ютуб для отдачи видео. Ещё я себе на сервер поставил недавно)

А этот TCP BBR есть для Windows серверов? Блиц гугление что-то не дало ответа.
И реально лучше становится если это использовать? На картиках вроде все красиво выглядит.

Не, нету, но он встроен в современные ядра линукса в выключенном по умолчанию состоянии. Собственно, я так его себе на сервер и добыл, поставил последнее ядро и дописал две строчки в /etc/sysctl.conf

Печалька

Печалька — это использовать винду на сервере :D

Но, видимо, есть какие-то причины

🤷‍♂️

скорее всего легаси

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

TCP очень тупой. Если линк с большой задержкой, то для заполнения канала нужно выставлять очень большое окно (что на дефолтных значениях не происходит вовсе), а механизм гарантии доставки такой, что если из 1000 пакетов окна был не достален только второй, то 999 пакетов начиная со второго будут доставлены повторно.
Более того, для заполнения тонких длинных каналов механизмы управления доставкой должны быть не дефолтными не только со стороны сервера, но и со стороны клиента...

В Security Bulletin Google была опубликована уязвимость CVE-2017-13176
Суть ее в том, что для url вида "http://a:a@example.com:a@example2.com/path" неверно возвращается хост

Uri uri = Uri.parse("http://a:a@example.com:a@example2.com/path");
String host  = uri.getHost();

host  будет равен example.com вместо example2.com

Уязвмости присвоили high уровень

Вопрос сообществу: Может есть идеи,  какие могут быть сценарии атак и как это смогут использовать малварные приложения?

делаешь вредоносный сайт доступным по урлу example.com, а сайт, удовлетворяющий всем нормам, делаешь доступным по урлу example2.com. В итоге подсовываешь всем андроид-девайсам на вид хороший сайт, а девайсы идут на другой. В суде говоришь, что ты не виноват в этом. Профит

в описании идет речь о поднятии привилегий

Хмм, а как понимать урл с двумя двоеточиями?

Два порта!

А, хотя нет, это урл с логином и паролем

А, юзернейм:пароль@хост:порт