В телеграме огромное количество пользователей, которые пришли в него за контентом и ради любимых каналов и блоггеров. Телеграм стал для многих новой социальной сетью, заменой ВКонтакте, и, к сожалению, такая аудитория не заинтересована в том, с кем Дуров сотрудничает и насколько это для них безопасно...
(говорю не про всех, конечно, это скорее актуально для молодого поколения, частью которого я сам являюсь)
Да, то, что проблема вызвана ТСПУ и действиями РКН не вызывает вопросов. Мы даже не в первый раз с таким сталкиваемся, но сейчас наиболее сильная волна таких «случайных» блокировок.
Самое печальное здесь то, что владельцы попавших под раздачу сервисов ничего не могут с этим поделать(
Владею проектом, большая часть инфраструктуры которого расположена на OVH. Начиная с 9 июня произошла значительная деградация подключений из РФ: после N килобайт данных соединения просто начинают терять пакеты. Причем это не полный дроп, изредка что-то таки долетает, из-за чего TCP подключения «зависают» в вечных retransmission, и даже определить достоверно, что подключение было «заблокировано» довольно тяжело.
Аналогичные вещи были замечены и с подключениями к другим хостинг-провайдерам. Кто-то жаловался на подключения к CloudFront, кто-то на CloudFlare.
А указанный вами сбой произошел позже, и не затронул, например, OVH. А вот проблемы были. И почему-то только лишь у российских пользователей.
Есть ли какие-то подтверждения этим словам? Это довольно сильное заявление, учитывая, что тот же Whats App обещает E2E и различные атаки на него не обходятся одним лишь перехватом трафика
У нашей школы несколько лет назад была вообще странная ситуация: журнал и некоторые сопутствующие сервисы (moodle) хостились прямо в школе, а вход на них был по просто IP адресу, без домена
Однажды со скуки в классе восьмом я обнаружил, что на этом IP адресе еще есть и FTP без авторизации. А там, помимо тонны всяких разных файлов, прямо в корне лежал файл с незашифрованным бэкапом всего школьного журнала. К счастью, именно персональных данных там почти не было (их можно было указать в учетке, но этого не делали ни школьники, ни учителя), зато были пароли надежно (нет) защищенные MD5 без соли
Я не стал об этом никому говорить тогда (остерегаясь последствий), поэтому этот архив пролежал там еще год, пока в новом учебном году школа не решила перейти на другой журнал (и заодно подчистить тот FTP-сервер)
В общем, это я к тому, что в целом в этой "индустрии" все довольно печально и проблемы далеко не единичны
Самоподписанный серт не будет считаться доверенным, ведь не подписан доверенным CA, на то он и самоподписанный
А LetsEncrypt требует подтвердить владение доменом либо через специальный файл, доступный по HTTP, либо через специальную DNS запись (и проверять он ее вряд ли будет через скомпрометированный DNS сервер)
Так что перехватить HTTPS едва ли представляется возможным, хотя иные виды атак все еще имеют место быть (например, можно спокойно перехватить HTTP, пусть его и не так много в современном вебе)
Проблема не столько в том, что автор решил защитить свою программу, сколько в том, как он это делает. Встраивание малвари - явный перебор. Аврот в любой момент может добавить что-то более вредоносное в скачиваемую нагрузку.
«Твой Дневник» каждые 20 минут будет присылать уведомления об оценках. Так как это сервис-посредник, вы понимаете, что по факту, если у нас 200 пользователей, то серверу придётся делать 200 авторизаций/запросов по токену, 200 раз прогружать расписание детей, 200 раз сравнивать, есть ли id полученной оценки в базе данных и 200-old_marks раз отправлять уведомление на устройства.
Почему бы не отправлять уведомление когда оценка будет выставлена? И не придется проверять новые оценки каждые 20 минут.
Вместо использования System.load, который требует полный путь до библиотеки, лучше использовать метод System.loadLibrary, который принимает название библиотеки. Она будет грузиться из java.library.path. (Его можно указать в параметрах JVM через -D)
Вместо написания класса Tunnel можно было использовать любую BlockingQueue из пакета java.util.concurrent (например ArrayBlockingQueue), которая выполняет почти те же задачи.
Видны, указатель на функцию можно получить через findExportByName() (как у автора в посте)
Затем можно и вызвать через NativeFunction
Да, неточно выразился, но мысль была такая: ей всё равно
В телеграме огромное количество пользователей, которые пришли в него за контентом и ради любимых каналов и блоггеров. Телеграм стал для многих новой социальной сетью, заменой ВКонтакте, и, к сожалению, такая аудитория не заинтересована в том, с кем Дуров сотрудничает и насколько это для них безопасно...
(говорю не про всех, конечно, это скорее актуально для молодого поколения, частью которого я сам являюсь)
Да, то, что проблема вызвана ТСПУ и действиями РКН не вызывает вопросов. Мы даже не в первый раз с таким сталкиваемся, но сейчас наиболее сильная волна таких «случайных» блокировок.
Самое печальное здесь то, что владельцы попавших под раздачу сервисов ничего не могут с этим поделать(
Это скорее просто интересное совпадение.
Владею проектом, большая часть инфраструктуры которого расположена на OVH. Начиная с 9 июня произошла значительная деградация подключений из РФ: после N килобайт данных соединения просто начинают терять пакеты. Причем это не полный дроп, изредка что-то таки долетает, из-за чего TCP подключения «зависают» в вечных retransmission, и даже определить достоверно, что подключение было «заблокировано» довольно тяжело.
Аналогичные вещи были замечены и с подключениями к другим хостинг-провайдерам. Кто-то жаловался на подключения к CloudFront, кто-то на CloudFlare.
А указанный вами сбой произошел позже, и не затронул, например, OVH. А вот проблемы были. И почему-то только лишь у российских пользователей.
Верно.
Есть ли какие-то подтверждения этим словам? Это довольно сильное заявление, учитывая, что тот же Whats App обещает E2E и различные атаки на него не обходятся одним лишь перехватом трафика
У нашей школы несколько лет назад была вообще странная ситуация: журнал и некоторые сопутствующие сервисы (moodle) хостились прямо в школе, а вход на них был по просто IP адресу, без домена
Однажды со скуки в классе восьмом я обнаружил, что на этом IP адресе еще есть и FTP без авторизации. А там, помимо тонны всяких разных файлов, прямо в корне лежал файл с незашифрованным бэкапом всего школьного журнала. К счастью, именно персональных данных там почти не было (их можно было указать в учетке, но этого не делали ни школьники, ни учителя), зато были пароли надежно (нет) защищенные MD5 без соли
Я не стал об этом никому говорить тогда (остерегаясь последствий), поэтому этот архив пролежал там еще год, пока в новом учебном году школа не решила перейти на другой журнал (и заодно подчистить тот FTP-сервер)
В общем, это я к тому, что в целом в этой "индустрии" все довольно печально и проблемы далеко не единичны
Эта слитая в 2024 году база данных (как минимум, ее часть) была в открытом доступе. Даже новость на хабре была: https://habr.com/ru/news/839076/
Тем не менее, присутствие этой информации для конкретного приложения дает понять, что оно установлено (и автору статьи интересен именно этот факт)
Самоподписанный серт не будет считаться доверенным, ведь не подписан доверенным CA, на то он и самоподписанный
А LetsEncrypt требует подтвердить владение доменом либо через специальный файл, доступный по HTTP, либо через специальную DNS запись (и проверять он ее вряд ли будет через скомпрометированный DNS сервер)
Так что перехватить HTTPS едва ли представляется возможным, хотя иные виды атак все еще имеют место быть (например, можно спокойно перехватить HTTP, пусть его и не так много в современном вебе)
Проблема не столько в том, что автор решил защитить свою программу, сколько в том, как он это делает. Встраивание малвари - явный перебор. Аврот в любой момент может добавить что-то более вредоносное в скачиваемую нагрузку.
Почему бы не отправлять уведомление когда оценка будет выставлена? И не придется проверять новые оценки каждые 20 минут.