Для тех кто хочет заселфхостить себе парольный менеджер есть ещё более крутой вариант: Vaultwarden - альтернативная, более легковесная, простая, понятная и минималистичная реализация сервера Bitwarden, на Rust
Очень крутое исследование, одна из самых увлекательных статей которую довелось причитать за последнее время. Спасибо! Правда, есть немного горькое послевкусие от прочтения:
Ребята провели просто невероятную работу, усердно трудились в течение многих месяцев, провели сложнейшую эксплуатацию уязвимостей сразу на трёх уровнях: доверенно загруженной ОС, потом процессоре обработки сигналов и наконец в ТЕЕ, а сама по себе криптография оказалась пшиком, причём как в варианте "для чужих" - с криптографией ослабленной до уровня взламываемого на калькуляторе, так и "для своих" - с полноценной длинной ключа, т.к. компания, которая её разработала, как и многие другие до неё, решила что она умнее остальных, и нарушила "нулевое правило Шнайера" - стала выдумывать свою криптографию, когда всё что ей нужно было сделать - просто взять и использовать доступные открытые технологии.
Инженеры с другой стороны, в свою очередь, потратили огромное количество своего времени не на то, чтобы создать качественный продукт - безопасную зашифрованную связь, а на то, чтобы огородить свою прошивку от аудита независимых исследователей, чтобы люди не могли узнать как именно она работает и обложить компании производители оборудования юридическими и лицензионными ограничениями. Если бы клиентам до покупки можно было бы сразу ознакомиться с тем, что именно представляет из себя эта "military grade" (c) криптография (по классике жанра именно такая фраза должна фигурировать в описании продукта) или если бы была возможность сразу независимо её проаудировать, то, разумеется, желающих приобрести подобные поделки было бы значительно меньше.
В сухом остатке: никто не получил пользы, никто не стал счастливее. Люди во всём мире много лет пользуются небезопасной связью, огромное количество сил талантливых людей потрачено на совершение работы без полезного результата, продукт, вероятно, придётся переделывать на нормальную открытую криптографию, которой можно было бы просто воспользоваться с самого начала, а оборудование, вероятно, либо сложно и больно обновлять/перепрошивать, либо выпускать новое. Грустно это.
Именно это апи - да, оно требует обязательного взаимодействия с гугл сервисами. Если приложение их не использует и скачано из рустора, то остаётся либо смириться и разрешить приложению полный доступ к СМС, либо вводить код из СМС самостоятельно. Лично я всегда предпочту второе. Главное, чтобы владельцы приложений которые теперь распространяются через рустор не навязывали первое
Если вы говорите про "dangerous" пермишены, которые требуют подтверждения разрешения на доступ у пользователя в рантайме, и в которые входит доступ к СМС, то да - просто так доступ к данным не получить, необходимо чтобы пользователь лично разрешил это. Если вы явно запретите доступ к СМС, то приложение их не получит.
Однако проблема с этими пермишенами в том, что, во-первых, они, как и многие другие вещи в андроиде, работают по принципу "всё или ничего" - либо мы не выдаём доступ вообще ни к чему, либо выдаём, но ко всему и сразу, без разграничения на то что приложению реально нужно, а что нет, а, во-вторых, политики гугла поддерживали хоть сколько-то этичное их использование. Например, согласно им, пользователь всегда должен иметь возможность отказаться предоставлять контакты/СМС/какие-то другие данные и приложение должно сохранить свой функционал. Переход в рустор, понятное дело, снимает подобные "пережитки прошлого", можно просто затребовать доступ к данным на входе в приложение и заблокировать работу приложения, если данные предоставлены не будут. Разумеется, скорее всего, на такое пойдут немногие, индустрия мобильных приложений уже много лет как переросла широкое использование подобного неэтичного абуза, и пользователи от него отвыкли, но технически, насколько я понимаю, в русторе это возможно, так что то ли ещё будет.
Кстати, QUERY_ALL_PACKAGES в "dangerous" группу не входит, приложение сразу будет иметь доступ к информации о всём установленном ПО без каких-то разрешений от пользователя.
С уходом из гугл плея в рустор многие российские приложения, например банки, с удовольствием добавили себе в манифест пермишены, с которыми гугл им никогда бы не дал опубликоваться в официальном сторе, например "QUERY_ALL_PACKAGES", чтобы следить за тем какие приложения установлены на устройстве пользователя. Эта информация может быть реально необходима приложению примерно никогда, в 99% случаев она нужна различным SDK которые собирают информацию о пользователе, телеметрию, профили для аналитики, статистики, и т.д. и ничего полезного для самого пользователя не делают. Гугл не разрешает публиковать приложения с этим пермишеном в официальном гугл сторе, но вот, сразу же после выхода первой же версии приложения в русторе, от приложений российских банков в сеть полетели данные об установленных приложениях.
Абсолютно та же история с чтением СМС. Гугл, в принципе, даёт право публиковать подобные приложения в сторе, но проверяет их в ручном режиме и смотрит действительно ли им необходим доступ к всем СМС, если нет - разворачивает. Разумеется, никаким банкам никакой доступ к СМС не может быть нужен в принципе. "Нам нужны ОТР-коды из СМС" - не оправдание. Для этого, во-первых, есть специальное апи, которое позволяет получить код из СМС и при этом не даёт доступа к содержанию всех остальных сообщений, а во-вторых, ничего не случится если пользователю потребуется лишние 3 секунды, чтобы посмотреть пришедшее СМС самостоятельно. Стоит ли и говорить что перейдя в рустор банки сразу же себе эти пермишены добавили, и теперь они имеют полный доступ к всем вашим СМС и могут делать с ними всё что хотят - читать, анализировать, удалять, отправлять, и т.д.
Спасибо за интересную статью! Как сторонник селфхостинга ресурсов под свои нужды - горячо одобряю, особенно с учётом подорожания стоимости аренды серверов.
В комментариях уже многие высказались за использование VPNа на VPS сервере с белым адресом вместо ssh-туннеля, и я, пожалуй, тоже присоединюсь к этому. Я достаточно много пользовался ssh-туннелями, и пользуюсь ими до сих пор для доступа к каким-то приватным ресурсам, веб-мордам админок и т.д. - всего того что не должно торчать в сеть ни при каких обстоятельствах, но с ssh-туннелями также имел крайне негативный опыт с обрывами соединения и их стабильностью. Самый неприятный момент в том, что соединение может оборваться, а вот процесс ssh отвечающий за поддержание туннеля не завершится, и приходится самостоятельно руками его прибивать и стартовать новый. Да, autossh вроде как решает проблему, но сам по себе является костылём, использования которого хотелось бы избежать.
Небольшой оффтоп. У меня получилось достичь приемлемой, почти полностью беспроблемной стабильности ssh-туннелей с помощью добавления TCP-keepalive. Это генерирует небольшой постоянный трафик, но в нынешние времена это не должно быть проблемой. Для включения keepalive необходимо в конфигурацию подключения на стороне клиента, которая описывается в файле ~/.ssh/config внести соответствующие параметры. У меня типичная конфигурация подключения выглядит примерно так:
Host SSH_ALIAS
HostName 123.45.67.89
User user
Port 12345
IdentityFile ~/.ssh/id_ed25519_key_for_certain_server
IdentitiesOnly yes
TCPKeepAlive yes
ServerAliveInterval 15
ServerAliveCountMax 4
StrictHostKeyChecking yes
Также обязательно на стороне сервера в конфигурацию openssh в файле /etc/ssh/sshd_config добавить:
TCPKeepAlive yes
Не уверен что это будет работать с минималистичными реализациями вроде dropbear, но на полноценных компьютерах почти все пользуются openssh, так что думаю что проблем не возникнет.
Выскажу свои аргументы за схему с VPN на VPSке вместо туннелей:
Хорошо настроенный wireguard, с правильно выставленными значениями MTU на стороне клиента и сервера позволяет прокачивать трафик от VPS почти без потери скорости и всё буквально ограничится пропускной способностью вашего домашнего интернета. В своё время я экспериментировал с синхронизацией большого количества данных через rsync over ssh, и там у меня скорость резалась очень серьёзно. С wireguard таких проблем вообще не встретил. Допускаю что это мои руки не из плеч.
Если не обязательно использовать 80 и 443 порты, то можно полностью избежать использования nginx, и, соответственно, лишнего расхода ресурсов совсем сделав на стороне VPS порт форвардинг прямо на iptables. Трафик будет заворачиваться получателю в нужный tun-интерфейс напрямую правилами фаервола. Обрывы не страшны, т.к. даже если клиент отвалился, он переподключится, на VPS ничего специально делать не нужно, следить за восстановлением маршрутов тоже. Если у вас только один сервер за VPS и нет необходимости ничего крутить на ней самой, то можно и 80 и 443 порты полностью завернуть на ваш домашний сервер, и уже на нём, на стороне nginx, раскидывать подключения через mod_stream, ssl_preload по виртуалкам или контейнерам. Таким образом у вас будут и все ваши ресурсы, хоть их будет несколько десятков, на официальном 443 порту, и на все можно получить бесплатные сертификаты от letsencrypt или zerossl. При этом нагрузка на VPS и её ответственность будут абсолютно минимальны: прокидывать туда-сюда трафик и быть "лицом с белым адресом".
С ssh-туннелями всё это тоже сделать можно, но получается чуть больше потенциальных проблем, необходимости контроля и нагрузки на обе стороны
Ого, круто! Огромное спасибо за проделанную работу и интересную статью. Я видимо застрял где-то в прошлом, в котором собственные мобильные сети на SDR можно было развернуть только в виде 2G, а тут уже LTE полностью работает.
Кстати, а нельзя ли на операторской стороне создать для абонентов eSIM, если клиентский телефон их поддерживает?
Справедливо. Тогда был действительно период, когда для цензоров шифрование SNI, закрывающее один из самых удобных способов быстро и дёшево ограничить нужные соединения, было относительно в новинку и не носило массовый характер. Сегодня разумеется этот вопрос стоит более остро, цензоры тоже немного разобрались с тем как там оно технически устроено, помню какой-то сумрачный гений из госдумы даже предлагал полностью запретить и блокировать TLS 1.3.
Я имел ввиду то, что в те времена, когда eSNI отлично работал, а цензоры ещё за этот вопрос не взялись, Mozilla вдруг крайне неожиданно взяла и просто убрала его из браузера, хотя никакой технической необходимости в этом как будто бы не было. Я не сторонник конспирологии, но тогда это выглядело так, что их очень попросили это сделать
Помню, пользовался пару лет назад Firefox-ом c eSNI, в сочетании с dns-over-https это позволяло без VPN-ов посещать большинство заблокированных ресурсов (те что сами поддерживали TLS 1.3 и хостились за CDN). А потом в какой-то день Mozilla вдруг объявили что убирают поддержку eSNI из браузера и разом её выпилили, сказав что "это был не стандарт, а драфт, и вообще случайный эксперимент, и на замену ему сейчас придёт полноценный ECH". Но вот только несколько лет уже прошло, ECH так полноценно и не работает, а вот eSNI наоборот - реально работал, ещё несколько лет назад и реально решал проблему цензуры. Выводы, как говорится, делайте сами
Вероятно потому, что пока в Русторе не поддерживается разделение на сплиты. Приложения в Гугл Плей принимаются от разработчиков в формате app-bundle, а на устройство пользователя доставляются apk собранные конкретно под его устройство, т.е. имеющие ресурсы и код только под нужные архитектуру ЦПУ, плотность пикселей экрана, локализацию и т.д. Соответсвенно, без поддержки этих возможностей стор вынужден доставлять полный "толстый" апк, а те же нативные библиотеки под неиспользуемые архитектуры могут запросто весить несколько десятков мегабайт
Интереснейшая статья, настоящее техническое творчество. Спасибо!
Кстати, о проекте OpenIPC узнал не так давно и с огромным уважением отношусь к этой инициативе. Надеюсь однажды она разрастётся и станет чем-то вроде OpenWrt в мире WiFi-роутеров
Как человек участвовавший в проектировании и разработке карточных систем для общественного транспорта, я перевидал, перечитал документацию, прошивал и попробовал дюжину разных видов карт и никак не могу пройти мимо этой статьи.
Во-первых, как верно указали в комментариях, речь идёт об уязвимости почти 15-летней давности. Казалось бы, можно было сказать, что сейчас это уже никакого отношения к реальности не имеет, но нет. Подобные системы карт, так же как и карты в СКУДах, к сожалению, нередко завязываются на конкретное оборудование и экосистему, от которой потом крайне сложно отказаться и крайне болезненно уходить. Задачу свою она выполняет, а штучные "ломатели карт", как правило, не являются слишком большой проблемой, вот и тянутся эти проблемы из десятилетия в десятилетие, а во многих системах в ходу карты 15, 20, а то и 30 летней давности.
Корни этой проблемы тянутся из прошлого. К пониманию необходимости защиты карт, и отказа от использования принципа "security by obscurity" человечество пришло далеко не сразу, а карт и оборудования для них уже навыпускали. Компании спешили поскорее выкатить продукт на рынок, а не задумываться о том что в будущем у каждого студента будет в кармане проксмарк/флиппер/телефон с NFC который сможет взаимодействовать с их оборудованием, поэтому защиту в карты даже не закладывали.
Возьмите, например, те же СКУДы, где до сих пор массово используют emmarine карты, они вообще не предполагают никакой защиты и копируются в один тык на китайские болванки за пару десятков рублей. Плохо ли это с точки зрения безопасности? Однозначно! Такие системы используются в бизнес центрах, предприятиях, офисах компаний, и т.д. Но, как часто бывает, карта не является единственным фактором аутентификации, поэтому бизнес и государсто продолжают закрывать глаза на проблему и митигируют её сторонними способами. Например в московском транспорте отлично работает антифрод система, которая почти моментально заблокирует использование и оригинальной карты и дубликата. Ну а копировать карты с магнитной полосой - это вообще избиение младенцев. Разумеется данные на них никак не защищены.
Во-вторых, существуют современные карты, которые уже давно не болеют подобными детскими болезнями. Протокол общения с ними предполагает принудительную двухстороннюю аутентификацию, использование признаваемой надёжной во всём мире криптографии, шифрование и подпись каждого отправляемого apdu, причём расчёт криптограмм используемых в процессе, делегируется отдельным аппаратным модулям безопасности, так что никто, включая злоумышленника получившего контроль над клиентским оборудованием, или даже оборудованием оператора транспортной системы, или даже непосредственно самих турникетов не может получить доступа к ключам карты и несанкционированно записать туда что-то. Пока что с подобными картами существует проблема - несмотря на то что они уже очень много лет существуют на рынке, они мало распространены, хотя по себестоимости зачастую выходят даже дешевле карт тридцатилетней давности с нулевой защитой. Виной всему та же огромная "инертность" технологий в этой сфере, но их время обязательно придёт.
Также, поскольку я много работал с картами NXP mifare, могу сказать что проблема с crypto1 уже также давно решена. Этот алгоритм был своеобразной пробой пера среди массово используемых карт в плане аутентификации включающей в себя криптографию, выработки сессии и дальнейшее шифрование всех передаваемых данных. Да, реализован он был слабо, особенно в плане оборудования карты. Напомню, что внутри карты находится маленький компьютер размером с четверть рисового зёрнышка, и заставить его выполнять вычислительно "тяжёлые" криптографические операции - это далеко не то же самое что делать подобное на полноценном компьютере. Инженеры экономили ресурсы как могли и просчитались не столько на самой криптографии, сколько на невозможности организовать на подобных мощностях криптографически стойкий аппаратных ГПСЧ (это куда сложнее чем кажется на первый взгляд). Тем не менее, спустя некоторое время они выпустили новый тип карт, который после прошивки можно было перевести в режим работы, который полностью повторял интерфейс оригинальных mifare classic, но при этом уже имел стойкий ГПСЧ без вышеупомянутой уязвимости и дополнительные плюшки типа защиты от фаззинга команд и брутфорса ключа. Так что теперь даже эти карты возможно использовать относительно безопасно, хотя в современных реалиях они обладают уже пожалуй слишком короткой длинной ключа, и если вы прямо сейчас разрабатываете современную систему использующую карты, то лучше возьмите хотя бы mifare plus ev1 от тех же NXP, используйте их в максимально защищённом режиме и всё будет хорошо и правильно.
Ну а от гениев использующих открытый 7-байтный UID карты в качестве идентификатора любая безопасность бессильна, т.к. этот UID вообще-то нужен для чисто технических задач типа разрешения коллизии карт и т.д. и вообще может возвращаться случайный в некоторых случаях. Это НЕ прикладные данные и полагаться на них нельзя
Очень давно пользуюсь yt-dlp. Заготовил даже для себя разные шелл-алиасы чтобы быстро скачивать музыку или целые плейлисты с аудио и видео, которые, к сожалению, копирасты нередко с ютуба удаляют. Музыку вообще стараюсь всегда держать только у себя локально и никаких подписок, потому что с ними те же проблемы «недуступно у вас в регионе», «удалено по жалобе правообладателя» и т.д. В личном хранилище всё организовано так как мне нужно и по чьей-то прихоти удалено не будет.
К сожалению, тему с зарезанием скорости замечаю уже некоторое время, последнее время кажется она особенно активна. Пока что разработчики yt-dlp справляются. Низкий им поклон от меня
Интересуюсь тем, что происходит в Китае и довольно давно наблюдаю за тем как Китайские компании потихоньку захватили чуть ли не 90% мировой добычи редкоземельных металлов, которые в будущем, при сохранении текущих темпов роста производства сложных технологических товаров, могут стать дороже золота. Да и вообще Китай контролирует токую огромную долю критически важных мировых ресурсов в производстве, цепочках поставок, логистике, и не только. Всегда удивляло то, что люди по всему миру не бьют тревогу на этот счёт.
Телеметрия Майкрософта таки дошла до необходимости делать добровольно-принудительные полные бэкапы данных пользователей на анализ? Впрочем, учитывая то что они у себя на onedrive даже пытаются подбирать пароли к архивам и анализировать их содержимое - неудивительно
Спасибо огромное за статьи! Очень полезная и актуальная тема.
UPD: Кстати, было бы интересно если бы вы также смогли дать краткое описание и пример настройки функционала xray bridge для тех кому нужен функционал реверс прокси и прокидывания доступа из внешней сети к домашней
Автор молодец! Очень круто, что уже в таком возрасте есть чёткое понимание того к чему хочется стремиться и куда развиваться. Я бы очень хотел быть таким же в свои 16. Если программирование - ваше призвание, то продолжайте, не останавливайтесь, и ни в коем случае не сомневайтесь в своём выборе, кто бы что вам ни говорил. Вашему отцу - уважение, за то что развивает и поддерживает вас в ваших начинаниях.
Как-то мне довелось плотно пообщаться с талантливыми молодыми ребятами на летней стажировке в Яндексе. Я конечно был поражён их уровнем знаний. В свои 18, только закончив школу, многие из них, по уровню навыков и квалификации, были на голову выше некоторых разработчиков с многолетним опытом, которых мне доводилось знать. Их пример, как и ваш, очень заряжают и вдохновляют.
Спасибо за интересную статью. Тема крайне актуальная и важная для крупных проектов. Тоже пытался по разному подступиться к этой проблеме на рабочем проекте (550+ gradle модулей, 2М+ LOC), делал оптимизацию сборки, дружащие с местным DI стабы -impl модулей (разбиение на -api, -impl, -stub), но взрывного эффекта, это, конечно, всё равно не давало.
По моему опыту работы с Gradle, он очень плохо переносит большое количество модулей, каждый новый модуль добавляет существенный импакт на время сборки, даже если это просто -stub модуль с "пустыми" реализациями интерфейсов из -api, количество модулей, к сожалению не меняется, время конфигурации (существенное узкое место, особенно актуальное в "горячих" сборках) не уменьшается, configuration-cache не всегда адекватно работает из-за некоторых подключённых к сборке плагинов, а выигрыш на тасках сборки модуля есть, но не огромный.
Наиболее правильный подход - это конечно вот такие вот демо, к которым можно подключить только 1-2 разрабатываемых в настоящий момент модуля и не страдать с пересборкой всего проекта. Я, к сожалению, не осилил у себя декомпозировать сильно старые базовые модули, авторизацию и проход до главного экрана, которые в своё время были очень монолитными и завязанными друг на друга, а потом стало слишком больно и сложно их рефакторить.
Для тех кто хочет заселфхостить себе парольный менеджер есть ещё более крутой вариант: Vaultwarden - альтернативная, более легковесная, простая, понятная и минималистичная реализация сервера Bitwarden, на Rust
Очень крутое исследование, одна из самых увлекательных статей которую довелось причитать за последнее время. Спасибо! Правда, есть немного горькое послевкусие от прочтения:
Ребята провели просто невероятную работу, усердно трудились в течение многих месяцев, провели сложнейшую эксплуатацию уязвимостей сразу на трёх уровнях: доверенно загруженной ОС, потом процессоре обработки сигналов и наконец в ТЕЕ, а сама по себе криптография оказалась пшиком, причём как в варианте "для чужих" - с криптографией ослабленной до уровня взламываемого на калькуляторе, так и "для своих" - с полноценной длинной ключа, т.к. компания, которая её разработала, как и многие другие до неё, решила что она умнее остальных, и нарушила "нулевое правило Шнайера" - стала выдумывать свою криптографию, когда всё что ей нужно было сделать - просто взять и использовать доступные открытые технологии.
Инженеры с другой стороны, в свою очередь, потратили огромное количество своего времени не на то, чтобы создать качественный продукт - безопасную зашифрованную связь, а на то, чтобы огородить свою прошивку от аудита независимых исследователей, чтобы люди не могли узнать как именно она работает и обложить компании производители оборудования юридическими и лицензионными ограничениями. Если бы клиентам до покупки можно было бы сразу ознакомиться с тем, что именно представляет из себя эта "military grade" (c) криптография (по классике жанра именно такая фраза должна фигурировать в описании продукта) или если бы была возможность сразу независимо её проаудировать, то, разумеется, желающих приобрести подобные поделки было бы значительно меньше.
В сухом остатке: никто не получил пользы, никто не стал счастливее. Люди во всём мире много лет пользуются небезопасной связью, огромное количество сил талантливых людей потрачено на совершение работы без полезного результата, продукт, вероятно, придётся переделывать на нормальную открытую криптографию, которой можно было бы просто воспользоваться с самого начала, а оборудование, вероятно, либо сложно и больно обновлять/перепрошивать, либо выпускать новое. Грустно это.
Именно это апи - да, оно требует обязательного взаимодействия с гугл сервисами. Если приложение их не использует и скачано из рустора, то остаётся либо смириться и разрешить приложению полный доступ к СМС, либо вводить код из СМС самостоятельно. Лично я всегда предпочту второе. Главное, чтобы владельцы приложений которые теперь распространяются через рустор не навязывали первое
Если вы говорите про "dangerous" пермишены, которые требуют подтверждения разрешения на доступ у пользователя в рантайме, и в которые входит доступ к СМС, то да - просто так доступ к данным не получить, необходимо чтобы пользователь лично разрешил это. Если вы явно запретите доступ к СМС, то приложение их не получит.
Однако проблема с этими пермишенами в том, что, во-первых, они, как и многие другие вещи в андроиде, работают по принципу "всё или ничего" - либо мы не выдаём доступ вообще ни к чему, либо выдаём, но ко всему и сразу, без разграничения на то что приложению реально нужно, а что нет, а, во-вторых, политики гугла поддерживали хоть сколько-то этичное их использование. Например, согласно им, пользователь всегда должен иметь возможность отказаться предоставлять контакты/СМС/какие-то другие данные и приложение должно сохранить свой функционал. Переход в рустор, понятное дело, снимает подобные "пережитки прошлого", можно просто затребовать доступ к данным на входе в приложение и заблокировать работу приложения, если данные предоставлены не будут. Разумеется, скорее всего, на такое пойдут немногие, индустрия мобильных приложений уже много лет как переросла широкое использование подобного неэтичного абуза, и пользователи от него отвыкли, но технически, насколько я понимаю, в русторе это возможно, так что то ли ещё будет.
Кстати, QUERY_ALL_PACKAGES в "dangerous" группу не входит, приложение сразу будет иметь доступ к информации о всём установленном ПО без каких-то разрешений от пользователя.
С уходом из гугл плея в рустор многие российские приложения, например банки, с удовольствием добавили себе в манифест пермишены, с которыми гугл им никогда бы не дал опубликоваться в официальном сторе, например "QUERY_ALL_PACKAGES", чтобы следить за тем какие приложения установлены на устройстве пользователя. Эта информация может быть реально необходима приложению примерно никогда, в 99% случаев она нужна различным SDK которые собирают информацию о пользователе, телеметрию, профили для аналитики, статистики, и т.д. и ничего полезного для самого пользователя не делают. Гугл не разрешает публиковать приложения с этим пермишеном в официальном гугл сторе, но вот, сразу же после выхода первой же версии приложения в русторе, от приложений российских банков в сеть полетели данные об установленных приложениях.
Абсолютно та же история с чтением СМС. Гугл, в принципе, даёт право публиковать подобные приложения в сторе, но проверяет их в ручном режиме и смотрит действительно ли им необходим доступ к всем СМС, если нет - разворачивает. Разумеется, никаким банкам никакой доступ к СМС не может быть нужен в принципе. "Нам нужны ОТР-коды из СМС" - не оправдание. Для этого, во-первых, есть специальное апи, которое позволяет получить код из СМС и при этом не даёт доступа к содержанию всех остальных сообщений, а во-вторых, ничего не случится если пользователю потребуется лишние 3 секунды, чтобы посмотреть пришедшее СМС самостоятельно. Стоит ли и говорить что перейдя в рустор банки сразу же себе эти пермишены добавили, и теперь они имеют полный доступ к всем вашим СМС и могут делать с ними всё что хотят - читать, анализировать, удалять, отправлять, и т.д.
Спасибо за интересную статью! Как сторонник селфхостинга ресурсов под свои нужды - горячо одобряю, особенно с учётом подорожания стоимости аренды серверов.
В комментариях уже многие высказались за использование VPNа на VPS сервере с белым адресом вместо ssh-туннеля, и я, пожалуй, тоже присоединюсь к этому. Я достаточно много пользовался ssh-туннелями, и пользуюсь ими до сих пор для доступа к каким-то приватным ресурсам, веб-мордам админок и т.д. - всего того что не должно торчать в сеть ни при каких обстоятельствах, но с ssh-туннелями также имел крайне негативный опыт с обрывами соединения и их стабильностью. Самый неприятный момент в том, что соединение может оборваться, а вот процесс ssh отвечающий за поддержание туннеля не завершится, и приходится самостоятельно руками его прибивать и стартовать новый. Да, autossh вроде как решает проблему, но сам по себе является костылём, использования которого хотелось бы избежать.
Небольшой оффтоп. У меня получилось достичь приемлемой, почти полностью беспроблемной стабильности ssh-туннелей с помощью добавления TCP-keepalive. Это генерирует небольшой постоянный трафик, но в нынешние времена это не должно быть проблемой. Для включения keepalive необходимо в конфигурацию подключения на стороне клиента, которая описывается в файле ~/.ssh/config внести соответствующие параметры. У меня типичная конфигурация подключения выглядит примерно так:
Также обязательно на стороне сервера в конфигурацию openssh в файле /etc/ssh/sshd_config добавить:
Не уверен что это будет работать с минималистичными реализациями вроде dropbear, но на полноценных компьютерах почти все пользуются openssh, так что думаю что проблем не возникнет.
Выскажу свои аргументы за схему с VPN на VPSке вместо туннелей:
Хорошо настроенный wireguard, с правильно выставленными значениями MTU на стороне клиента и сервера позволяет прокачивать трафик от VPS почти без потери скорости и всё буквально ограничится пропускной способностью вашего домашнего интернета. В своё время я экспериментировал с синхронизацией большого количества данных через rsync over ssh, и там у меня скорость резалась очень серьёзно. С wireguard таких проблем вообще не встретил. Допускаю что это мои руки не из плеч.
Если не обязательно использовать 80 и 443 порты, то можно полностью избежать использования nginx, и, соответственно, лишнего расхода ресурсов совсем сделав на стороне VPS порт форвардинг прямо на iptables. Трафик будет заворачиваться получателю в нужный tun-интерфейс напрямую правилами фаервола. Обрывы не страшны, т.к. даже если клиент отвалился, он переподключится, на VPS ничего специально делать не нужно, следить за восстановлением маршрутов тоже. Если у вас только один сервер за VPS и нет необходимости ничего крутить на ней самой, то можно и 80 и 443 порты полностью завернуть на ваш домашний сервер, и уже на нём, на стороне nginx, раскидывать подключения через mod_stream, ssl_preload по виртуалкам или контейнерам. Таким образом у вас будут и все ваши ресурсы, хоть их будет несколько десятков, на официальном 443 порту, и на все можно получить бесплатные сертификаты от letsencrypt или zerossl. При этом нагрузка на VPS и её ответственность будут абсолютно минимальны: прокидывать туда-сюда трафик и быть "лицом с белым адресом".
С ssh-туннелями всё это тоже сделать можно, но получается чуть больше потенциальных проблем, необходимости контроля и нагрузки на обе стороны
Ого, круто! Огромное спасибо за проделанную работу и интересную статью. Я видимо застрял где-то в прошлом, в котором собственные мобильные сети на SDR можно было развернуть только в виде 2G, а тут уже LTE полностью работает.
Кстати, а нельзя ли на операторской стороне создать для абонентов eSIM, если клиентский телефон их поддерживает?
Справедливо. Тогда был действительно период, когда для цензоров шифрование SNI, закрывающее один из самых удобных способов быстро и дёшево ограничить нужные соединения, было относительно в новинку и не носило массовый характер. Сегодня разумеется этот вопрос стоит более остро, цензоры тоже немного разобрались с тем как там оно технически устроено, помню какой-то сумрачный гений из госдумы даже предлагал полностью запретить и блокировать TLS 1.3.
Я имел ввиду то, что в те времена, когда eSNI отлично работал, а цензоры ещё за этот вопрос не взялись, Mozilla вдруг крайне неожиданно взяла и просто убрала его из браузера, хотя никакой технической необходимости в этом как будто бы не было. Я не сторонник конспирологии, но тогда это выглядело так, что их очень попросили это сделать
Помню, пользовался пару лет назад Firefox-ом c eSNI, в сочетании с dns-over-https это позволяло без VPN-ов посещать большинство заблокированных ресурсов (те что сами поддерживали TLS 1.3 и хостились за CDN). А потом в какой-то день Mozilla вдруг объявили что убирают поддержку eSNI из браузера и разом её выпилили, сказав что "это был не стандарт, а драфт, и вообще случайный эксперимент, и на замену ему сейчас придёт полноценный ECH". Но вот только несколько лет уже прошло, ECH так полноценно и не работает, а вот eSNI наоборот - реально работал, ещё несколько лет назад и реально решал проблему цензуры. Выводы, как говорится, делайте сами
Ничего себе! Вот это чтиво! Люблю подобные низкоуровневые штуки. В них - настоящая красота программирования. Автору - огромное уважение
Вероятно потому, что пока в Русторе не поддерживается разделение на сплиты. Приложения в Гугл Плей принимаются от разработчиков в формате app-bundle, а на устройство пользователя доставляются apk собранные конкретно под его устройство, т.е. имеющие ресурсы и код только под нужные архитектуру ЦПУ, плотность пикселей экрана, локализацию и т.д. Соответсвенно, без поддержки этих возможностей стор вынужден доставлять полный "толстый" апк, а те же нативные библиотеки под неиспользуемые архитектуры могут запросто весить несколько десятков мегабайт
Интереснейшая статья, настоящее техническое творчество. Спасибо!
Кстати, о проекте OpenIPC узнал не так давно и с огромным уважением отношусь к этой инициативе. Надеюсь однажды она разрастётся и станет чем-то вроде OpenWrt в мире WiFi-роутеров
Как человек участвовавший в проектировании и разработке карточных систем для общественного транспорта, я перевидал, перечитал документацию, прошивал и попробовал дюжину разных видов карт и никак не могу пройти мимо этой статьи.
Во-первых, как верно указали в комментариях, речь идёт об уязвимости почти 15-летней давности. Казалось бы, можно было сказать, что сейчас это уже никакого отношения к реальности не имеет, но нет. Подобные системы карт, так же как и карты в СКУДах, к сожалению, нередко завязываются на конкретное оборудование и экосистему, от которой потом крайне сложно отказаться и крайне болезненно уходить. Задачу свою она выполняет, а штучные "ломатели карт", как правило, не являются слишком большой проблемой, вот и тянутся эти проблемы из десятилетия в десятилетие, а во многих системах в ходу карты 15, 20, а то и 30 летней давности.
Корни этой проблемы тянутся из прошлого. К пониманию необходимости защиты карт, и отказа от использования принципа "security by obscurity" человечество пришло далеко не сразу, а карт и оборудования для них уже навыпускали. Компании спешили поскорее выкатить продукт на рынок, а не задумываться о том что в будущем у каждого студента будет в кармане проксмарк/флиппер/телефон с NFC который сможет взаимодействовать с их оборудованием, поэтому защиту в карты даже не закладывали.
Возьмите, например, те же СКУДы, где до сих пор массово используют emmarine карты, они вообще не предполагают никакой защиты и копируются в один тык на китайские болванки за пару десятков рублей. Плохо ли это с точки зрения безопасности? Однозначно! Такие системы используются в бизнес центрах, предприятиях, офисах компаний, и т.д. Но, как часто бывает, карта не является единственным фактором аутентификации, поэтому бизнес и государсто продолжают закрывать глаза на проблему и митигируют её сторонними способами. Например в московском транспорте отлично работает антифрод система, которая почти моментально заблокирует использование и оригинальной карты и дубликата. Ну а копировать карты с магнитной полосой - это вообще избиение младенцев. Разумеется данные на них никак не защищены.
Во-вторых, существуют современные карты, которые уже давно не болеют подобными детскими болезнями. Протокол общения с ними предполагает принудительную двухстороннюю аутентификацию, использование признаваемой надёжной во всём мире криптографии, шифрование и подпись каждого отправляемого apdu, причём расчёт криптограмм используемых в процессе, делегируется отдельным аппаратным модулям безопасности, так что никто, включая злоумышленника получившего контроль над клиентским оборудованием, или даже оборудованием оператора транспортной системы, или даже непосредственно самих турникетов не может получить доступа к ключам карты и несанкционированно записать туда что-то. Пока что с подобными картами существует проблема - несмотря на то что они уже очень много лет существуют на рынке, они мало распространены, хотя по себестоимости зачастую выходят даже дешевле карт тридцатилетней давности с нулевой защитой. Виной всему та же огромная "инертность" технологий в этой сфере, но их время обязательно придёт.
Также, поскольку я много работал с картами NXP mifare, могу сказать что проблема с crypto1 уже также давно решена. Этот алгоритм был своеобразной пробой пера среди массово используемых карт в плане аутентификации включающей в себя криптографию, выработки сессии и дальнейшее шифрование всех передаваемых данных. Да, реализован он был слабо, особенно в плане оборудования карты. Напомню, что внутри карты находится маленький компьютер размером с четверть рисового зёрнышка, и заставить его выполнять вычислительно "тяжёлые" криптографические операции - это далеко не то же самое что делать подобное на полноценном компьютере. Инженеры экономили ресурсы как могли и просчитались не столько на самой криптографии, сколько на невозможности организовать на подобных мощностях криптографически стойкий аппаратных ГПСЧ (это куда сложнее чем кажется на первый взгляд). Тем не менее, спустя некоторое время они выпустили новый тип карт, который после прошивки можно было перевести в режим работы, который полностью повторял интерфейс оригинальных mifare classic, но при этом уже имел стойкий ГПСЧ без вышеупомянутой уязвимости и дополнительные плюшки типа защиты от фаззинга команд и брутфорса ключа. Так что теперь даже эти карты возможно использовать относительно безопасно, хотя в современных реалиях они обладают уже пожалуй слишком короткой длинной ключа, и если вы прямо сейчас разрабатываете современную систему использующую карты, то лучше возьмите хотя бы mifare plus ev1 от тех же NXP, используйте их в максимально защищённом режиме и всё будет хорошо и правильно.
Ну а от гениев использующих открытый 7-байтный UID карты в качестве идентификатора любая безопасность бессильна, т.к. этот UID вообще-то нужен для чисто технических задач типа разрешения коллизии карт и т.д. и вообще может возвращаться случайный в некоторых случаях. Это НЕ прикладные данные и полагаться на них нельзя
Очень давно пользуюсь yt-dlp. Заготовил даже для себя разные шелл-алиасы чтобы быстро скачивать музыку или целые плейлисты с аудио и видео, которые, к сожалению, копирасты нередко с ютуба удаляют. Музыку вообще стараюсь всегда держать только у себя локально и никаких подписок, потому что с ними те же проблемы «недуступно у вас в регионе», «удалено по жалобе правообладателя» и т.д. В личном хранилище всё организовано так как мне нужно и по чьей-то прихоти удалено не будет.
К сожалению, тему с зарезанием скорости замечаю уже некоторое время, последнее время кажется она особенно активна. Пока что разработчики yt-dlp справляются. Низкий им поклон от меня
Интересуюсь тем, что происходит в Китае и довольно давно наблюдаю за тем как Китайские компании потихоньку захватили чуть ли не 90% мировой добычи редкоземельных металлов, которые в будущем, при сохранении текущих темпов роста производства сложных технологических товаров, могут стать дороже золота. Да и вообще Китай контролирует токую огромную долю критически важных мировых ресурсов в производстве, цепочках поставок, логистике, и не только. Всегда удивляло то, что люди по всему миру не бьют тревогу на этот счёт.
Кажется, скоро до широких масс начнёт доходить
Телеметрия Майкрософта таки дошла до необходимости делать добровольно-принудительные полные бэкапы данных пользователей на анализ? Впрочем, учитывая то что они у себя на onedrive даже пытаются подбирать пароли к архивам и анализировать их содержимое - неудивительно
Спасибо огромное за статьи! Очень полезная и актуальная тема.
UPD: Кстати, было бы интересно если бы вы также смогли дать краткое описание и пример настройки функционала xray bridge для тех кому нужен функционал реверс прокси и прокидывания доступа из внешней сети к домашней
Очень круто! Спасибо за статью
Автор молодец! Очень круто, что уже в таком возрасте есть чёткое понимание того к чему хочется стремиться и куда развиваться. Я бы очень хотел быть таким же в свои 16. Если программирование - ваше призвание, то продолжайте, не останавливайтесь, и ни в коем случае не сомневайтесь в своём выборе, кто бы что вам ни говорил. Вашему отцу - уважение, за то что развивает и поддерживает вас в ваших начинаниях.
Как-то мне довелось плотно пообщаться с талантливыми молодыми ребятами на летней стажировке в Яндексе. Я конечно был поражён их уровнем знаний. В свои 18, только закончив школу, многие из них, по уровню навыков и квалификации, были на голову выше некоторых разработчиков с многолетним опытом, которых мне доводилось знать. Их пример, как и ваш, очень заряжают и вдохновляют.
Успехов!
Спасибо за интересную статью. Тема крайне актуальная и важная для крупных проектов. Тоже пытался по разному подступиться к этой проблеме на рабочем проекте (550+ gradle модулей, 2М+ LOC), делал оптимизацию сборки, дружащие с местным DI стабы -impl модулей (разбиение на -api, -impl, -stub), но взрывного эффекта, это, конечно, всё равно не давало.
По моему опыту работы с Gradle, он очень плохо переносит большое количество модулей, каждый новый модуль добавляет существенный импакт на время сборки, даже если это просто -stub модуль с "пустыми" реализациями интерфейсов из -api, количество модулей, к сожалению не меняется, время конфигурации (существенное узкое место, особенно актуальное в "горячих" сборках) не уменьшается, configuration-cache не всегда адекватно работает из-за некоторых подключённых к сборке плагинов, а выигрыш на тасках сборки модуля есть, но не огромный.
Наиболее правильный подход - это конечно вот такие вот демо, к которым можно подключить только 1-2 разрабатываемых в настоящий момент модуля и не страдать с пересборкой всего проекта. Я, к сожалению, не осилил у себя декомпозировать сильно старые базовые модули, авторизацию и проход до главного экрана, которые в своё время были очень монолитными и завязанными друг на друга, а потом стало слишком больно и сложно их рефакторить.
Спасибо ещё раз!