Предложение задеанониться
Реакция интернета:
Реакция интернета:
Откровенность, вынуждающая вести себя респектабельно:
Откровенность, не вынуждающая вести себя респектабельно:
Обманчивая откровенность:
В России предложили ввести новые правила идентификации читателей, которые оставляют свои комментарии под материалами интернет-СМИ. С такой инициативой выступили в Ассоциации профессиональных пользователей соцсетей и мессенджеров (АППСИМ).
Авторов комментариев в СМИ в России предложили верифицировать
Копия письма директора АППСИМ Владимира Зыкова в адрес министра цифрового развития, связи и массовых коммуникаций России Константина Носкова есть в распоряжении RT.
Как пояснил автор инициативы, в настоящее время пользователи могут делиться своим мнением относительно того или иного материала, заходя в разделы комментариев СМИ через соцсети под вымышленными именами.
Нередко это заканчивается распространением на страницах интернет-изданий недостоверной, а также запрещённой в России информации, считает Зыков.
Ответственность за это несёт не пользователь, а СМИ, сказано в обращении. Согласно действующему законодательству, за распространение запрещённой информации редакции может грозить штраф или иное наказание, вплоть до прекращения деятельности.
«Для того чтобы это предотвратить, необходимо дать возможность пользователям СМИ, которые хотят оставлять комментарии под материалами издания, авторизоваться через портал госуслуг при помощи единой системы идентификации и аутентификации (ЕСИА). Таким образом, нести ответственность за оставленные комментарии будут граждане, а не СМИ», — сказано в тексте обращения.
Ранее Роскомнадзор представил список интернет-страниц с фейками.
https://russian.rt.com/russia/news/694161-kommentarii-smi-ve...
В чем вообще заключается анонимизация?
Кроме нашумевшего на всех углах интернета мнения о сокрытии IP-адреса есть еще множество других деталей. По большому счету все методы и средства анонимности преследуют цель сокрытия провайдера. Через которого уже можно получить физически точное местоположение пользователя, обладая дополнительной информацией о нем (IP, «отпечатки» браузера, логи его активности в определенном сегменте сети и пр.). А также большинство методов и средств направлены на максимальное сокрытие/нераскрытие этой косвенной информации, по которой позже можно будет спрашивать у провайдера нужного юзера.
Какие есть способы анонимизации пребывания в сети?
Если говорить про обособленные единицы анонимизации (ведь есть еще схемы в виде комбинирования того или иного средства анонимности), то можно выделить следующие:
1) Прокси-серверы — бывают разных видов, со своими особенностями. Классификация прокси под спойлером.
HTTP прокси – работает по протоколу http и выполняет функцию кэширования.
Степени анонимности: прозрачные, искажающие, анонимные, элитные.
Цепочку из HTTP проксей можно построить только в том случае, если они поддерживают метод CONNECT, исключением есть построение цепочки с помощью спец. программы.
HTTPS прокси (они же CONNECT) – прокси поддерживающие HTTP 1.1, которая в свою очередь имеет две спецификации - RFC 2616 и устаревший RFC 2068. Отличаются они тем, что в спец. RFC 2616 документирован метод CONNECT.
Все эти подтипы проксей имеют одну и ту же возможность – они могут работать с использованием метода CONNECT (в дополнение к GET / POST).
Различие между подтипами состоит исключительно в настройках программ прокси-серверов:
Если в настройках прокси сервера разрешено подключение методом CONNECT к порту 443 (https:// адреса), то это HTTPS proxy;
Если в настройках прокси сервера разрешено подключение методом CONNECT к любым портам (не считая 443 и 25), то он называется CONNECT proxy (в ICQ такой прокси называется HTTP proxy);
Если в настройках прокси сервера разрешено подключение методом CONNECT к порту 25 (почтовый сервис), то его можно использовать для рассылки почты и такой прокси называется mail-enabled, или 25 port enabled или прокси с открытым 25-м портом.
FTP прокси – работает по протоколу ftp и предназначен для анонимного управления сайтом (сервером). Все ftp прокси есть анонимными потому, что протокол FTP не предусматривает наличия прокси.
В паблике FTP прокси отсутствуют. Из FTP проксей невозможно построить цепочку.
CGI прокси (веб анонимайзер) – это страница на сайте, куда вбиваешь url, и она выводит указанную страницу. При этом адрес этой страницы (указанный в поле адреса) с точки зрения Вашего компьютера будет другой - что-то вроде
http://www.cgi-proxy...r-url.com/path/
С точки зрения анонимности CGI proxy бывают такими же, как и HTTP proxy. В «смешанных» цепочках этот вид проксей может стоять только на последнем месте.
SOCKS – этот вид прокси имеет 2 спецификации:
Socks 4 работает по протоколу TCP
Socks 5 поддерживает TCP, UDP, авторизацию и удаленный DNS-запрос. Socks по своей природе есть дейсвительно анонимным (потому, что он работает напрямую с TCP). Из проксей этого вида можно построить цепь. Сокс – самый лучший способ остаться анонимным в сети.
Анонимность Прокси
Всем известно, что при взаимодействии клиента с сервером, клиент посылает серверу некую информацию (в основном ее передает браузер, но прокся тоже может добавлять туда что-то «от себя»). Имеется ввиду название и версия операционной системы, название и версия браузера, настройки браузера (разрешение экрана, глубина цвета, поддержка java / javascript, ...), IP адрес клиента (если используется proxy, то заменяется proxy сервером на IP proxy), используется ли proxy сервер (если используется proxy, то IP клиента - это IP proxy - добавляется proxy сервером), если используется proxy, то Ваш реальный IP адрес (добавляется proxy сервером) и многое другое…
Эта информация передается в виде переменных окружения (environment variables).
Я остановлюсь лишь на тех, которые имеют отношение к анонимности.
Итак, Если прокси не используется, то переменные окружения выглядят следующим образом:
REMOTE_ADDR = Ваш IP
HTTP_VIA = не определена
HTTP_X_FORWARDED_FOR = не определена
Прозрачные прокси не скрывают инфу о реальном IP:
REMOTE_ADDR = IP proxy
HTTP_VIA = IP или имя proxy (используется proxy сервер)
HTTP_X_FORWARDED_FOR = реальный IP
Анонимные прокси (anon) не скрывают того факта, что используется прокси, но меняют реальный IP на свой:
REMOTE_ADDR = IP proxy
HTTP_VIA = IP или имя proxy (используется proxy сервер)
HTTP_X_FORWARDED_FOR = IP proxy
Искажающие прокси (distorting) не скрывают того факта, что используется proxy сервер. Однако реальный IP подменяется на другой (в общем случае произвольный, случайный):
REMOTE_ADDR = IP proxy
HTTP_VIA = IP или имя proxy (используется proxy сервер)
HTTP_X_FORWARDED_FOR = случайный IP
Элитные прокси (elite, high anon) не только меняют IP, но и скрывают даже сам факт использования прокси сервера:
REMOTE_ADDR = IP proxy
HTTP_VIA = не определена
HTTP_X_FORWARDED_FOR = не определена
2) VPN-сервисы — тоже работают по разным протоколам, которые предлагают провайдеры на выбор.
3) SSH-туннели, изначально создавались (и функционируют по сей день) для других целей, но также используются для анонимизации. По принципу действия довольно схожи с VPN’ами, поэтому в данной теме все разговоры о VPN будут подразумевать и их тоже.
4) Dedicated-серверы — самое основное преимущество в том, что пропадает проблема раскрытия истории запросов узла, с которого проводились действия (как это может быть в случае с VPN/SSH или прокси).
5) Tor;
6) I2P — анонимная, децентрализованная сеть, работающая поверх интернета, не использующая IP-адресацию.
7) Иные средства — анонимные сети, анонимайзеры и др. В силу пока недостаточной популярности они еще не изучены (а следовательно не имеют относительной гарантии надежности) сообществом, но достаточно перспективны.
Что стоит скрывать, или какие есть деанонимизирующие данные и методы их получения?
Хочу обратить внимание на один интересный ресурс, который посвящен вопросам, какую информацию мы оставляем о себе в сети, заходя в разных устройств:
1) IP-адрес, или самый популярный идентификатор в интернете. Дает возможность найти провайдера юзера и узнать у него точный адрес через тот же IP.
2) IP DNS провайдера, который можно «потерять» через метод, называемый DNS leaks (утечки DNS). Важно отметить, что эта утечка может произойти при связке HTTP/SOCKS4 (5 в некоторых случаях) + Tor! Поэтому тут надо быть особенно внимательными.
3) Если большая часть траффика долго выходит в интернет через один узел, например, тот же Tor, то можно провести так называемое профилирование — отнести определенную активность к определенному псевдониму, который можно сдеанонить через другие каналы.
4) Прослушивание трафика на выходном узле или Mitm-атаки (man in the middle).
5) Одновременное подключение к анонимному и открытому каналам может в некоторых ситуациях создать неприятности, например, при обрывании соединения у клиента, оба канала перестанут функционировать, и на сервере можно будет определить нужный адрес, сопоставив время отсоединения пользователей (правда, это довольно геморный и далеко неточный способ деанонимизации).
6) Деанонимизирующая активность в анонимном сеансе — пользование публичными сервисами, особенно теми, на которых уже есть информация об этом пользователе.
7) MAC-адрес, который получает WiFi точка при подключении к ней (или он может быть бэкапнут коммутаторами одной из локальных сетей, через которую был осуществлен выход в интернет).
8) Информация из браузеров:
Cookies — это текстовые файлы c какими-либо данными (как правило, уникальными для каждого пользователя), хранимые приложением (часто — браузером) для разных задач, например, аутентификации. Часто бывает, что клиент сначала посетил ресурс из открытого сеанса, браузер сохранил cookies, а потом клиент соединился из анонимного сеанса, тогда сервер может сопоставить cookies и вычислить клиента;
Flash, Java, Adobe Reader — первые три плагина вообще можно выделить, как отдельные приложения на базе браузера. Они могут обходить прокси (DNS leaks), засвечивать IP (IP leaks), создавать свои подобия долгоживущих cookies и др. Также все три (в особенности этим грешит Flash) часто служат подспорищем для эксплуатации каких-нибудь 0-day или 1-day уязвимостей, позволяющих порой проникнуть в саму систему;
JavaScript — исполняется на стороне клиента, не обладает таким широким спектром возможности в плане деанона, хотя может предоставить точную информацию об ОС, виде и версии браузера, а также имеет доступ к некоторым технологиям браузера, которые могут также, например, слить IP-адрес.
Browser fingerprint или отпечаток браузера — совокупность данных, которые браузер постоянно предоставляет серверу при работе с ним, что может сформировать достаточно уникальный «цифровой отпечаток», по которому можно будет найти юзера даже в анонимном сеансе или позже, по выходу из него;
Чем VPN отличается от прокси?
1) Трафик между клиентом и прокси передается в открытом виде, при использовании VPN уже идет шифрование.
2) Стабильность — при создании VPN соединения как правило постоянная, редко создаются разъединения, у прокси они происходят относительно чаще. Но все зависит от провайдера.
3) Кроме шифрования соединения VPN предоставляет более анонимный сервис в том плане, что используются DNS сервера VPN сервиса и не может произойти раскрытия приватных данных типа DNS leak, что ни чуть не хуже, чем раскрытие IP-адресаю Правда у SOCKS5 и SOCKS4a-прокси есть такая же возможность переложить DNS сервис на прокси-сервер.
4) VPN сервисы не ведут журналов или ведут на очень короткие сроки и неподробно (по крайней мере они так говорят), большинство прокси-серверов не дают таких обещаний.
Насколько эффективна цепочка из прокси-серверов?
Скорее она неэффективна, если ориентироваться по соотношению прироста времени деанонимизации на уменьшение скорости соединения от конечного ресурса к клиенту. К тому же, почти все недостатки деанонимизации, присущие прокси-серверам не исчезают при построении из них подобных цепочек. Поэтому можно сделать вывод, что данным методом при достижении анонимности лучше не пользоваться.
В FAQ’e про прокси-серверы не сказано о SOCKS4a, зачем он нужен?
Это промежуточная версия между 4 и 5 SOCKS’ами, в которой все функционирует аналогично 4, за исключением того, что SOCKS4a принимает только доменное имя вместо IP-адреса ресурса и сам его резолвит.
Можно поподробнее об особенностях, плюсах и минусах аренды dedicated-серверов?
Выделенный сервер предназначается далеко не для анонимизации, а для хостинга приложений, сервисов и всего другого, что заказчик посчитает нужным. Важно отметить, что арендатору предоставляется отдельная физическая машина, что дает ему некий гарант полного контроля этого узла и созадет важное преимущество для анонимности — уверенность в том, что история запросов никуда не утечет.
Учитывая вышесказанное и другие моменты можно выделить ряд преимуществ данного средства с точки зрения анонимизации:
1) Настройка HTTP/SOCKS-прокси или SSH/VPN-соединения на выбор.
2) Контроль истории запросов.
3) Спасает при атаке через Flash, Java, JavaScript, если использовать удаленный браузер.
Ну и недостатки тоже присутствуют:
1) Сильно дорогой метод.
2) В некоторых странах априори не может предоставлять анонимность, потому что арендатор обязан предоставить о себе данные: паспорт, кредитка и др.
3) Все соединения с выделенным сервером логируются у его провайдера, так что тут возникает доверенность немного другого плана.
Через какие протоколы идет работа в VPN и какие у них есть особенности?
Лучше сразу рассматривать существующие сейчас варианты VPN, то есть какие связки и технологии предлагают провайдеры, если мы конечно не ставим цель поднять знания теории сетевых протоколов (хотя есть варианты с использованием одного единственного протокола, что мы также рассмотрим).
SSL (Secure Socket Layer) протокол защищенных сокетов — использует защиту данных с открытым ключом для подтверждения подлинности передатчика и получателя. Поддерживает надежность передачи данных за счет использования корректирующих кодов и безопасных хэш-функций. Один из наиболее простых и «низкоанонимных» протоколов для VPN-соединений, используется в основном приложениями-клиентами для VPN. Чаще является частью какой-нибудь связки при создании VPN-соединения.
PPTP (Point-to-Point Tunneling Protocol) — используется наиболее часто, довольно быстрый, легко настраивается, но считается наименее защищённым относительно других своих собратьев.
L2TP (Layer 2 Tunneling Protocol) + IPSec (часто IPSec опускают в названии, как вспомогательный протокол). L2TP обеспечивает транспорт, а IPSec отвечает за шифрование. Данная связка имеет более сильное шифрование, чем PPTP, устойчива к уязвимостям PPTP, обеспечивает также целостность сообщений и аутентификацию сторон. Есть VPN на основе только протокола IPSec или только L2TP, но, очевидно, что L2TP + IPSec дают больше возможностей в защите и анонимизации, чем по отдельности.
OpenVPN — безопасный, открытый, а следовательно, распространённый, позволяет обходить многие блокировки, но требует отдельного программного клиента. Технически это не протокол, а реализация технологии VPN. Проводит все сетевые операции через TCP или UDP транспорт. Также возможна работа через большую часть прокси серверов, включая HTTP, SOCKS, через NAT и сетевые фильтры. Для обеспечения безопасности управляющего канала и потока данных OpenVPN использует SSLv3/TLSv1.
SSTP — такой же безопасный, как и OpenVPN, отдельного клиента не требует, однако сильно ограничен в платформах: Vista SP1, Win7, Win8. Инкапсулирует PPP-кадры в IP-датаграммы для передачи по сети. Для управления туннелем и передачи PPP-кадров данных протокол SSTP использует TCP-подключение (порт 443). Сообщение SSTP шифруется каналом SSL протокола HTTPS.
Отдельно стоит отметить сервисы, предоставляющие такие услуги как «DoubleVPN», когда перед достижением нужного узла траффик проходит 2 разных VPN-сервера в разных регионах. Или существует еще более жесткое решение — «QuadVPN», когда используется 4 сервера, которые пользователь может выбрать сам и расположить в нужном ему порядке.
Какие минусы есть у VPN?
Конечно же, не такая анонимность, как у некоторых других сервисов типа Tor’a, и не только потому, что алгоритм и схема другие. Также при использовании VPN все таки в критических ситуациях придется больше полагаться на добросовестное исполнение обязанностей этого сервиса (минимальное журналирование, работа без бэкапов трафика и пр.).
Следующий момент состоит в том, что хоть VPN и скрывает IP в большинстве случаев, а также предотвращает DNS leak, но есть ситуации, при которых и этот метод анонимизации даст сбой. А именно:
1) IP leak через WebRTC — на хроме и мозилле работает гарантированно и реализовывается через обычный JavaScript.
2) Утечка IP через Flash, инициировавший соединение с сервером и передавший ему IP клиента в обход VPN (правда работает не всегда);
Хотя эти случае можно предотвратить выключив у себя в браузере JS, Flash и Java.
3) При использовании клиентских настроек по умолчанию при разрыве соединения, в отличие от прокси-серверов, серфинг в сети будет продолжаться напрямую, уже не через виртуальный канал, то есть будет полное палево.
Но этого можно избежать подкорректировав таблицу маршрутизации, где в качестве основного шлюза по умолчанию указать только шлюз VPN-сервера или перенастроить файрвол.
В чем различие между SSH-тунелями и VPN?
SSH-туннель ни что иное, как шифруемое по протоколу SSH соединение, где данные шифруются на стороне клиента и расшифровываются у получателя (SSH-сервера). Создается для удаленного защищенного управления ОС, но как уже было написано выше, применяется еще для анонимизации.
Поддерживает 2 варианта работы: посредством реализации приложением HTTP/SOCKS-прокси для направления траффика через локальный прокси-сервер в SSH-туннель. Или происходит создание практически полноценного (можно сказать аналогичного, если брать последние версии SSH и OpenSSH) VPN-соединения.
VPN же разрабатывался в целях обеспечивать защищенный удаленный доступ к ресурсам корпоративных сетей, а следовательно компьютер, подключенный к VPN-серверу становиться частью локальной сети и может пользоваться ее сервисами.
То есть кроме технических мелких аспектов принципы функционирования схожи. А основное отличие состоим в том, что SSH-туннель — это соединение точка-точка, а VPN-соединение — это соединение устройство-сеть (хотя спецы могут и перенастроить по своему усмотрению).
Как работает Tor со стороны клиента?
В сети море вариаций ответов на этот вопрос, но хочу попробовать изложить основы как можно более просто и лаконично, избавив читателя от копания в горах аналитической и сложной информации.
Tor — система маршрутизаторов, доступных только клиентам самого Tor’a, через цепочку которых клиент соединяется с нужным ему ресурсом. При дефолтных настройках количество узлов — три. Tor использует многоуровневое шифрование. Опираясь на эти особенности, можно кратко описать общую схему доставки пакета данных от клиента к запрашиваемому ресурсу через 3 узла (то есть при настройках по умолчанию): предварительно пакет последовательно шифруется тремя ключами: сначала для третьего узла, потом для второго и в конце, для первого. Когда первый узел получает пакет, он расшифровывает «верхний» слой шифра (как при очистки луковицы) и узнаёт, куда отправить пакет дальше. Второй и третий сервер поступают аналогичным образом. А передача зашифрованных данных между промежуточными маршрутизаторами осуществляется через SOCKS-интерфейсы, что обеспечивает анонимность в купе с динамичным переконфигурированием маршрутов. И в отличие от статических прокси-цепочек, конфигурации луковых маршрутизаторов может меняться чуть ли не с каждым новым запросом, что только усложняет деанон.
Какие преимущества и недостатки есть у Tor’a?
Из преимуществ стоит выделить:
1) Один из самых высоких уровней анонимности (при должной конфигурации), особенно в комбинации с другими способами типа VPN.
2) Простота в использовании — скачал, пользуйся (можно даже без особых настроек).
Недостатки:
1) Относительно низкая скорость, так как трафик идет через цепочку узлов, каждый раз происходит расшифровка и может проходить вообще через другой континент.
2) Выходной трафик может прослушиваться, а если не использовать HTTPS, то и прекрасно фильтроваться для анализа.
3) Может не спасти при включенных плагинах — Flash, Java и даже от JavaScript’a, но создатели проекта рекомендуют эти дела отключать.
4) Наличие управляющих серверов.
Если сайт детектит Tor, то я никак не могу зайти на этот сайт анонимным используя его?
Попасть на такой сайт можно двумя способами. При помощи более изощренной схемы, которая де-факто делает это посещение еще более анонимным: связка Tor ⇢ VPN, можно Tor ⇢ Proxy, если не нужна дополнительная анонимность, а только факт сокрытия использования Tor для сервера сайта, но надо использовать именно в этой последовательности. Так получается, что сначала запрос идет через луковые хосты, затем через VPN/Proxy, а на выходе выглядит, как будто просто VPN/Proxy (или вообще обычное соединение).
Но стоит заметить, что взаимодействие этих связок вызывает бурные обсуждения на форумах, вот раздел о Tor и VPN на сайте лукового проекта.
Что следует знать о I2P, и как эта сеть работает?
I2P — распределенная, самоорганизующаяся сеть, основанная на равноправии ее участников, отличающаяся шифрованием (на каких этапах оно происходит и какими способами), переменными посредниками (хопами), нигде не используются IP-адреса. В ней есть свои сайты, форумы и другие сервисы.
В сумме при пересылке сообщения используется четыре уровня шифрования (сквозное, чесночное, туннельное, а также шифрование транспортного уровня), перед шифрованием в каждый сетевой пакет автоматически добавляется небольшое случайное количество случайных байт, чтобы ещё больше обезличить передаваемую информацию и затруднить попытки анализа содержимого и блокировки передаваемых сетевых пакетов.
Весь трафик передается по туннелям — временные однонаправленные пути, проходящие через ряд узлов, которые бывают входящими или исходящими. Адрессация происходит на основе данных из так называемой сетевой базы NetDb, которая распределена в той или иной мере по всем клиентам I2P. NetDb содержит в себе:
RouterInfos — контактные данные роутеров (клиентов), используются для построения туннелей (упрощая, они представляют собой криптографические идентификаторы каждого узла);
LeaseSets — контактные данные адресатов, используются для связи исходящих и входящих туннелей.
Принцип взаимодействия узлов этой сети.
Этап 1. Узел «Kate» строит исходящие туннели. Он обращается к NetDb за данными о роутерах и строит туннель с их участием.
Этап 2. «Boris» строит входной туннель аналогично тому, как и строится исходящий туннель. Затем он публикует свои координаты или так называемый «LeaseSet» в NetDb (здесь отметьте, что LeaseSet передается через исходящий туннель).
Этап 3. Когда «Kate» отправляет сообщение «Boris’у», он запрашивает в NetDb LeaseSet «Boris’а». И по исходящим туннелям пересылает сообщение к шлюзу адресата.
Еще стоит отметить, что у I2P есть возможность выхода в Интернет через специальные Outproxy, но они неофициальные и по совокупности факторов даже хуже выходных узлов Тоr. Также внутренние сайты в сети I2P доступны из внешнего Интернета через прокси-сервер. Но на этих входных и выходных шлюзах высока вероятность частично потерять анонимность, так что надо быть осторожным и по возможности этого избегать.
Какие есть преимущества и недостатки у I2P сети?
Преимущества:
1) Высокий уровень анонимности клиента (при любых разумных настройках и использовании).
2) Полная децентрализация, что ведёт к устойчивости сети.
3) Конфиденциальность данных: сквозное шифрование между клиентом и адресатом.
4) Очень высокая степень анонимности сервера (при создании ресурса), не известен его IP-адрес.
Недостатки:
1) Низкая скорость и большое время отклика.
2) «Свой интернет» или частичная изолированность от интернета, с возможностью туда попасть и повышением вероятности деанона.
3) Не спасает от атаки через плагины (Java, Flash) и JavaScript, если не отключить их.
Какие еще есть сервисы/проекты по обеспечению анонимности?
Freenet — одноранговая сеть распределенного хранения данных.
GNUnet — скоординированный набор софта для peer-to-peer соединения, не нуждающегося в серверах.
JAP — John Donym, в основу взят Tor.
RetroShare — кроссплатформенный софт для бессерверного обмена письмами, мгновенными сообщениями и файлами с помощью шифрованной одноранговой F2F (friend-to-friend) сети.
Perfect Dark — японский клиент под винду для файлового обмена. Анонимность сети Perfect Dark базируется на отказе от использования прямых соединений между конечными клиентами, неизвестности IP-адресов и полном шифровании всего, что только можно.
Следующие 3 проекта особенно интересные тем, что их цель — скрыть пользователя реализуется путем освобождения от провайдерской зависимости при интернет-соединении, за счет построения беспроводных сетей. Ведь тогда интернет станет еще более самоорганизованным:
Byzantium
Netsukuku — Networked Electronic Technician Skilled in Ultimate Killing, Utility and Kamikaze Uplinking.
B.A.T.M.A.N — Better Approach To Mobile Ad-hoc Networking.
Есть ли какие-то комплексные решения по обеспечению анонимности?
Кроме связок и комбинаций различных методов, вроде Tor+VPN, описанных выше можно воспользоваться дистрибутивами линукса, заточенными на эти потребности. Преимущество такого решения в том, что в них уже есть большинство этих комбинированных решений, все настройки выставлены на обеспечение максимального количества рубежей для деанонимизаторов, все потенциально опасные службы и софт вырезаны, полезные установлены, в некоторых помимо документации есть всплывающие подсказки, которые не дадут поздним вечером потерять бдительность.
По своему опыту и некоторых других знающих людей я бы выбрал дистрибутив Whonix, так как он содержит в себе самые новые техники по обеспечению анонимности и безопасности в сети, постоянно развивается и имеет очень гибкую настройку на все случаи жизни и смерти. Также имеет интересную архитектуру в виде двух сборок: Gateway и Workstation, которые в функционируют в связке. Основное преимущество этого состоит в том, что если в результате появления какой-нибудь 0-day в Tor или самой ОС, через которую попробуют раскрыть прятавшегося пользователя Whonix, то будет «деанонимизирована» только виртуальная Workstation и атакующий получит «очень ценную» информацию типа IP 192.168.0.1 и Mac address 02:00:01:01:01:01.
Но за наличие такого функционала и гибкости в настройке надо платить — этим обуславливается сложность конфигурации ОС из-за чего ее порой ставят в низ топа операционок для анонимности.
Более легкие в настройке аналоги — это довольно известные Tails, рекомендованный Сноуденом, и Liberte, которые также можно с успехом использовать в этих целях и которые обладают очень хорошим арсеналом для обеспечения анонимности.
Есть еще какие-нибудь моменты при достижении анонимности?
Да, есть. Существует ряд правил, которых желательно придерживаться даже в анонимном сеансе (если стоит цель достичь практически полной анонимности, конечно) и мер, которые необходимо предпринять перед входом в этот сеанс. Сейчас о них будет написано подробнее.
1) При использовании VPN, Proxy и пр. всегда в настройках устанавливать использование статических DNS-серверов провайдера сервиса, дабы избежать утечек DNS. Или выставлять должные настройки в барузере или межсетевом экране.
2) Не использовать постоянные цепочки Tor, регулярно менять выходные узлы (VPN-серверы, прокси-серверы).
3) При пользовании браузером отключать по возможности все плагины (Java, Flash, еще какие-нибудь Adobe’вские поделки) и даже JavaScript (если задача полностью минимализировать риски деанона), а также отрубать использование cookies, ведение истории, долгосрочного кэширования, не разрешать отправлять HTTP-заголовки User-Agent и HTTP-Referer или подменять их (но это специальные браузеры для анонимности нужны, большинство стандартных не позволяют такую роскошь), использовать минимум браузерных расширений и т. д. Вообще есть еще один ресурс, описывающий настройки для анонимности в различных браузерах, к которому тоже при желании стоит обратиться.
4) При выходе в анонимном режиме в сеть следует использовать «чистую», полностью обновленную ОС с самыми последними стабильными версиями ПО. Чистая она должна быть — чтобы было сложнее отличить «отпечатки» ее, браузера и другого софта от среднестатистических показателей, а обновленная, чтобы понижалась вероятность подхватить какую-нибудь малварь и создать себе определенных проблем, ставящих под угрозу работу всех сосредоточенных для анонимизации средств.
5) Быть внимательным при появлении предупреждений о валидности сертификатов и ключей, для предотвращения Mitm-атак (прослушки незашифрованного трафика).
6) Не допускать никакой левой активности в анонимном сеансе. Например, если клиент из анонимного сеанса заходит на свою страницу в соц. сети, то его интернет-провайдер об этом не узнает. Но соц. сеть, несмотря на то, что не видит реальный IP-адрес клиента, точно знает, кто зашел.
7) Не допускать одновременного подключения к ресурсу по анонимному и открытому каналу (описание опасности было приведено выше).
8) Стараться «обфусцировать» все свои сообщения и другие продукты авторского интеллектуального производства, так как по жаргону, лексике и стиллистике речевых оборотов можно с довольно большой точностью определить автора. И уже есть конторы, которые делают на этом целый бизнес, так что не надо недооценивать этот фактор.
9) Перед подключением к локальной сети или беспроводной точке доступа предварительно менять MAC-адрес.
10) Не использовать любое недоверенное или непроверенное приложение.
11) Желательно обеспечить себе «предпоследний рубеж», то есть какой-то промежуточный узел до своего, через который вести всю активность (как это делается с dedicated-серверами или реализовано в Whonix), чтобы в случае преодоления всех предыдущих преград или заражения рабочей системы третие лица получали доступ к болванке-посреднику и не имели особых возможностей продвигаться в вашу сторону дальше (или эти возможности были бы крайне дороги или требовали затраты очень большого количества времени).
Напоролся на сайте ВВС (это которые British Broadcasting Corporation), а не
на статейку про то, что оштрафованная давеча на 170 миллионов долларов компания Google теперь подозревается еще и в схеме создания скрытых веб-страниц, которые собирают данные о действиях пользователей, и явно не просто так. Но пост не про это, а про то, что в конце статьи авторы предлагают тем, кто хочет узнать, насколько много информации о них утекает через браузер, посетить сайт Panopticklick, который бесплатно тестирует ваш браузер.
Я уже несколько лет пользуюсь браузером Opera и на ноуте, и в мобилах, т.к. считаю его одним из самых защищенных, да к тому же со встроенным VPN и блокировкой рекламы. Еще у меня на ноуте стоят расширения ABP, HTTPS Everywhere и Blur (бывший DNT - DoNotTrack). Ну и стоит на ноуте «голый» Microsoft Edge, без всяких расширений. На нем изредка смотрю, как сайты выглядят без входа под логином, отличаются ли цены без cookies и прочее.
Так вот запустил я на ноуте тест (он быстрый, с полминуты) на этом самом Паноптиклике на обоих браузерах. Результат ниже:
Установил я это расширение Privacy Badger и после нового тестирования на Опере результат стал таким:
Нужно сказать, что запустив тест на мобильной Opera beta без включенного VPN, я получил неутешительные результаты, аналогичные Edge, а после включения VPN, результат такой же хороший, как картинка выше, но без всяких расширений.
Я никого ни к чему не призываю и не рекомендую. Информация дана для размышления. Так-то пофиг, мы ведь с вами не сноудены какие-то.
Ну я заканчиваю, надо бежать, в дверь звонят.
Вряд ли сегодня можно встретить человека, который бы не обменивался интернет-сообщениями: сотни миллионов устройств ежедневно получают десятки миллиардов сообщений по всему миру. Приложения Telegram, WhatsApp, Skype, Viber, ICQ, Facebook, Google Hangouts и около десятка других мессенджеров предоставляют своим пользователям возможности оперативной коммуникации.
Однако вместе с удобством мгновенного обмена информацией обнаруживается проблема конфиденциальности сообщений. Эта дополнительная осторожность может показаться абсурдной, если задуматься о том, сколько информации мы с радостью предоставляем в Интернете ежедневно. Но есть случаи, когда переписка должна быть полностью конфиденциальной без какой-либо третьей стороны, способной запросто ее нарушить.
Сквозное шифрование, или end-to-end encryption (E2EE), считается панацеей от настойчивых попыток хакеров и силовых ведомств ознакомиться с онлайновой перепиской. Смысл E2EE часто сводится к тому, что ключи хранятся только на устройствах собеседников и не попадают на сервер… но это не совсем так. Давай посмотрим, как в действительности обстоят дела с E2EE, на примере популярных мессенджеров.
Шифрование в мессенджерах
Написать эту статью меня подтолкнуло исследование Obstacles to the Adoption of Secure Communication Tools (PDF). Как выяснили его авторы, «подавляющее большинство участников опроса не понимают основную концепцию сквозного шифрования». Проще говоря, люди обычно выбирают мессенджер сердцем, а не мозгом.
Начнем с того, что E2EE имеет свои особенности в каждом мессенджере. В Signal оно почти образцовое. В WhatsApp формально такое же, как в Signal, за исключением одного очень важного момента: смена основного ключа абонента WhatsApp не блокирует отправку ему сообщений. Максимум можно включить бесполезное уведомление (которое отключено в дефолтных настройках). В Viber сквозное шифрование неактивно по умолчанию, да и появилось только в шестой версии. В Telegram E2EE также используется только в секретных чатах, причем реализованы они довольно странно.
Конфликт Роскомнадзора с Telegram вообще создал отличную рекламу последнему. Рядовые пользователи теперь считают творение Дурова настоящей занозой в спине спецслужб (или чуть пониже нее), которые ничего не могут сделать с пуленепробиваемым инновационным сервисом. Поклонники Telegram сравнивают его с Signal и утверждают о превосходстве первого.
Однако в криптографии не бывает чудес, и особенно — в прикладной.
Многие математически красивые идеи оказываются безнадежно испорчены реализацией, когда удобство и подконтрольность ставят выше безопасности и приватности (а так происходит практически всегда).
Исходно в мессенджерах применялся протокол OTR (Off-the-Record). Он использует симметричное шифрование AES в режиме CTR, протокол обмена ключами DH и хеш-функцию SHA-1. Схема AES-CTR обеспечивает так называемое «спорное» (в хорошем смысле) шифрование и возможность отрицания авторства текста, если его перехватят. Всегда можно сослаться на то, что перехвативший трафик сам изменил шифротекст так, чтобы он соответствовал другому варианту расшифровки той же длины. Например, вместо «сходи за хлебом» получилось «отрави королеву» — технически это возможно, и такое свойство специально заложено в алгоритм.
Протокол OTR выполняет аутентификацию собеседников и шифрует переписку между ними. Он безопасен до тех пор, пока участники разговора регулярно проверяют отпечатки открытых ключей друг друга и противостоят атакам по другим векторам (включая социальный инжиниринг).
Главный недостаток OTR заключается в том, что после отправки нового ключа требуется дождаться подтверждения от собеседника. Если он офлайн, то связь будет временно невозможна. Одним из выходов стал алгоритм Double Ratchet (DR), разработанный пять лет назад Тревором Перрином и Мокси Марлинспайком в Open Whisper Systems. Сегодня DR используется в Signal, WhatsApp, Viber и многих других мессенджерах, поддерживающих сквозное шифрование по умолчанию или как отдельную опцию (секретные чаты).
Упрощенная схема алгоритма Double Ratchet (источник: signal.org). Алиса и Боб начинают
сессию, обмениваясь публичными ключами
Сквозное шифрование
Схема E2EE использует комбинацию из криптографических систем с открытым и закрытым ключом. Она очевидна в общих чертах и довольно сложна на уровне деталей. В ней используется масса взаимосвязанных ключей, часть из которых обязательно попадает на сервер и, более того, обязательно загружается на него до начала переписки, чтобы ее можно было начать в произвольный момент. Давай рассмотрим ее подробнее.
Начало схемы ты наверняка знаешь, поскольку оно стандартно для всех систем асимметричного шифрования, — генерируется пара ключей. Это необходимо потому, что криптосистемы с одним ключом (вроде AES) использовать в переписке в чистом виде слишком трудно. С ними пришлось бы как-то организовывать защищенный канал для передачи ключа (например, встречаться лично), а потом делать это снова при каждой его смене.
Тут же все как в привычном PGP: есть два собеседника (Алиса и Боб), каждый из которых генерирует свою пару ключей. Затем они обмениваются публичными ключами, сохраняя в тайне парные им секретные. Публичные ключи передаются по открытому каналу (на то они и публичные, пусть перехватывают на здоровье) и служат для двух целей: они позволяют зашифровать сообщение и проверить его подпись. Соответственно, секретные ключи используются для расшифровки и формирования подписи.
Термин «сообщение» используется здесь в широком смысле. Сообщением может быть текст, медиафайл или служебные метаданные, которыми мессенджер обменивается с сервером. Часть этих данных содержит временные метки, состояние клиентского приложения и новые ключи.
Такая криптосистема кое-как работает в электронной почте, поскольку это сервис для доставки отдельных зашифрованных сообщений произвольной длины. Пользуясь им, собеседники не обязаны одновременно быть онлайн. Все сообщения накапливаются на сервере и скачиваются с него по требованию после того, как пользователь успешно пройдет авторизацию. Расшифровка происходит локально при помощи секретных ключей, которые никуда не передаются. Почта с PGP популярна, но работает далеко не идеально.
К сожалению, в чистом виде схема асимметричного шифрования также не годится для мессенджеров, поскольку эти сервисы ориентированы на интенсивную онлайновую переписку в виде цепочки коротких сообщений. Они должны отображаться в строго определенном порядке, а собеседник может в любое время оказаться офлайн и нарушить структуру диалога.
К тому же шифровать множество коротких сообщений одним ключом — плохая идея. Всего за день переписки их создаются сотни (если не тысячи). Во многих сообщениях количество шифротекста минимальное и предсказуемое (смайлик, стикер). Также у них есть стандартные заголовки, которые упрощают криптоанализ.
Особенность переписки в мессенджерах в том, что из-за типовых метаданных за короткое время атакующий может перехватить большой объем предсказуемого шифротекста.
Его львиная доля будет соответствовать известному открытому тексту. Если она будет шифроваться одним ключом, то при успешной атаке окажутся скомпрометированными все ранее написанные сообщения, и даже те, которые собеседники напишут в будущем.
Чтобы этого не происходило, в мессенджерах предусмотрены такие свойства, как прямая и обратная секретность. Они подразумевают невозможность прочитать отправленные ранее и написанные в будущем сообщения, имея на руках только текущий ключ шифрования. Для этого используется многослойное шифрование с переходом от асимметричной к симметричной криптографии и дополнительные ключи с разным временем жизни.
Диффи, Хеллман! Дайте три!
Из открытой документации известно, что в Telegram аутентифицированное распределение ключей обеспечивает классический протокол Диффи — Хеллмана (DH). Он создает мост между асимметричным (RSA) и симметричным (AES) шифрованием, давая возможность энному количеству собеседников вести зашифрованную переписку, передав только публичные ключи по открытому каналу. Для этого в нем генерируются сессионные ключи, представляющие собой общий секрет или общий эфемерный ключ. Он вычисляется на основе секретного ключа одного собеседника и публичного ключа другого. Эфемерные ключи аутентифицируются долговременными открытыми ключами.
В DH канал передачи может быть не защищен от прослушивания (пассивного наблюдения), но обязан иметь защиту от атаки подмены. Если атакующая сторона может подменить трафик (выполнить активную атаку MITM), то вся схема летит к черту.
Поэтому для своего мессенджера Signal компания Open Whisper Systems использует метод тройного преобразования Диффи — Хеллмана X3DH c Curve25519 (эллиптическая кривая Бернстайна для быстрого DH) или X448. В качестве других криптографических примитивов в X3DH используется HMAC-SHA-256 и AES-256.
Протокол Extended Triple Diffie — Hellman устанавливает общий секретный ключ между двумя сторонами, которые взаимно аутентифицируют друг друга на основе открытых ключей.
Дополнительно ключи сверяются сразу после установки сессии и перед началом передачи сообщений. Это сводит к минимуму риск MITM-атак, делая их очень сложными.
В X3DH используются четыре типа ключей, три из которых постоянно меняются:
IK (identity keys). Секретные ключи, которые создаются один раз и служат основой для формирования всех остальных;
EK (ephemeral key). Эфемерный ключ, который нужен для проверки личности собеседника (без разглашения истинной);
SPk (signed public key, signed proof of knowledge) — по сути, это эфемерный ключ, подписанный секретным. Обычно в мессенджерах он меняется с частотой от одного дня до недели. Иногда вместо времени жизни SPk задают число сообщений, после которого он меняется;
OPK (one-time public key) — одноразовый эфемерный ключ. Он создается отправителем перед установкой сеанса связи и удаляется сразу после успешного «рукопожатия» (handshake).
Наследие Enigma
Смена вспомогательных ключей в X3DH происходит по алгоритму Double Ratchet. Он пришел на смену OTR и ввел понятие цепочки, или пула, ключей. На случай, если собеседник будет офлайн, предусмотрено создание пула OPK. Несколько разовых эфемерных ключей заранее загружаются на сервер и расходуются по мере общения. Это позволяет серверу принимать зашифрованные сообщения, аутентифицируя их отправителя по новой паре ключей, даже когда получатель не в сети. Если пул OPK исчерпан, то сервер использует запасной EK.
Название «двойной храповик» — отсылка к устройству шифровальной машины Enigma с зубчатыми колесиками, которые исключали обратное движение и повторное использование прежних значений. Цифровая аналогия в том, что DR используется для генерирования новых эфемерных ключей, которыми шифруется следующее сообщение (или небольшая порция сообщений). При этом эфемерные ключи гарантированно отличаются, не повторяют предыдущие и не могут быть предсказаны за разумное время атаки.
На X3DH основан протокол TextSecure, который позже был переименован в Signal. В чистом или слегка модифицированном виде протокол Signal используется в одноименном мессенджере, а также в WhatsApp, Viber и других. Разработчики могут давать протоколам собственные названия, но по сути это все тот же X3DH с варьирующимся набором хеш-функций, ГПСЧ и иных криптографических примитивов.
Проблема групповых чатов
Организация групповых чатов в мессенджерах подробно разобрана в свежей статье «More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema» (PDF). Приведу основные выводы из нее.
Наш систематический анализ выявил, что целостность коммуникаций (представленная целостностью всех сообщений) и групповая принадлежность (определяемая возможностью членов группы управлять ими) не имеют end-to-end-защиты.
Кроме того, мы показали, что обратная секретность (ключевое свойство безопасности) не сохраняется при использовании протокола Signal для групповых чатов.
Пояснение: краеугольный камень сквозного шифрования — аутентифицированное распределение ключей по классическому или усиленному протоколу DH. Оно работает только для двух собеседников, формирующих общий секрет. Ожидаемо, что в мессенджерах DH не используется в групповых чатах, а структура обмена сообщениями в них лишена основных криптографических свойств.
Шифрование в групповых чатах. A — отправитель, B — получатель, G — группа пользователей
Странности Telegram
С Telegram все покрыто завесой тайны. О протоколе MTProto 2.0 есть только частичные сведения. Его внешний аудит не выполнялся, а опенсорсная модель Telegram используется в сильно искаженном виде и исключительно с маркетинговыми целями. Ниже я поясню, почему так считаю.
Судя по официальному описанию, все недоставленные сообщения временно (мы надеемся) хранятся на серверах Telegram, которые часто разбросаны по миру и объединены в виртуальное облако. Они синхронизируются между собой, чтобы упорядочить и доставить сообщения одному или нескольким (в случае группового чата) собеседникам в определенном порядке, как только они появятся в сети.
Поэтому шифрование делится на два этапа: на участках клиент — сервер и сервер — сервер
Это обычная схема, но в ней странно то, что прямое соединение клиентов не используется вообще никогда.
В Telegram трафик передается через серверы даже при открытии секретного чата, для которого логичнее было бы сделать P2P-соединение. Напрашивается вывод, что без постоянного использования серверов Telegram связь в этом мессенджере вообще не работает. Другие мессенджеры могут использовать свои серверы только на начальном этапе — для сопоставления текущих IP-адресов собеседников и организации между ними прямого соединения. Telegram так не умеет, и это чертовски похоже на MITM by design.
Почему-то все рассуждения о стойкости MTProto 2.0 крутятся вокруг того, что алгоритм DH надежно защищает от перехвата. Это не так.
Алгоритм Диффи — Хеллмана как раз уязвим для атаки MITM. Более того, в случае Telegram он, вероятно, дополнительно ослаблен на уровне ГПСЧ.
Проблема в том, что клиентское приложение Telegram руководствуется очень невнятной оценкой энтропии. Вместо того чтобы локально генерировать псевдослучайные числа и отсеивать качественные простые, клиент запрашивает их с сервера. Что за ГПСЧ используется на сервере, насколько удачные простые числа он генерирует и нет ли на сервере механизмов избирательной отправки простых чисел с определенными свойствами отдельным клиентам — вопросы без ответа. Клиентское приложение лишь выполняет проверку присланного случайного числа, причем упрощенную, поскольку на тщательный тест prime numbers за разумное время у смартфона банально не хватит вычислительных ресурсов.
Другой частый аргумент в пользу безопасности Telegram — открытые исходники.
Однако в них нет исходного кода серверной части, а код клиентской обычно неактуален. Репозитории Telegram обновляются с большой задержкой (разве что урезанная веб-версия более-менее живая), и в них всегда лежат только старые версии. Нет даже возможности проверить, действительно ли из исходников компилируется то, что сейчас раздается как готовый дистрибутив.
Поэтому говорить про аудит мессенджера фактически бессмысленно. Пока специалисты несколько месяцев копаются в старом коде, выйдет десяток новых версий Telegram, где будут переписаны огромные куски кода. Чтобы сделать уязвимой всю систему шифрования, достаточно замены одного байта — например, одного условного перехода.
Хакатоны, которые устраивает Дуров, не заменят аудит, поскольку ничего не доказывают. В их заданиях создается искусственная ситуация, в которой у атакующей стороны есть только одно зашифрованное сообщение. В реальной жизни таких ограничений нет и для атаки на мессенджер есть множество других векторов.
Тысяча и одна уязвимость
Signal — один из немногих мессенджеров, чей протокол проходил внешний аудит (PDF). Отчет о его результатах очень объемный, поэтому процитирую главные выводы в своем переводе.
Наш анализ показывает, что [протокол] Signal удовлетворяет стандартным криптографическим предположениям и свойствам безопасности. Мы не обнаружили серьезных недостатков в его дизайне, что очень обнадеживает. При реальном использовании Signal остаются неопределенности. Поэтому невозможно сказать, всегда ли [приложение] Signal достигает заявленных целей.
Нужно осознавать, что анализ протокола передачи сообщений — важный этап аудита, но далеко не единственная составляющая безопасности. Любой мессенджер работает в реальной и очень уязвимой среде. Обычно он запускается на не самой свежей версии Android, параллельно с сотней левых приложений (часть из которых наверняка злоупотребляют разрешениями или даже содержат троянские закладки), а сам аккаунт привязан к номеру мобильного телефона.
Огромная брешь заключается в том, что коды подтверждения приходят в SMS.
Их можно перехватить через известную уязвимость в протоколе сотовой связи SS7. Так атакующий получит доступ ко всей переписке, не зная ключей шифрования и даже не пытаясь взломать Signal/Proteus/MTProto/другойсекьюрныйпротокол. Сервер мессенджера сам сменит ключ и услужливо дешифрует последнюю переписку (как минимум, недоставленные сообщения). Даже твои стикерпаки восстановит. Главное же — удобство, верно?
Еще одна зияющая дыра в модели безопасности — push-уведомления.
Без них ты не узнаешь, что тебе пришло сообщение, пока вручную не запустишь мессенджер. С ними ты превращаешь сервер push-уведомлений в легализованного «человека посередине». Например, чтобы в iMessage работали уведомления, он отправляет ключи шифрования на серверы Apple. Уже они выполняют аутентификацию пользователей и (как минимум) дешифровку заголовков сообщений. Восстанови учетку Apple на другом устройстве, и ты получишь все как было — вплоть до переписки и паролей от Wi-Fi. Почти такая же ситуация с серверами Google и Microsoft. Или ты еще веришь в сквозное шифрование с привязкой к номеру мобильного и основному аккаунту на смартфоне?
Проблема небезопасного управления ключами и большой поверхности атаки касается вообще всех мессенджеров.
WhatsApp, Viber и многие другие позволяют создавать копии переписки (в том числе облачные) и не шифруют метаданные (а иногда сам факт разговора важнее его содержания). У Signal дела обстоят чуть лучше, но и его я не считаю идеальным мессенджером по целому ряду причин:
Во-первых, Signal также использует гугловский сервис push-уведомлений. Поэтому на смартфоне без сервисов Google (например, все китайские модели для внутреннего рынка без GApps) он просто не работает.
Во-вторых, для голосового общения в Signal используется закрытый сервер RedPhone.
В-третьих, Signal (как и многие другие мессенджеры) позволяет открыть параллельную сессию на другом устройстве, просто отсканировав QR-код.
В-четвертых, на HITBSecConf2017 рассказали (PDF) про ряд концептуальных проблем Signal и продемонстрировали успешную атаку на него.
XMPPP
Как видишь, сторонним и тем более проприетарным мессенджерам доверять сложно, даже если их рекомендовали Сноуден, Ассанж и EFF. Поэтому некоторые организуют общение через свой мессенджер — с опенсорсом и плагинами. Для простой переписки годится плагин OTR, но он не поддерживает групповые чаты. Есть родственные протоколы mpOTR и GOTR, в которых добавлена эта функция.
Так или иначе, для коллективного общения удобнее использовать открытый протокол XMPP (Extensible Messaging and Presence Protocol), который ранее назывался Jabber. XMPP переводится как «расширяемый протокол обмена сообщениями и информацией о присутствии», это очень емкое название. Открытость означает полную доступность исходных кодов. Ты можешь поднять свой сервер XMPP, ни от кого не зависеть и ничего за это не платить. Также есть уйма готовых серверов и клиентов на любой вкус — например, десктопный Pidgin и Xabber для Android.
Расширяемость подразумевает возможность передачи не только текста, но и данных другого типа, а также добавление разных функций и схем шифрования.
Например, по XMPP легко передать голосовые сообщения, видео и файлы, при желании зашифровав их средствами TLS или PGP. Не так давно на базе XMPP был создан протокол расширения OMEMO, в котором используется тот же DR от Open Whisper Systems, что и в Signal и WhatsApp, но без прочих недостатков последних.
Выводы
В современных мессенджерах заявлена поддержка сквозного шифрования, но часто оказывается, что она реализована со странностями. К тому же в их коде много других дыр, которые были оставлены случайно либо намеренно. Последнее куда вероятнее, если учесть, сколько денег и труда профессионалов было вложено в их разработку. Я стараюсь соблюдать баланс между комфортом и привычным наслаждением паранойей. Использую разные мессенджеры (какие удобнее моим собеседникам), но никогда не веду через них действительно приватных бесед. Для этого есть множество опенсорсных альтернатив. Помимо Xabber, пользователям Android я бы рекомендовал присмотреться к Conversations — свободному XMPP-клиенту с поддержкой OTR, OMEMO, openPGP и SOCKS5.
Больше сливов,мануалов и схем на канале telegram: t.me/dark3idercartel
Статья была подана вам в ознакомительных целях и не как не призывает вас к противоправным действиям.
Спасибо всем, кто ознакомился с этой статьей и поддержал меня в написании моих предыдущих статей !
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.
Локализованный интернет - это наша будущее, и никакие системы анонимизации типа VPN или прокси сервера, в долгосрочной перспективе не помогут.
глушить интернет будут лишь для того, чтобы провоцировать устанавливать сертификат, но стратегического значения это никакого не имеет, возможно таким образом пытаются создать бот-нет сеть для дальнейшей эксплуатации этой сети в рамках каких-то мировых проектов, хотя что мешает провайдерам зарегистрировать самостоятельно своих ботов, используя уже имеющиеся у них базы данных с персональными данными пользователей - непонятно. Понятно лишь одно - бежать некуда.