Справедливо :) Я видел что mac mini, особенно достаточно старых серий, можно взять за очень доступную цену на том же авито, но, думаю, во-первых, отчасти, мне просто хотелось поэкспериментировать с хакинтошем, а, во-вторых, я держал в уме то, что такой мини-компик всегда можно перенастроить и использовать как обычную домашнюю машину общего назначения.
Думаю что имелось ввиду "на схожем по производительности железе", и ещё на х86. Процы Apple M, конечно, по производительности обгонят большинство сопоставимых x86
Круто что предложение по аренде серверов на macos существует. Штука экзотическая, крайне редко необходимая, и существующая, по моему мнению, исключительно благодаря закрытости Apple и нежеланию делать нормальную кросскомпиляцию под свою платформу, но вот когда она внезапно оказывается нужна, хорошее решение найти очень непросто. Ну и цены на подобные решения, особенно в условиях дефицита как спроса, так и предложения, заставляют хвататься за сердце.
Лично я для себя решил что аренда macos серверов - это слишком большая роскошь. Была у меня некоторое время назад необходимость организовать специфическую, работающую только в macos сборку. По итогу, настроил для себя сервер на хакинтоше. Купил под это дело мини-пк (типа beelink и ему подобных), взял по скидке на распродаже 11.11 на алиэкспрессе за ~300 долларов. По характеристикам: Ryzen 7 5700U, 32GB RAM, 1TB SSD. Райзены 5000-6000 поддерживаются проектом opencore, идентификаторы генерируются и зашиваются нормально, все остальные железки макосью тоже подхватились без проблем.
Да, по производительности такой велосипед однозначно уступает М2, тем более учитывая процессор U-серии, но с другой стороны, это же не какая-то на порядок отстающая по железу сборка: полноценных 8 ядер / 16 потоков, памяти - много, да и от macos людям обычно нужна не сверхпроизводительность, а просто возможность работать с инструментами которые Apple огораживает в своей системе - запускать компиляцию в xcode, и т.д. Пускай работать он будет в пару раз медленнее, зато чисто само железо стоит, как минимум, в 5 раз дешевле, а уж по сравнению с арендой выгода становится совсем очевидна. Кажется, что покупка отбивается за 1-2 месяца аренды аналогичной конфигурации, из-за чего покупка своего, вместо аренды у кого-то, становится выгодна даже для краткосрочной пробы, не говоря уже о долгосрочном использовании.
Пожалуй, главный и единственный минус подобного подхода в том, что при необходимости сделать большое обновление, например на новую мажорную версию macos что-нибудь может поломаться, но я пока, к счастью, в своём проекте ни с какими проблемами не сталкивался, и свои задачи этот мини-компик выполняет на все 100, надеюсь что так оно и продолжит работать. Я несколько опасался возможных проблем и перед его покупкой почитал интернеты на предмет того, каких можно ожидать подвохов при работе на хакинтоше. Оказалось, что есть люди которые полноценно и стабильно работают на таких системах, например занимаются ios разработкой. Иронично то, что, по их утверждениям, xcode на хакинтошах работает даже лучше и быстрее чем на оригинальном железе от Apple
Я знаю что Хабр - не жалобная книга, но история с биометрией - это реально очень важно и, думаю, что высказаться по данному вопросу - тоже важно. Тем более, мне есть что сказать.
В комментариях я заметил, что кто-то интересуется "в чём вообще проблема с ЕБС?". Я несколько лет назад, в 2017-2018 годах, плотно работал с движком распознавания лиц, компанию разработчика которого в итоге выкупило государство, и вероятно, если и не полностью, то частично в ЕБС используются наработки того движка с которым работал я. Пару лет назад, стоя в очереди в банке, я увидел как оператор снимала у клиента лицо на камеру, и просила выполнить некоторые действия, в которых я узнал характерные liveless проверки (проверки на то что в кадре живой человек, а не фото или видео), которые видел в API того движка, так что лично я уверен что это именно он, и похоже что с тех пор он не сильно изменился.
Я думаю, что сделав предположение о том что ЕБС нужен исключительно государству для слежки и контроля за гражданами я на 90% попаду в точку. Выслеживание неугодных, карательные мероприятия, ну и, если очень повезёт, поиск преступников - вот цель сбора биометрических данных. Другие стороны, в том числе коммерческие компании заинтересованы в биометрии куда меньше. Им её сложнее применить и монетизировать (комбайны по массовой слежке типа google/apple/facebook не в счёт - это отдельная история), у них возникает множество новых юридических рисков и т.д. Может быть банки - единственное исключение, где это действительно может быть необходимо, и то лично я на 100% являюсь противником использования биометрии в антифроде, т.к. мы живём в эпоху нейросетей, и доверять биометрии в этом случае просто опасно. Как можно признавать значащим фактором аутентификации то, что уже прямо сейчас может быть легко подделано? Причём стоит это копейки и делается быстро и без проблем.
Поскольку мы улыбаясь, машА, с воздушными шариками в руках и улыбками на лицах неотвратимо движемся в сторону всемирного цифрового концлагеря, остановить применение биометрии вряд ли получится - это слишком выгодный инструмент для государств по всему миру, хотя, разумеется, если бы хоть одно государство было по настоящему заинтересовано и действовало в интересах своих граждан, то уже сейчас бы оно ввело полный законодательный запрет на хранение и обработку любых биометрических данных и серьёзную ответственность за нарушение этого, но мы все понимаем, что этого точно не произойдёт. А раз уж киберпанк оказался самым пророческим жанром последних лет и наступление подобного будущего неотвратимо, то нужно по крайней мере понимать к чему готовиться.
Первое - биометрия нарушает фундаментальное свойство защиты информации "forward secrecy". Когда ваши данные будут скомпрометированы (именно "когда", а не "если"), то они будут скомпрометированы навсегда. По простому - вы не можете "перевыпустить" свои лицо, голос, отпечатки пальцев. Если у вас украли данные например RSA ключей для идентификации и вы об этом узнали, то вы в тот же момент перевыпускаете ключи и забываете об этой проблеме навсегда. В случае с биометрическими данными кража будет создавать для вас угрозу всю будущую жизнь. Объяснять серьёзность этого, я думаю, излишне.
Второе - биометрия - это недетерминированные алгоритмы идентификации, они могут ошибаться и они будут ошибаться на большой выборке. Когда я работал с движком распознавания лиц, то мы делали достаточно много экспериментальных продуктов с ним, и точность распознавания была не идеальной. Продаваны от компании говорили про то, что система способна различать 10+ миллионов лиц, различать близнецов и т.д. Менеджеры были воодушевлены возможностью наклепать проектов на новый незанятый рынок. Однако, поскольку конкретно я лично работал с технической частью, то общих восторгов, мягко говоря, не разделял. Я лично тестировал этот движок на близнецах и у меня есть скриншот, как движок выдал значение в 0.995 что "это один и тот же человек" на фото двух знакомых близнецов, которых именно человек легко отличит и по внешности, и по голосу, и по поведению. Я сталкивался с тем что качество распознавания начинало критически ухудшаться при неправильном угле установки камеры, с которого неудачно выхватывались основные точки на лице, или с определённого расстояния. Например, в вышеупомянутом банке изображения снимали с дешёвой 500-рублёвой USB-камеры, с таким отвратным качеством, что она, кажется, про двух абсолютно случайных людей может сказать что "это один и тот же человек". Liveless проверки я лично обманывал несколькими разными способами. Ну не мог в те времена движок отличить фотографию или видео от живого человека, да и как смог бы? Изображение он получает не с какой-то хитрой камеры с ИК датчиками и сенсорами строящими 3D проекцию лица с расстояниями до точек, а просто с фото или видеопотока. Вы наверняка читали про то что люди проходят в метро по face-pay за деньги, которые система списывает каких-то других, случайных людей, и это только самый безобидный сценарий. Представьте что будет, если ваше лицо вдруг окажется сильно схоже с лицом какого-нибудь разыскиваемого преступника. Приятно будет получать автоматические штрафы или "горячий приём" сотрудниками правоохранительных органов? И ходить потом обивать пороги, доказывать что вы это вы - это будет уже ваша забота, и именно вы будете тратить на это свои время и силы.
Третье и самое опасное - биометрия, именно в том движке с которым работал я, и который, вероятно, стал ЕБС, обрабатывается небезопасно. Заявления в духе "ну вот вы же на айфоне используете биометрию" - это просто вздор. Это типичная подмена правильного подхода - "security by design" на ложный "security by policy". Биометрия на мобильных устройствах хранится и обрабатывается исключительно в ТЕЕ - либо в отдельном чипе, либо внутри трастлета. Извлечь её оттуда технически невозможно, можно передать данные туда и спросить "это сохранённое лицо/палец или нет?", можно разблокировать ключ для расшифровки каких-то данных или ключ подписи, можно их удалить и т.д. но их нельзя получить в каком-то читаемом виде. Это гарантирует их безопасность - это "security by design".
Биометрия же в вышеупомянутом движке была выражена просто в виде данных, они получалась в виде данных из фото или видео, в виде данных хранилась и передавалась между клиентом и сервером, ни о каком безопасном хранении и обработке в специализированном железе и речи не шло. Вот как условные Фамилия, Имя, Отчество хранятся в базе данных в виде текста, вот точно также хранились и эти данные. Когда эти данные будут украдены (опять же, это вопрос "когда", а не "если") вас сможет отслеживать по любой камере не только условный "товарищ майор", как это предполагается сейчас, но и вообще абсолютно любой человек, всегда, до конца вашей жизни. Ваше лицо будет навсегда связано с вашими данными. Вас всегда будет узнавать абсолютно любая камера, телефон, кто угодно. Представьте каково будет стать жертвой преследования в этом случае. Вы уже не сможете быть в безопасности нигде и никогда.
Может быть что-то изменилось с тех пор и сейчас данные обрабатываются по настоящему безопасно, с применением SE чипов, но я почти на 100% уверен что это не так. Государство ОБЕЩАЕТ вам ("security by policy"), что сохранит эти данные, но это обоснование безопасности системы уровня "trust me bro". Посмотрите на реальную ситуацию, например, с персональными данными россиян - данные 90% граждан РФ пробиваются в известных телеграм-ботах по цене пары коробков спичек, с полными ФИО, паспортными данными, адресом, телефонами, почтами, снилсами, инн и многими другими вещами. Может быть я что-то мало понимаю в жизни, или плохо знаю устройство подобных систем в других странах, но, по моему, это - абсолютный провал. Я такого не видел больше нигде и никогда.
Моя рекомендация на счёт ЕБС очень проста - всеми возможными способами избегайте попадания ваших данных в ЕБС столько, сколько это будет возможно. Не соглашайтесь на это в банках, не соглашайтесь на это у опсосов. Если есть какая-то возможность, напишите заявления на запреты обработки биометрических данных, отказ от их сдачи и обработки и т.д. Если данные уже забрали, но есть возможность удалить их - удалите. Понятное дело, что удаление - формальное, только для вас и данные уже украдены. Понятное дело, что рано или поздно сдачу биометрии либо сделают добровольно-принудительной через законы, либо обманом как вот обсуждаемый в статье банк, но всё равно, старайтесь как можно дольше уклоняться от этого, не упрощайте жизнь мошенникам и аферистам.
Когда биометрические данные будут собраны со всех граждан и утекут в руки мошенников, мы получим такой невиданный масштаб мошенничества нового типа, с которым мы не сталкивались никогда в истории. Пусть хотя бы как-то юридически вы будете прикрыты тем, что отказывались от сбора и обработки этой информации везде где могли. Это хоть как-то даст вам в будущем возможность отстаивать свои интересы на юридическом поле.
По теме статьи: тиньков сознательно ввели клиентов в заблуждение чтобы по их невнимательности, обманом, получить согласие на обработку биометрических данных, которое в противном случае большинство людей дать бы отказалось. Это недостойный поступок достойный осуждения, и народных минусов, как вижу, официальный аккаунт тинька в комментариях уже словил. Сойдёт ли это им с рук? Конечно! Государство решило назначить крайними крупный бизнес, чтобы весь негатив от сбора биометрии летел в него, но поскольку получить биометрические данные для контроля и слежки за гражданами ну уж очень сильно хочется, то суды, разумеется, все эти конторы и банки отмажут. У меня лично претензий конкретно к разработчикам банка нет, я понимаю что они это делают не по своей воле. Как говорится, все всё понимают.
Доводилось писать плагины и для IDE (Android Studio) и для сборки (Gradle). Технически - очень непростое занятие, документации либо очень мало (как в случае с платформой Intellij), либо черезчур много и в ней сложно разобраться (это у Gradle), долго вникать в API, приходится смотреть на существующие в опенсорсе примеры и поначалу тратить довольно много времени на самые простые действия, но результат того стоит. Иметь интеграцию на уровне IDE, вместо, например, работы руками или вызова каких-то внешних инструментов, на долгой дистанции выливается в значительную экономию ресурса времени, а, в случае безопасности, ещё и внимания, т.к. человек легко может упустить какую-то небольшую ошибку, которая имеет шансы вылиться в серьёзные проблемы с безопасностью в проде
Недавно появился проект открытой прошивки для популярных на рынке камер видеонаблюдения - OpenIPC. Уже поддерживается несколько десятков моделей и разработка активно движется.
Конечно, настройка предполагает выбор совместимого оборудования и должной технической компетенции для перепрошивки, что подходит не для каждого, но в данном деле, боюсь, по другому пока никак. Будем надеяться, что со временем появятся этичные производители оборудования, которые будут поставлять камеры на свободной неогороженной прошивке, без всяких умных облаков и прочего.
Мне кажется, есть крайне важные с точки зрения приватности вещи, например домашнее видеонаблюдение, которые крайне сложно доверить непонятным облакам от производителей умных устройств, репутация которых уже не раз была испорчена массовым злоупотреблением доверия клиентов.
Есть такая система - uceprotect, у них помимо репутации самого адреса отслеживаются также виды репутации "L2" и "L3", что означает, если я правильно помню, средняя отрицательная репутация с соседями по блоку адресов и с соседями по AS. Вот эти значения для моего адреса ненулевые, однако я пользуюсь прям очень небольшим VPS провайдером и эти значения у меня на порядок или даже несколько порядков, в десятки и сотни раз, ниже чем у других, специально проверял. Просто видимо Google не желает принимать почту от мелких провайдеров, только от крупных. Я читал иностранные форумы по администрированию и вычитал мнение что те, кто хостит почту у крупных провайдеров с внимательной к абузам поддержкой типа Contabo, подобные проблемы испытывают реже. Внимательные - это значит готовые по первому требованию выключить VPS на адресе, ограничить доступ владельцу VPS к своей машине, или выдать его данные. Вообще, люди рекомендуют заранее смотреть в интернете у каких провайдеров лучше размещать свою почту. Некоторые провайдеры вообще явно запрещают это делать и на уровне своих фаерволов просто блокируют все связанные с почтой порты, т.е. почту на них вы не сможете ни отправить, ни принять.
Особенно пикантно то, что uceprotect зарабатывают тем, что за деньги, достаточно немаленькие деньги, по подписке, удаляют из своей базы записи о плохой репутации адресов. Это почти легализованное вымогательство, и это в очередной раз подводит к тому, что вся индустрия электронной почты живёт на деньги спамеров и корпораций занимающихся массовой слежкой. Спамеру абсолютно не проблема заплатить несколько сотен долларов за чистоту репутации адреса. Обычный владелец почтового сервера этого делать не будет. Письма со спамом доставятся, а вот письма обычного владельца почтового сервера попадут в спам. Если вы обычный человек и вам хочется чтобы ваша почта доставлялась до адресата - добро пожаловать в крупные конторы вроде Google.
Мне кажется, крупные компании тут лукавят, и это очень, очень мягко говоря. Соблюдение SPF/DKIM/DMARC и раньше де-факто было минимальной необходимой планкой для того чтобы письмо вообще было доставлено, хотя бы в папку "спам", да и настроить это дело - не проблема. Реальные проблемы - в сломанном институте репутации, в том что весь бизнес связанный с электронной почтой в мире в первую очередь ориентирован на самих же спамеров и зависит от их денег, и в том, что большие корпорации заинтересованы в том чтобы ограничить конкуренцию и потенциально загнать всех возможных клиентов к крупным провайдерам, желательно - к себе.
Как человек поддерживающий свой сервер с почтой могу сказать, что тот же gmail отказывается принимать письма с личного сервера с полностью настроенными RDNS, PTR, DNSSEC, DANE, TLSA, MTA-STS, SPF, DKIM, DMARC, оценкой 10/10 на mailtester-e, доменом который существует уже 7 лет и 100% кристально чистой репутацией IP-адреса в базах типа spamhaus-а. Просто их smtp-сервер отвечает "мы вашему адресу не доверяем, письмо принимать не будем". Тот же Яндекс, например, письма всё же принимает и доставляет до адресатов, но они 100% улетают в спам.
В итоге для доставки важных писем на ящики содержащиеся у крупных провайдеров электронной почты мне приходится отправлять их через smtp-реле, что в общем-то подрывает саму идею использования своего почтового сервера, т.к. во-первых, все письма проходят через третьи руки, и доставка проходит не напрямую, а во-вторых, владельцы smtp-реле подсовывают в проходящие через них письма свои заголовки и пиксели для слежки за письмом, контролем доставки, и т.д. чем, например, ломают оригинальную подпись и получатель получает письмо с большим предупреждением о том что "цифровая подпись нарушена, кто-то подделал содержание этого письма".
Я понимаю, в общих чертах, почему так получилось и как мы пришли к жизни такой. Понимаю, что спам - реальная проблема. Но тот факт что письма принимаются от провайдеров smtp реле и не принимаются от владельцев частных email серверов, потому что у владельцев smtp-реле более высокая репутация - это просто вздор. Если вы зайдёте на сайт любого из них, то увидите рекламные слоганы в духе "надёжно доставляйте миллионы писем клиентам", "поможем вам провести маркетинговую компанию под ключ", "без головной боли поможем вам постоянно напоминать о себе" и т.д. Суть всех этих компаний - рассылать миллионы писем людям которые по неосторожности оставили где-то свою настоящую почту, и smtp-реле зарабатывают на этом огромные деньги. Именно эти письма: "купи у нас ещё и вот это...", "у нас акция...", "скидки только для вас..." - различный кликбейтный мусор и спам, пользователи чаще всего потом не глядя отправляют в корзину разбирая свой почтовый ящик. Если вы посмотрите на заголовки письма - в половине случаев отправлены именно через подобные smtp-реле.
Ирония в том, что для того чтобы письма надёжно доставлялись, адрес должен иметь репутацию у крупных провайдеров почты. Большие ребята дружат между собой и адресам smtp-серверов друг-друга доверяют. В противном случае вступает в силу обычный подход, где нужен прогрев, репутация и т.д. Таким образом почта становится удовольствием только для крупных компаний, у которых есть возможность отправлять десятки и сотни писем ежедневно, ещё и желательно с адреса внутри своей AS и блока адресов, который случайно не окажется по соседству со случайной VPS, которую спамеры арендуют на день-два чтобы разослать миллионы спама про казино, т.к. репутация адресов соседей влияет и на вашу - спамеры после своей рассылки забудут и про VPS и про её адрес, а вот именно ваши письма приниматься из-за плохой репутации перестанут. Мелкий и средний бизнес же, в виду сломанности репутации, обязан либо обращаться к разным мутным конторам бизнес которых - просто доставить почту, либо к крупным провайдерам, тем же самым Google и им подобным, которых такая ситуация на 100% устраивает.
Плюсую. Недавно в силу обстоятельств тоже возникла необходимость поднять свою доску, посмотрел какие есть варианты, остановил выбор на https://plane.so/ Пользуюсь ей не очень долго, и основательного мнения пока не составил, но пока что впечатления позитивные.
Они позиционируют себя как замена Jira, и мне их функционал показался действительно достаточно богатым. Приятный дизайн, поддержка обычной и тёмной тем, удобный UI. Проект полностью open-source, self-hosted - буржуи вас по айпи не вычислят и не забанят. Минусы правда тоже есть: пока что нет поддержки русского языка (но в issues это уже обсуждается), и ещё мобильные приложения - они есть, но собирать их нужно самому руками, в маркеты они почему-то не публикуются.
Я обычно, когда вынужден писать негатив, напрямую название компании не называю. Те кто знают, те узнают. Мне скорее хотелось донести серьёзность ситуации, но да, это они.
Причём, в условиях нынешней политики и факта того что управление компанией, как и несколькими другими до неё, перехватило государство, а оригинальный основатель отправлен на бутылку по статье, с которой невозможно даже с материалами уголовного дела ознакомиться, то всё становится ещё пикантнее.
Откровенно говоря, я подозреваю, что в нынешних условиях любое, хотя бы одно, установленное российское приложение на устройстве == 24/7 доклад о себе товарищу майору
Как человек который любит реверс-инженерить мобильные приложения, и ковырявший, ради интереса, приложения в том числе и банков, могу сказать - правильно делаете. Мобильные приложения банков в РФ собирают неприлично много информации о пользователе, в таких количествах, в которых она им явно не требуется. Особенно с переездом в российский RuStore, т.к. там нет политик ограничивающих использование например сбор информации об установленных на устройство приложениях (QUERY_ALL_PACKAGES), в то время как гугл просто не даст приложению запрашивающему такие права опубликоваться в официальном маркете.
Приведу пример из того что я находил лично. Насколько я понимаю, в приложения банков встраиваются специальные антифрод системы, в виде внешних зависимостей. Формально, насколько я понимаю, их цель благая - иметь возможность в случае разбирательств по мошенничеству по максимуму идентифицировать устройство с которого открыта сессия и использовать это как техническое доказательство. Вот только фактически это работает так, что они собирают всю информацию на устройстве до которой только могут дотянуться, и отправляют её раз в несколько секунд на бэк, причём даже не на домен самого банка, а на домен другой компании - крупного российского вендора в сфере информационной безопасности.
Среди этой информации - точная локация. Если на неё приложению не выдано пользователем соответствующее разрешение (например для функционала просмотра карты расположения банкоматов), то по возможности собирается информация о ближайших сотовых вышках и точках, по которой локацию тоже можно определить с точностью до пары десятков метров. Подумайте, ваша точная локация, с данными которые идентифицируют вас на 100% (сессия с учёткой банка -> привязка к sim-карте -> привязка к паспорту) раз в несколько секунд, улетает "куда надо". И, разумеется, этот функционал крутится в отдельном сервисе, который прилагает все усилия для того, чтобы продолжить работу даже после того как приложение будет закрыто, стартует вместе с загрузкой устройства, и т.д.
Причём, особенно интересно то, что эта система, судя по всему, скрывает свой функционал даже от самих разработчиков банка, и они сами не знают что это за функционал вшит в их приложении и работает там втихаря. Все передаваемые данные шифруются вшитым в классы публичным ключом RSA и на сервер вендора улетают в зашифрованном виде, с контролем в обе стороны сертификатов при установке соединения. Т.е. даже если вы исследуете приложение под mitm прокси, на рутованном устройстве, с подсунутым на устройство в системное хранилище сертификатом, этот код не будет ничего совершать и как-то выдывать запросы к серверу, а если вы сымитируете на эмуляторе окружение в котором системная openssl будет выдавать доверие любому сертификату, то увидите только пошифрованные бинарные данные, и, поскольку это шифрование публичным ключом RSA, то этот фарш уже невозможно провернуть назад. Только исследование памяти работающего процесса под динамической инструментацией выявило всю эту историю.
Я бы даже и не полез ковырять эту штуку, но уж больно мутно и подозрительно она выглядела и хотелось разобраться что к чему. Я совершенно не удивлюсь тому, что во многих российских приложениях есть подобный функционал, и что разработчики доработали его таким образом чтобы не выдавать его наличие в коде любопытствующим мимокрокодилам вроде меня. Так что, если вы пользуетесь хотя бы одним из них, то уже имеете шансы серьёзно скомпрометировать себя и докладывать куда нужно о своём местоположении в реальном времени.
Уверен, что все соглашения об обработке персданных составлены нужным образом, и предъявлять что-либо банкам или вендору бессмысленно, потому что "всё для вашего блага" и "соглашение вы подписали", но этичность подобных действий, лично для меня, под большим вопросом. Что интересно, в иностранных приложения такой дичи я встречаю куда меньше. Комбайны по массовой слежке типа фейсбука не в счёт - это отдельная история. А вот в России у компаний, как будто бы, просто какой-то бзик на слежке за клиентами
Для тех кто хочет заселфхостить себе парольный менеджер есть ещё более крутой вариант: 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 наоборот - реально работал, ещё несколько лет назад и реально решал проблему цензуры. Выводы, как говорится, делайте сами
Справедливо :) Я видел что mac mini, особенно достаточно старых серий, можно взять за очень доступную цену на том же авито, но, думаю, во-первых, отчасти, мне просто хотелось поэкспериментировать с хакинтошем, а, во-вторых, я держал в уме то, что такой мини-компик всегда можно перенастроить и использовать как обычную домашнюю машину общего назначения.
Думаю что имелось ввиду "на схожем по производительности железе", и ещё на х86. Процы Apple M, конечно, по производительности обгонят большинство сопоставимых x86
Круто что предложение по аренде серверов на macos существует. Штука экзотическая, крайне редко необходимая, и существующая, по моему мнению, исключительно благодаря закрытости Apple и нежеланию делать нормальную кросскомпиляцию под свою платформу, но вот когда она внезапно оказывается нужна, хорошее решение найти очень непросто. Ну и цены на подобные решения, особенно в условиях дефицита как спроса, так и предложения, заставляют хвататься за сердце.
Лично я для себя решил что аренда macos серверов - это слишком большая роскошь. Была у меня некоторое время назад необходимость организовать специфическую, работающую только в macos сборку. По итогу, настроил для себя сервер на хакинтоше. Купил под это дело мини-пк (типа beelink и ему подобных), взял по скидке на распродаже 11.11 на алиэкспрессе за ~300 долларов. По характеристикам: Ryzen 7 5700U, 32GB RAM, 1TB SSD. Райзены 5000-6000 поддерживаются проектом opencore, идентификаторы генерируются и зашиваются нормально, все остальные железки макосью тоже подхватились без проблем.
Да, по производительности такой велосипед однозначно уступает М2, тем более учитывая процессор U-серии, но с другой стороны, это же не какая-то на порядок отстающая по железу сборка: полноценных 8 ядер / 16 потоков, памяти - много, да и от macos людям обычно нужна не сверхпроизводительность, а просто возможность работать с инструментами которые Apple огораживает в своей системе - запускать компиляцию в xcode, и т.д. Пускай работать он будет в пару раз медленнее, зато чисто само железо стоит, как минимум, в 5 раз дешевле, а уж по сравнению с арендой выгода становится совсем очевидна. Кажется, что покупка отбивается за 1-2 месяца аренды аналогичной конфигурации, из-за чего покупка своего, вместо аренды у кого-то, становится выгодна даже для краткосрочной пробы, не говоря уже о долгосрочном использовании.
Пожалуй, главный и единственный минус подобного подхода в том, что при необходимости сделать большое обновление, например на новую мажорную версию macos что-нибудь может поломаться, но я пока, к счастью, в своём проекте ни с какими проблемами не сталкивался, и свои задачи этот мини-компик выполняет на все 100, надеюсь что так оно и продолжит работать. Я несколько опасался возможных проблем и перед его покупкой почитал интернеты на предмет того, каких можно ожидать подвохов при работе на хакинтоше. Оказалось, что есть люди которые полноценно и стабильно работают на таких системах, например занимаются ios разработкой. Иронично то, что, по их утверждениям, xcode на хакинтошах работает даже лучше и быстрее чем на оригинальном железе от Apple
Я знаю что Хабр - не жалобная книга, но история с биометрией - это реально очень важно и, думаю, что высказаться по данному вопросу - тоже важно. Тем более, мне есть что сказать.
В комментариях я заметил, что кто-то интересуется "в чём вообще проблема с ЕБС?". Я несколько лет назад, в 2017-2018 годах, плотно работал с движком распознавания лиц, компанию разработчика которого в итоге выкупило государство, и вероятно, если и не полностью, то частично в ЕБС используются наработки того движка с которым работал я. Пару лет назад, стоя в очереди в банке, я увидел как оператор снимала у клиента лицо на камеру, и просила выполнить некоторые действия, в которых я узнал характерные liveless проверки (проверки на то что в кадре живой человек, а не фото или видео), которые видел в API того движка, так что лично я уверен что это именно он, и похоже что с тех пор он не сильно изменился.
Я думаю, что сделав предположение о том что ЕБС нужен исключительно государству для слежки и контроля за гражданами я на 90% попаду в точку. Выслеживание неугодных, карательные мероприятия, ну и, если очень повезёт, поиск преступников - вот цель сбора биометрических данных. Другие стороны, в том числе коммерческие компании заинтересованы в биометрии куда меньше. Им её сложнее применить и монетизировать (комбайны по массовой слежке типа google/apple/facebook не в счёт - это отдельная история), у них возникает множество новых юридических рисков и т.д. Может быть банки - единственное исключение, где это действительно может быть необходимо, и то лично я на 100% являюсь противником использования биометрии в антифроде, т.к. мы живём в эпоху нейросетей, и доверять биометрии в этом случае просто опасно. Как можно признавать значащим фактором аутентификации то, что уже прямо сейчас может быть легко подделано? Причём стоит это копейки и делается быстро и без проблем.
Поскольку мы улыбаясь, машА, с воздушными шариками в руках и улыбками на лицах неотвратимо движемся в сторону всемирного цифрового концлагеря, остановить применение биометрии вряд ли получится - это слишком выгодный инструмент для государств по всему миру, хотя, разумеется, если бы хоть одно государство было по настоящему заинтересовано и действовало в интересах своих граждан, то уже сейчас бы оно ввело полный законодательный запрет на хранение и обработку любых биометрических данных и серьёзную ответственность за нарушение этого, но мы все понимаем, что этого точно не произойдёт. А раз уж киберпанк оказался самым пророческим жанром последних лет и наступление подобного будущего неотвратимо, то нужно по крайней мере понимать к чему готовиться.
Первое - биометрия нарушает фундаментальное свойство защиты информации "forward secrecy". Когда ваши данные будут скомпрометированы (именно "когда", а не "если"), то они будут скомпрометированы навсегда. По простому - вы не можете "перевыпустить" свои лицо, голос, отпечатки пальцев. Если у вас украли данные например RSA ключей для идентификации и вы об этом узнали, то вы в тот же момент перевыпускаете ключи и забываете об этой проблеме навсегда. В случае с биометрическими данными кража будет создавать для вас угрозу всю будущую жизнь. Объяснять серьёзность этого, я думаю, излишне.
Второе - биометрия - это недетерминированные алгоритмы идентификации, они могут ошибаться и они будут ошибаться на большой выборке. Когда я работал с движком распознавания лиц, то мы делали достаточно много экспериментальных продуктов с ним, и точность распознавания была не идеальной. Продаваны от компании говорили про то, что система способна различать 10+ миллионов лиц, различать близнецов и т.д. Менеджеры были воодушевлены возможностью наклепать проектов на новый незанятый рынок. Однако, поскольку конкретно я лично работал с технической частью, то общих восторгов, мягко говоря, не разделял. Я лично тестировал этот движок на близнецах и у меня есть скриншот, как движок выдал значение в 0.995 что "это один и тот же человек" на фото двух знакомых близнецов, которых именно человек легко отличит и по внешности, и по голосу, и по поведению. Я сталкивался с тем что качество распознавания начинало критически ухудшаться при неправильном угле установки камеры, с которого неудачно выхватывались основные точки на лице, или с определённого расстояния. Например, в вышеупомянутом банке изображения снимали с дешёвой 500-рублёвой USB-камеры, с таким отвратным качеством, что она, кажется, про двух абсолютно случайных людей может сказать что "это один и тот же человек". Liveless проверки я лично обманывал несколькими разными способами. Ну не мог в те времена движок отличить фотографию или видео от живого человека, да и как смог бы? Изображение он получает не с какой-то хитрой камеры с ИК датчиками и сенсорами строящими 3D проекцию лица с расстояниями до точек, а просто с фото или видеопотока. Вы наверняка читали про то что люди проходят в метро по face-pay за деньги, которые система списывает каких-то других, случайных людей, и это только самый безобидный сценарий. Представьте что будет, если ваше лицо вдруг окажется сильно схоже с лицом какого-нибудь разыскиваемого преступника. Приятно будет получать автоматические штрафы или "горячий приём" сотрудниками правоохранительных органов? И ходить потом обивать пороги, доказывать что вы это вы - это будет уже ваша забота, и именно вы будете тратить на это свои время и силы.
Третье и самое опасное - биометрия, именно в том движке с которым работал я, и который, вероятно, стал ЕБС, обрабатывается небезопасно. Заявления в духе "ну вот вы же на айфоне используете биометрию" - это просто вздор. Это типичная подмена правильного подхода - "security by design" на ложный "security by policy". Биометрия на мобильных устройствах хранится и обрабатывается исключительно в ТЕЕ - либо в отдельном чипе, либо внутри трастлета. Извлечь её оттуда технически невозможно, можно передать данные туда и спросить "это сохранённое лицо/палец или нет?", можно разблокировать ключ для расшифровки каких-то данных или ключ подписи, можно их удалить и т.д. но их нельзя получить в каком-то читаемом виде. Это гарантирует их безопасность - это "security by design".
Биометрия же в вышеупомянутом движке была выражена просто в виде данных, они получалась в виде данных из фото или видео, в виде данных хранилась и передавалась между клиентом и сервером, ни о каком безопасном хранении и обработке в специализированном железе и речи не шло. Вот как условные Фамилия, Имя, Отчество хранятся в базе данных в виде текста, вот точно также хранились и эти данные. Когда эти данные будут украдены (опять же, это вопрос "когда", а не "если") вас сможет отслеживать по любой камере не только условный "товарищ майор", как это предполагается сейчас, но и вообще абсолютно любой человек, всегда, до конца вашей жизни. Ваше лицо будет навсегда связано с вашими данными. Вас всегда будет узнавать абсолютно любая камера, телефон, кто угодно. Представьте каково будет стать жертвой преследования в этом случае. Вы уже не сможете быть в безопасности нигде и никогда.
Может быть что-то изменилось с тех пор и сейчас данные обрабатываются по настоящему безопасно, с применением SE чипов, но я почти на 100% уверен что это не так. Государство ОБЕЩАЕТ вам ("security by policy"), что сохранит эти данные, но это обоснование безопасности системы уровня "trust me bro". Посмотрите на реальную ситуацию, например, с персональными данными россиян - данные 90% граждан РФ пробиваются в известных телеграм-ботах по цене пары коробков спичек, с полными ФИО, паспортными данными, адресом, телефонами, почтами, снилсами, инн и многими другими вещами. Может быть я что-то мало понимаю в жизни, или плохо знаю устройство подобных систем в других странах, но, по моему, это - абсолютный провал. Я такого не видел больше нигде и никогда.
Моя рекомендация на счёт ЕБС очень проста - всеми возможными способами избегайте попадания ваших данных в ЕБС столько, сколько это будет возможно. Не соглашайтесь на это в банках, не соглашайтесь на это у опсосов. Если есть какая-то возможность, напишите заявления на запреты обработки биометрических данных, отказ от их сдачи и обработки и т.д. Если данные уже забрали, но есть возможность удалить их - удалите. Понятное дело, что удаление - формальное, только для вас и данные уже украдены. Понятное дело, что рано или поздно сдачу биометрии либо сделают добровольно-принудительной через законы, либо обманом как вот обсуждаемый в статье банк, но всё равно, старайтесь как можно дольше уклоняться от этого, не упрощайте жизнь мошенникам и аферистам.
Когда биометрические данные будут собраны со всех граждан и утекут в руки мошенников, мы получим такой невиданный масштаб мошенничества нового типа, с которым мы не сталкивались никогда в истории. Пусть хотя бы как-то юридически вы будете прикрыты тем, что отказывались от сбора и обработки этой информации везде где могли. Это хоть как-то даст вам в будущем возможность отстаивать свои интересы на юридическом поле.
По теме статьи: тиньков сознательно ввели клиентов в заблуждение чтобы по их невнимательности, обманом, получить согласие на обработку биометрических данных, которое в противном случае большинство людей дать бы отказалось. Это недостойный поступок достойный осуждения, и народных минусов, как вижу, официальный аккаунт тинька в комментариях уже словил. Сойдёт ли это им с рук? Конечно! Государство решило назначить крайними крупный бизнес, чтобы весь негатив от сбора биометрии летел в него, но поскольку получить биометрические данные для контроля и слежки за гражданами ну уж очень сильно хочется, то суды, разумеется, все эти конторы и банки отмажут. У меня лично претензий конкретно к разработчикам банка нет, я понимаю что они это делают не по своей воле. Как говорится, все всё понимают.
Доводилось писать плагины и для IDE (Android Studio) и для сборки (Gradle). Технически - очень непростое занятие, документации либо очень мало (как в случае с платформой Intellij), либо черезчур много и в ней сложно разобраться (это у Gradle), долго вникать в API, приходится смотреть на существующие в опенсорсе примеры и поначалу тратить довольно много времени на самые простые действия, но результат того стоит. Иметь интеграцию на уровне IDE, вместо, например, работы руками или вызова каких-то внешних инструментов, на долгой дистанции выливается в значительную экономию ресурса времени, а, в случае безопасности, ещё и внимания, т.к. человек легко может упустить какую-то небольшую ошибку, которая имеет шансы вылиться в серьёзные проблемы с безопасностью в проде
Недавно появился проект открытой прошивки для популярных на рынке камер видеонаблюдения - OpenIPC. Уже поддерживается несколько десятков моделей и разработка активно движется.
Конечно, настройка предполагает выбор совместимого оборудования и должной технической компетенции для перепрошивки, что подходит не для каждого, но в данном деле, боюсь, по другому пока никак. Будем надеяться, что со временем появятся этичные производители оборудования, которые будут поставлять камеры на свободной неогороженной прошивке, без всяких умных облаков и прочего.
Мне кажется, есть крайне важные с точки зрения приватности вещи, например домашнее видеонаблюдение, которые крайне сложно доверить непонятным облакам от производителей умных устройств, репутация которых уже не раз была испорчена массовым злоупотреблением доверия клиентов.
По спамхаусу проверял - всё абсолютно чисто.
Есть такая система - uceprotect, у них помимо репутации самого адреса отслеживаются также виды репутации "L2" и "L3", что означает, если я правильно помню, средняя отрицательная репутация с соседями по блоку адресов и с соседями по AS. Вот эти значения для моего адреса ненулевые, однако я пользуюсь прям очень небольшим VPS провайдером и эти значения у меня на порядок или даже несколько порядков, в десятки и сотни раз, ниже чем у других, специально проверял. Просто видимо Google не желает принимать почту от мелких провайдеров, только от крупных. Я читал иностранные форумы по администрированию и вычитал мнение что те, кто хостит почту у крупных провайдеров с внимательной к абузам поддержкой типа Contabo, подобные проблемы испытывают реже. Внимательные - это значит готовые по первому требованию выключить VPS на адресе, ограничить доступ владельцу VPS к своей машине, или выдать его данные. Вообще, люди рекомендуют заранее смотреть в интернете у каких провайдеров лучше размещать свою почту. Некоторые провайдеры вообще явно запрещают это делать и на уровне своих фаерволов просто блокируют все связанные с почтой порты, т.е. почту на них вы не сможете ни отправить, ни принять.
Особенно пикантно то, что uceprotect зарабатывают тем, что за деньги, достаточно немаленькие деньги, по подписке, удаляют из своей базы записи о плохой репутации адресов. Это почти легализованное вымогательство, и это в очередной раз подводит к тому, что вся индустрия электронной почты живёт на деньги спамеров и корпораций занимающихся массовой слежкой. Спамеру абсолютно не проблема заплатить несколько сотен долларов за чистоту репутации адреса. Обычный владелец почтового сервера этого делать не будет. Письма со спамом доставятся, а вот письма обычного владельца почтового сервера попадут в спам. Если вы обычный человек и вам хочется чтобы ваша почта доставлялась до адресата - добро пожаловать в крупные конторы вроде Google.
Мне кажется, крупные компании тут лукавят, и это очень, очень мягко говоря. Соблюдение SPF/DKIM/DMARC и раньше де-факто было минимальной необходимой планкой для того чтобы письмо вообще было доставлено, хотя бы в папку "спам", да и настроить это дело - не проблема. Реальные проблемы - в сломанном институте репутации, в том что весь бизнес связанный с электронной почтой в мире в первую очередь ориентирован на самих же спамеров и зависит от их денег, и в том, что большие корпорации заинтересованы в том чтобы ограничить конкуренцию и потенциально загнать всех возможных клиентов к крупным провайдерам, желательно - к себе.
Как человек поддерживающий свой сервер с почтой могу сказать, что тот же gmail отказывается принимать письма с личного сервера с полностью настроенными RDNS, PTR, DNSSEC, DANE, TLSA, MTA-STS, SPF, DKIM, DMARC, оценкой 10/10 на mailtester-e, доменом который существует уже 7 лет и 100% кристально чистой репутацией IP-адреса в базах типа spamhaus-а. Просто их smtp-сервер отвечает "мы вашему адресу не доверяем, письмо принимать не будем". Тот же Яндекс, например, письма всё же принимает и доставляет до адресатов, но они 100% улетают в спам.
В итоге для доставки важных писем на ящики содержащиеся у крупных провайдеров электронной почты мне приходится отправлять их через smtp-реле, что в общем-то подрывает саму идею использования своего почтового сервера, т.к. во-первых, все письма проходят через третьи руки, и доставка проходит не напрямую, а во-вторых, владельцы smtp-реле подсовывают в проходящие через них письма свои заголовки и пиксели для слежки за письмом, контролем доставки, и т.д. чем, например, ломают оригинальную подпись и получатель получает письмо с большим предупреждением о том что "цифровая подпись нарушена, кто-то подделал содержание этого письма".
Я понимаю, в общих чертах, почему так получилось и как мы пришли к жизни такой. Понимаю, что спам - реальная проблема. Но тот факт что письма принимаются от провайдеров smtp реле и не принимаются от владельцев частных email серверов, потому что у владельцев smtp-реле более высокая репутация - это просто вздор. Если вы зайдёте на сайт любого из них, то увидите рекламные слоганы в духе "надёжно доставляйте миллионы писем клиентам", "поможем вам провести маркетинговую компанию под ключ", "без головной боли поможем вам постоянно напоминать о себе" и т.д. Суть всех этих компаний - рассылать миллионы писем людям которые по неосторожности оставили где-то свою настоящую почту, и smtp-реле зарабатывают на этом огромные деньги. Именно эти письма: "купи у нас ещё и вот это...", "у нас акция...", "скидки только для вас..." - различный кликбейтный мусор и спам, пользователи чаще всего потом не глядя отправляют в корзину разбирая свой почтовый ящик. Если вы посмотрите на заголовки письма - в половине случаев отправлены именно через подобные smtp-реле.
Ирония в том, что для того чтобы письма надёжно доставлялись, адрес должен иметь репутацию у крупных провайдеров почты. Большие ребята дружат между собой и адресам smtp-серверов друг-друга доверяют. В противном случае вступает в силу обычный подход, где нужен прогрев, репутация и т.д. Таким образом почта становится удовольствием только для крупных компаний, у которых есть возможность отправлять десятки и сотни писем ежедневно, ещё и желательно с адреса внутри своей AS и блока адресов, который случайно не окажется по соседству со случайной VPS, которую спамеры арендуют на день-два чтобы разослать миллионы спама про казино, т.к. репутация адресов соседей влияет и на вашу - спамеры после своей рассылки забудут и про VPS и про её адрес, а вот именно ваши письма приниматься из-за плохой репутации перестанут. Мелкий и средний бизнес же, в виду сломанности репутации, обязан либо обращаться к разным мутным конторам бизнес которых - просто доставить почту, либо к крупным провайдерам, тем же самым Google и им подобным, которых такая ситуация на 100% устраивает.
Плюсую. Недавно в силу обстоятельств тоже возникла необходимость поднять свою доску, посмотрел какие есть варианты, остановил выбор на https://plane.so/ Пользуюсь ей не очень долго, и основательного мнения пока не составил, но пока что впечатления позитивные.
Они позиционируют себя как замена Jira, и мне их функционал показался действительно достаточно богатым. Приятный дизайн, поддержка обычной и тёмной тем, удобный UI. Проект полностью open-source, self-hosted - буржуи вас по айпи не вычислят и не забанят. Минусы правда тоже есть: пока что нет поддержки русского языка (но в issues это уже обсуждается), и ещё мобильные приложения - они есть, но собирать их нужно самому руками, в маркеты они почему-то не публикуются.
Я обычно, когда вынужден писать негатив, напрямую название компании не называю. Те кто знают, те узнают. Мне скорее хотелось донести серьёзность ситуации, но да, это они.
Причём, в условиях нынешней политики и факта того что управление компанией, как и несколькими другими до неё, перехватило государство, а оригинальный основатель отправлен на бутылку по статье, с которой невозможно даже с материалами уголовного дела ознакомиться, то всё становится ещё пикантнее.
Откровенно говоря, я подозреваю, что в нынешних условиях любое, хотя бы одно, установленное российское приложение на устройстве == 24/7 доклад о себе товарищу майору
Как человек который любит реверс-инженерить мобильные приложения, и ковырявший, ради интереса, приложения в том числе и банков, могу сказать - правильно делаете. Мобильные приложения банков в РФ собирают неприлично много информации о пользователе, в таких количествах, в которых она им явно не требуется. Особенно с переездом в российский RuStore, т.к. там нет политик ограничивающих использование например сбор информации об установленных на устройство приложениях (QUERY_ALL_PACKAGES), в то время как гугл просто не даст приложению запрашивающему такие права опубликоваться в официальном маркете.
Приведу пример из того что я находил лично. Насколько я понимаю, в приложения банков встраиваются специальные антифрод системы, в виде внешних зависимостей. Формально, насколько я понимаю, их цель благая - иметь возможность в случае разбирательств по мошенничеству по максимуму идентифицировать устройство с которого открыта сессия и использовать это как техническое доказательство. Вот только фактически это работает так, что они собирают всю информацию на устройстве до которой только могут дотянуться, и отправляют её раз в несколько секунд на бэк, причём даже не на домен самого банка, а на домен другой компании - крупного российского вендора в сфере информационной безопасности.
Среди этой информации - точная локация. Если на неё приложению не выдано пользователем соответствующее разрешение (например для функционала просмотра карты расположения банкоматов), то по возможности собирается информация о ближайших сотовых вышках и точках, по которой локацию тоже можно определить с точностью до пары десятков метров. Подумайте, ваша точная локация, с данными которые идентифицируют вас на 100% (сессия с учёткой банка -> привязка к sim-карте -> привязка к паспорту) раз в несколько секунд, улетает "куда надо". И, разумеется, этот функционал крутится в отдельном сервисе, который прилагает все усилия для того, чтобы продолжить работу даже после того как приложение будет закрыто, стартует вместе с загрузкой устройства, и т.д.
Причём, особенно интересно то, что эта система, судя по всему, скрывает свой функционал даже от самих разработчиков банка, и они сами не знают что это за функционал вшит в их приложении и работает там втихаря. Все передаваемые данные шифруются вшитым в классы публичным ключом RSA и на сервер вендора улетают в зашифрованном виде, с контролем в обе стороны сертификатов при установке соединения. Т.е. даже если вы исследуете приложение под mitm прокси, на рутованном устройстве, с подсунутым на устройство в системное хранилище сертификатом, этот код не будет ничего совершать и как-то выдывать запросы к серверу, а если вы сымитируете на эмуляторе окружение в котором системная openssl будет выдавать доверие любому сертификату, то увидите только пошифрованные бинарные данные, и, поскольку это шифрование публичным ключом RSA, то этот фарш уже невозможно провернуть назад. Только исследование памяти работающего процесса под динамической инструментацией выявило всю эту историю.
Я бы даже и не полез ковырять эту штуку, но уж больно мутно и подозрительно она выглядела и хотелось разобраться что к чему. Я совершенно не удивлюсь тому, что во многих российских приложениях есть подобный функционал, и что разработчики доработали его таким образом чтобы не выдавать его наличие в коде любопытствующим мимокрокодилам вроде меня. Так что, если вы пользуетесь хотя бы одним из них, то уже имеете шансы серьёзно скомпрометировать себя и докладывать куда нужно о своём местоположении в реальном времени.
Уверен, что все соглашения об обработке персданных составлены нужным образом, и предъявлять что-либо банкам или вендору бессмысленно, потому что "всё для вашего блага" и "соглашение вы подписали", но этичность подобных действий, лично для меня, под большим вопросом. Что интересно, в иностранных приложения такой дичи я встречаю куда меньше. Комбайны по массовой слежке типа фейсбука не в счёт - это отдельная история. А вот в России у компаний, как будто бы, просто какой-то бзик на слежке за клиентами
Для тех кто хочет заселфхостить себе парольный менеджер есть ещё более крутой вариант: 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 наоборот - реально работал, ещё несколько лет назад и реально решал проблему цензуры. Выводы, как говорится, делайте сами