Атаки на соединения в Tor: как (не)проебать шифрование

[torinmyheart]

Эксклюзивно для

Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.

Это продолжение и развитие темы "

Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.

" (

Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.

)
Ознакомьтесь с первой статьёй, если ещё не читали или успели забыть прочитанное.

Итак, напомню на чём мы остановились.
Bob поднял выходную ноду Tor, запустил свои зловредные алгоритмы и затаился в ожидании жертвы.
Alice заходит в Tor и ощущает себя в полной безопасности, не подозревая, что на неё открыта охота.

Почему защищать DNS-запросы - это бесполезное занятие
В предыдущей статье мы выяснили, что выходная нода Tor видит DNS-запросы и может подменять ответы. Представим, что Alice не послушала мои рекомендации и включила DoH (DNS over HTTPS) в Tor, пожертвовав анонимностью ради лучшей защиты соединения. Что же поменялось?

Ура, теперь выходная нода не сможет подменить IP-адрес!​

Не верно. Действительно, выходная нода не может вмешаться в процесс общения по протоколу DoH и мы получим истинный IP (если только DNS-сервер не был заражён). Однако, сразу после этого следует установка связи с искомым сервером, и тут выходная нода с лёгкостью может направить нас на любой другой IP.

Ура, теперь хотя бы выходная нода не знает какие домены искала Alice, ведь раньше домены передавались DNS-серверу в открытом виде!

Не верно. Действительно, выходная нода не сможет посмотреть какие домены Alice ищет в DNS. Однако, сразу после этого браузер Alice начинает строить HTTPS-соединение. Этот процесс не моментальный, он начинается с обмена данными в открытом виде. В числе других, в открытом виде передаётся заголовок SNI (Server Name Indication), который содержит доменное имя. Bob это видит.
На данный момент (начало 2022 года) заголовок SNI передаётся в открытом виде даже в самой последней версии TLS 1.3. Рабочих способов это исправить пока нет.
Но так будет не всегда...

Спойлер: Как эволюция TLS нагнёт государственную цензуру интернета

Открытый заголовок SNI - это подарок для любого средства интернет-цензуры.

Важные для понимания термины:
Handshake - это процесс "знакомства" сервера и юзера, иными словами, процесс строительства зашифрованного HTTPS-соединения
ClientHello - первый этап процесса handshake, все данные на этом этапе передаются в открытом виде
SNI (Server Name Indication) - заголовок (параметр), который передаётся на этапе ClientHello и содержит искомое доменное имя

О шифровании SNI задумались очень давно, но долгое время поиск решений был безуспешным. Причина кроется в архитектуре handshake: чтобы зашифровать SNI, нужно получить сертификат, а чтобы получить сертификат, нужно отправить серверу SNI. Это замкнутый круг.

Вскоре после выпуска TLS 1.3 придумали ESNI (Encrypted SNI), в тестовом варианте даже завезли поддержку в Firefox. Однако, ESNI быстро исчерпал свой потенциал и имел существенные недостатки. Идея трансформировалась в новую концепцию - ECH (Encrypted ClientHello). Как видно из названия, тут шифрует не только заголовок SNI, а весь этап ClientHello. Пока это эксперементальная технология, но, вероятнее всего, именно она выйдет из черновика и продвинет конфиденциальность в интернете на новый уровень.

ECH подразумевает двойной ClientHello: один открытый, второй внутри первого и уже зашифрованный. Благодаря этому можно скрыть доменное имя и даже истинный IP-адрес сервера с помощью перенаправления в зашифрованном ClientHello. Если сильно упростить: это работает как VPN, встроенный в протокол HTTPS.
DoH + https+ECH - вот только в таком соединении DoH будет работать "в полную силу". Эта технология при массовом распространении способна отправить в музей все DPI разом. И конечно, это даст возможность скрыть от выходных нод Tor информацию о том, каким сайтам вы обращаетесь.

Остаётся только дождаться, когда разработка спецификации ECH будет завершена. Для работы ECH требуется поддержка со стороны серверов, браузеров и даже DNS-серверов, поэтому процесс распространения может затянуться на долгие годы.

Хорошо, что это только размышления и Alice не стала включать DoH в Tor.

Как работает HTTPS
Именно этот механизм отвечает за соответствие домена и сервера. Залезем к нему под капот.

TLS (transport layer security) - протокол для зашифрованнного обмена данными.
SSL - предшественник TLS, его старая версия, считается уязвимой и небезопасной.
HTTP - протокол передачи данных в открытом виде.
HTTPS - расширение протокола HTTP, которое использует SSL (может, но уже не должен) или TLS для шифрования передаваемых данных.

Правильно настроенный HTTPS выполняет две основные задачи:

1. Подтверждает соответствие домена и сервера, чтобы никто, кроме подлинного сервера, не мог вести обмен данными с клиентом.
2. Шифрует данные таким образом, чтобы посредник (внешний наблюдатель) не мог прочитать или изменить их. Шифрование должно обладать прогрессивной секретностью (forward secrecy), что означает:
   • Бесполезно сохранять зашифрованный трафик для дальнейших попыток его расшифровать. Сделать это не подучится благодаря стойким шифрам (алгоритмам шифрования).
   • Утечка секретного ключа (который хранится на сервере) не поможет расшифровать сохранённый ранее трафик. Для этого каждому сеансу генерируется свой ключ.

Сейчас (начало 2022) актуальны только TLS 1.2 и TLS 1.3, они поддерживаются современными браузерами, пути эксплуатации обнаруженных уязвимостей закрываются. Обе версии протокола достаточно безопасны, открытых критических уязвимостей в них сейчас нет. Но отличаются они значительно.

• TLS 1.2
  • Опубликован в 2008 году.
  • Архитектурно похож на TLS 1.1, разработан как улучшенная его версия с целью устранить изъяны безопасности, но сохранить совместимость с устройствами и поддержку широкого списка используемых на тот момент шифров. Это компромисс между безопасностью и совместимостью.
  • По мере развития многие функции обратной совместимости исключались из протокола в угоду безопасности, однако, даже современная версия протокола в наследство получила поддержку устаревших шифров.
  • Браузеры продолжают поддерживать протокол TLS 1.2. Исключаются из поддержки только уязвимые шифры. А для слабых шифров браузеры применяют меры предотвращения атак и смягчения последствий. Протокол TLS 1.2 можно считать безопасным только в сочетании с современным браузером.
• TLS 1.3
  • Опубликован в 2018 году.
  • На предыдущую версию 1.2 совсем не похож. TLS 1.3 - это не улучшение старого протокола, это уже новый протокол.
  • Разработан с упором на безопасность, без сомнительных компромиссов. Не наследует плохие решения от предыдущих версий, поддерживает только безопасные стойкие шифры.
  • Обладает высоким уровнем надёжности, со временем TLS 1.3 станет минимальной безопасной версией протокола.

TLS-сертификат - [упрощённо] сборка, включающая в себя ключ и информацию о сервере, которая обычно подписана третьей стороной (CA, центром сертификации).
CA [ЦА] - центр сертификации, та самая третья сторона. Например, Let’s Encrypt.

За соответствие домена и сервера отвечает TLS-сертификат (то, что обычно именуют HTTPS). Для подтверждения подлинности используется цепочка сертификатов. Объясню упрощённо и наглядно.

Certificate 1/2/3/n - это сам TLS-сертификат сайта.
Intermediate CA, Root CA - это сертификаты, которые принадлежат центрам сертификации.
Далее всю задачу решают два простых условия:

• Центры сертификации, прежде чем подписать Certificate-1/2/3/n, всегда проверяют, что он принадлежит именно владельцу домена.
• Браузеры будут считать Certificate-1/2/3/n подлинным только при наличии подписи от доверенного CA. Список доверенных CA вшит в браузеры.

При установке HTTPS-соединения в открытом виде передаётся только доменное имя. Полный URL передаётся после установления соединения в зашифрованном виде.
Примеры (красное - открыто; зелёное - зашифровано):
https://gnu.org/philosophy/free-sw.html
https://wery-secret-private-site.org/secret-path-to-secret-document-jqakajcoorvxfmghnwm/

Bob атакует Alice
Раздел относится только к доменам клирнета

По случайности Alice сразу попадает на выходную ноду, которую контролирует Bob. Разберёмся что может натворить этот негодяй.

*Tor - имеется в виду обычный Tor-браузер и версия Tor на Whonix. Всё, что написано в данной статье, актуально для обоих браузеров.

	Ситуация​	Методы атаки​	Методы защиты​
1	Alice открывает сайт, не имеющий версии HTTPS. Например: darkseller.org	Обычный MITM (Man In The Middle, человек посередине) в элементарных условиях. Тут нет никакого шифрования, поэтому Bob видит всё: и домен, и полный URL-адрес, и все данные, которыми Alice обменивается с сервером. Всё это Bob может логировать и подменять "налету", незаметно для Alice.	Методов защиты не существует. Не следует использовать сайты по HTTP. В качестве исключения можно посещать такие сайты только с целью прочитать некоторую не важную информацию (статью, анекдот). Нельзя использовать ссылки, счета, кошельки и что-либо, размещённое на сайте. По внешним ссылкам переходить тоже не следует. Рекомендация Во всех браузерах Tor (включая браузер на Whonix) поставить средний уровень безопасности: Открыть about:preferences#privacy (через адресную строку как обычную ссылку), найти заголовок "Security" ("Защита") и установить значение "Safer" ("Высокий"). Помимо прочего, это запретит JS на сайтах без защиты, из-за чего Bob не сможет заставить браузер Alice исполнять его JavaScript код.
2	Alice вводит в адресную строку ссылку без указания протокола Например, так: rutor.biz	Интересная особенность. В этом случае браузер автоматически выбирает протокол HTTP и сперва пытается подключиться без шифрования (есть исключения в виде предзагрузки HSTS, но об это расскажу в другом разделе). Bob может этим воспользоваться: Удалить перенаправление на HTTPS и заставить Alice пользоваться оригинальным сайтом без шифрования (при этом даже не обязательно, чтобы оригинальный сайт поддерживал небезопасный HTTP). В адресной строке будет настоящий домен, но рядом с ним будет иконка с перечёркнутым замком (что может броситься в глаза Alice). В этом случае сценарий переходит к пункту 1. Это называется SSL (TLS) stripping (во времена SSL у этой атаки было больше векторов, но и сейчас она работает). Перенаправить Alice на фишинговый домен. В этом случае подозрительной иконки не будет, будет только немного отличаться домен, но это Alice заметить уже сложнее. Соединение будет зашифровано, но "на том конце" вместо настоящего сервера будет поддельный, которым владеет Bob. Таким образом, Alice открывает настоящий домен, но всё равно попадает на фишинг.	Сохраняя ссылки, всегда следует приписывать к ним протокол. Примеры: Неправильно http://eff.org Тоже неправильно eff.org Правильно https://eff.org И, конечно, копировать ссылку нужно только вместе с протоколом. Не забывайте об этом, когда передаёте ссылку другим людям. Проверьте, чтобы ваши ссылки были сохранены именно в таком формате. Актуально только для ссылок клирнета, к onion не относится.
3	Для реализации этого типа атаки от Alice не требуется никаких действий, она может открывать сайты правильно (как рекомендуется в пункте 2) или просто переходить по ссылкам (ссылка может скрываться под любой кнопкой).	Bob, вмешиваясь в процесс установления соединения, пытается убедить обе стороны (Alice и сервер) использовать устаревшие уязвимые версии протокола TLS (или даже SSL). Если ему это удастся, то формально соединение HTTPS будет установлено, но на деле Bob сможет вскрыть шифрование и прослушивать соединение. Это атака TLS Downgrade. В данном случае браузер Alice настроен именно на HTTPS-соединение, поэтому подложный редирект на HTTP не сработает (Alice получит ошибку установления безопасного соединения, если только браузер не слишком старый). Если TLS Downgrade не удаётся (браузер и/или сервер не поддерживают старые протоколы), Bob может просто препятствовать установлению HTTPS-соединения (цель этого не вполне понятна, но Bob это может).	Браузер и систему нужно держать в актуальном стостоянии, регулярно обновлять. Особенно часто забывают обновлять виртуалки whonix, а ещё чаще забывают обновлять Gateway. Если вы давно не делали этого - сделайте прямо сейчас. Вот команда для whonix и других дистрибутивов семейства debian: sudo apt update && sudo apt upgrade Современный Firefox (и Tor тоже) по-умолчанию не поддерживает старые версии протокола TLS. За это отвечает настройка в конфигах браузера, которую довольно легко случайно сбить, поэтому нужно её проверить: открыть about:config, в поиске ввести security.tls.version.enable-deprecated, значение должно быть false. На сайтах, которые требуют старые версии TLS, вы получите ошибку Никогда не следует нажимать на кнопку "Enable TLS 1.0 and 1.1" ("Включить TLS 1.0 и 1.1"), это сразу переключит security.tls.version.enable-deprecated в небезопасное значение true, после чего придётся вручную возвращать false (и это обязательно). Установить во всех браузерах HTTPS-Only Mode. Раньше для этого было дополнение HTTPS Everywhere, а сейчас его функционал встроен в браузеры на основе Firefox (значит и в Tor). Открыть about:preferences#privacy, пролистать вниз и найти "HTTPS-Only Mode" ("Режим «Только HTTPS»"), переключить его на "Enable HTTPS-Only Mode in all windows" ("Включить режим «Только HTTPS» во всех окнах"). Теперь браузер всегда будет перенаправлять вас на HTTPS, а при попадании на сайты без HTTPS вы будете получать предупреждение "Secure Connection Not Available" ("Защищённое соединение недоступно"). После нажатия кнопки "Continue to HTTP Site" ("Перейти на HTTP-сайт"), браузер больше не будет выдавать предупреждение на этом сайте в текущем сеансе, а вы попадаете в сценарий пункта 1. Пользуйтесь мерами безопасности из этого пункта. Примечание: получив такое предупреждение, попробуйте вручную дописать https:// к адресу сайта, в редких случаях это помогает.
4	Для этой атаки Alice снова не придётся ничего делать. Это не совсем отдельный тип атаки, а скорее пункт 1, но в более сложных обстоятельствах. Alice открывает сайт как положено, по HTTPS, но криворукие разработчики умудрились в коде сайта прописать загрузку некоторых элементов (или отправку данных) по HTTP.	Если сам сайт открывается по HTTPS, это ещё не означает, что остальной контент внутри страницы загружается только по HTTPS. Иногда часть данных сайт может получать/отправлять по HTTP, это называется Mixed content - смешанное содержимое. По визуальным признакам понять что именно загружается без шифрования, невозможно, это может быть всё что угодно: форма с вашим паролем, адрес криптовалютного кошелька, изображение (например, адрес криптовалютного кошелька в qr-коде). На иконке замка в адресной строке может быть восклицательный знак, но не всегда.	От этого типа атак помогает защита из пункта 3, а также рекомендация из пункта 1. Самое главное - включить HTTPS-Only Mode. В таком случае загрузка контента по HTTP блокируется автоматически, а вот попытка что-то отправить на сайт по HTTP сопровождается предупреждением: "Информация, введённая вами на этой странице, будет отправлена по незащищённому соединению и может быть прочитана третьей стороной" ("The information you have entered on this page will be sent over an insecure connection and could be read by a third party"). Рекомендую всегда отменять это действие, иначе вы попадаете в пункт 1.
5	От Alice не требуется совершать никаких ошибок.	Перехват и расшифровка трафика. Подобные атаки можно разделить на два типа: перехват и расшифровка realtime (в реальном времени) при этом расшифровать ранее перехваченный трафик невозможно расшифровка ранее записанного трафика (отсутствие прогрессивной секретности, forward secrecy) В Firefox в целях совместимости отключены ещё не все слабые шифры. Слабыми считаются в основном шифры на CBC (Cipher-Block Chaining, цепочки из защифрованных блоков), поддерживались такие шифры только до TLS 1.2 (включительно). В данном случае слабый - это не обязательно уязвимый. Шифры на CBC считаются слабыми по причине многократного обнаружения в них уязвимостей на одних и тех же механизмах, несмотря на исправления. Cовременный Firefox (и Tor) поддерживает только те шифры на CBC, в которых нет открытых уязвимостей и которые обладают forward secrecy, поэтому прямой угрозы это не несёт. С учётом исторического опыта, шифры на CBC были признаны слабыми, в TLS 1.3 они не поддерживаются. Из уязвимых и доступных для использования в современном браузере Tor я обнаружил только один: 3DES (triple DES). Атака на него называется sweet32 описана здесь: Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки. К тому же, этот шифр, по мнению ssllabs, не обладает forward secrecy. Для реализации атаки требуется выполнить несколько сложных условий, которые в условиях Tor становятся ещё сложнее, но факт самой уязвимости это не отменяет. Bob очень вряд ли сможет успешно проверунть эту операцию, но оставлять для него такую возможность нежелательно.	От любых атак этой категории (в том числе и будущих) наиболее эффективно помогает защита из пункта 3. О проблемах с 3DES также свидетельствует вот этот пост в блоге Mozilla: Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки. Там сказано, что начиная с версии Firefox 93 шифры 3DES по-умолчанию отключены. Это хорошо, но проблема в том, что сейчас (начало 2022) Tor основан на Firefox 91 (esr). Поэтому отключим 3DES самостоятельно... Или нет? После отключения поменяется TLS-отпечаток (TLS Fingerprint) браузера. С одной стороны, без поддетжки 3DES безопасность HTTPS станет выше, а отпечаток будет похож на Firefox 93+. С другой стороны, новый отпечаток будет выделять вас среди дургих пользователей Tor, а реализация атаки маловероятна. Отключать или нет, пусть каждый решит сам. Как выключить шифры 3DES: открыть about:config, ввести в посик security.ssl3.rsa_des_ede3_sha (да, это влияет на TLS 1.2) и установить значение в false. Проверить поддержку 3DES: Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки. (должна быть ошибка защищённого соединения, а если красный экран, значит ваш браузер поддерживает 3DES) Проверить TLS-отпечаток: Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки. После этого в некоторых сообщениях об ошибке (в том числе на сайте с проверкой 3DES) будут кнопка "Restore default settings" ("Восстановить настройки по умолчанию"), не нажимайте на неё, если не хотите возвращать поддержку отключённого шифра. Чтобы отключить вообще все слабые шифры, проще всего поднять минимально допустимую версию TLS до 1.3. Сделать это не сложно, но рекомендовать это и приводить инструкцию я не буду, потому что такая конфигурация даст уже совсем уникальный TLS-отпечаток, от чего больше вреда, чем пользы.
6	Ошибка Alice описана в третьей колонке.	Казалось бы, сбросить или взломать шифрование уже никак не получится. Но ещё не всё потеряно. Bob может прибегнуть к грубой подмене TLS-сертификата. Конечно, поддельный сертификат не пройдёт проверку, о чём браузер Alice выдаст предупреждение (вспоминайте цепочки сертификатов из раздела "Как работает HTTPS"). Но это не остановит заядлых любителей неправильно использовать самоподписные сертификаты, или любителей бездумно следовать любым инструкцим из интернета. Такие люди в два клика пропустят это предупреждение и тогда Bob получит полный контроль над трафиком. Остаётся только надеяться, что Alice из таких. В случае успеха сценарий этой атаки перейдёт на пункт 1, несмотря на наличие HTTPS.	Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки. Вот так это выглядит. Пока Alice видит это предупреждение, она в безопасности. Опасность начнётся только тогда, когда Alice пропустит предупреждение, нажав "Дополнительно" и "Принять риск и продолжить". Виновником такой картины может быть не только Bob. Иногда администраторы сайтов забывают продлевать tls-сертификаты или неправильно настраивают nginx, вследствие чего появляется аналогичное предупреждение. В этой ситуации можно только несколько раз обновить цепочку Tor и если проблема не исчезнет, то лучше всего подождать, пока сайт заработает нормально. А самоподписные сертификаты нужно использовать иначе. Если ваш разработчик говорит вам пропускать предупреждение безопасности, лучше смените разработчика, потому что он не только ставит под угрозу безопасность передачи данных в отдельном конкретном случае, но и вырабатывает у вас вредную привычку.

Разработчики и Bob иногда заодно
В таблице я рассмотрел уязвимости и слабые места как данность, по принципу "надейся только на себя". Но в действительности защиту многих атак по-хорошему должны делать разработчики веб-сервисов.

• Пункт 1
  Думаю, тут без комментариев. В современном мире сайт по HTTP - это открытое неуважение к посетителям.
• Пункт 2
  Чтобы существенно сократить возможность проведения таких атак (независимо от настроек браузера) придумали HSTS. Упрощённо: сервер сам включает в браузере клиента HTTPS-Only Mode, но только для одного своего сайта. Эта настройка сохраняется до полной очистки браузера, поэтому уязвим только самый первый запрос (можно исправить и это через список предустановленных HSTS, но этот метод уже не всем подходит).
• Пункт 3
  И снова правильная настройка сервера закроет возможность атаки. TLS Downgrade может работать только в пределах версий TLS (SSL), которые одновременно поддерживают и клиент, и сервер. Достаточно включить на сервере поддержку только актуальных версий TLS, после чего для атаки Downgrade не будет шансов.
• Пункт 4
  Mixed content - это всегда вина разработчиков.
• Пункт 5
  Как ни странно, и здесь не исключение. Всё аналогично пункту 3, достаточно не включать на сервере поддержку слабых и уязвимых шифров и такой вид атаки будет не страшен.

Но практика показывает, что разработчики иногда встречаются разработчики, которые кладут хер на подобные тонкости или совсем не умеют работать с nginx и бездумно копируют чужие конфиги, даже не понимая что в них написано. Да поможет таким патч Бармина...

Спойлер: Патч Бармина смотреть онлайн

Bob не угомонился

Сайтов ему мало, ведь много всего другого может работать через Tor.

SSH, SFTP

Эти протоколы имеют надёжное шифрование. Но к ним нельзя привязать домен c tls-сертификатом. Как Alice удостоверится в том, что она подключается к настоящему серверу?​

Здесь Alice сама себе центр сертификации.​

При подключении к незнакомому серверу любая программа показывает его отпечаток (fingerprint, обычно вычисленный по алгоримту sha256). В этот момент задача Alice подтвердить подлинность отпечатка или отклонить соединение, если отпечаток не соответствует настоящему. В случае подтверждения отпечаток сохраняется локально (например, для ssh-соединений в файле /home/user/.ssh/known_hosts). При каждом следующем соединении с сервером отпечаток сверяется автоматически. Верефикация Alice потребуется снова только если знакомый сервер вернул незнакомый отпечаток.​

Bob имеет отличную возможность подменить сервер и надеяться на невнимательность Alice.​

Alice, чтобы оставаться в безопасности, достаточно выполнить два простых правила:​

1. При первом подключении к серверу.
   Записать полученный отпечаток (fingerprint, тот, что получен по sha256 (sha2), отпечатком MD5 не стоит пользоваться). Затем отклонить соединение без подтверждения отпечатка, обновить цепочку Tor и соединиться повторно, и так несколько раз. Каждый раз нужно сверять полученный отпечаток с тем, который был скопирован ранее. Подтверждать отпечаток можно только когда он совпал более трёх раз подряд.
2. Если при подключении к уже знакомому серверу появляется верефикация отпечатка, нужно вернуться к первому пункту и выполнить его алгоритм снова. При этом очень желательно разобраться в причинах возникновения такой ситуации, по возможности до подтверждения нового отпечатка.

Если Alice будет действовать строго по этим правилам, Bob не сможет провести успешную атаку даже при первом подключении.​

​

Кстати, а как провести ручную верефикацию сервера без Tor? Никак, остаётся только запрашивать fingerprint у хостера (которые часто не считают нужным их публиковать).​

FTP, FTPS

Да, SFTP и FTPS - это совсем разные протоколы. Если коротко: SFTP - родственник SSH, надёжный; FTPS - родственник FTP, ненадёжный.​

FTP пользоваться категорически запрещено, это устаревший небезопасный протокол без шифрования.​

FTPS поддерживает даже подключение по домену с TLS-сертификатом, но этот протокол всё равно не соответствует стандартам безопасности, от него по возможности лучше отказаться в пользу SFTP.​

XMPP (Jabber)

Это надёжный протокол, если соблюдать следующие правила:​

• Использовать проверенные мессенджеры (например, Gajim, Pidgin, Conversations)
• XMPP поддерживает обмен данными в открытом виде, поэтому в беседах нужно всегда включать шифрование (OMEMO, OTR, PGP)
• Всегда проверять отпечатки (Fingerprint) собеседников.

APT

Это тот случай, когда открытое соединение HTTP не представляет прямой угрозы, потому что передаваемые пакеты подписаны репозиторием. Однако, для сохранения конфиденциальности рекомендую установить и настроить apt-transport-https и apt-transport-tor (Whonix в настройке не нуждается, там это есть из коробки).​

1. sudo apt install apt-transport-https apt-transport-tor
2. Открыть файлы с источниками и прописать на месте протокола tor+https (именно HTTPS, не упустите это из вида):
   Было: deb http://security.debian.org/debian-security ...
   Стало: deb tor+https://security.debian.org/debian-security ...
   Файлы источников: /etc/apt/sources.list и все файлы в директории /etc/apt/sources.list.d/
   А для самых продвинутых (как раз для меня) у Debian есть официальные зеркала в onion:
   Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
   
   Не забудьте, что с onion-доменом протокол должен быть tor+http, вот так:
   deb tor+http://5ajw6aqf3ep7sijnscdzw77t7xq4xjpsy335yb2wiwgouo7yfxtjlmid.onion/debian-security ...

Криптовалютные кошельки

Если использовать официальные кошельки, которые поддерживаются разработчиками криптовалюты, либо кошельки из надёжных источников (например, репозитории Debian), то внешние соединения будут безопасными. Главное случайно (или намеренно) не включить RPC для общения с внешним миром без защиты соединения (по HTTP или HTTPS без проверки сертификата), но такие задачи обычно решают разраотчики, поэтому спрашивать нужно с них. Кстати, для этих целей не обязательно лепить сертификат, можно использовать onion.​

Для кошельков с полной нодой (full node) рекомендую настроить входящие соединения через onion.​

Другие программы и протоколы передачи данных

Тут совсем бардак.​

• Многое зависит от применяемого протокола и алгоритма шифрования. Здесь нет супервайзера в виде браузера, потому могут использоваться устаревшие уязвимые технологии.
• Многие протоколы по-умолчанию не поддерживают шифрование. Например, SMTP, IMAP, VoIP.
• Многие программы используют оппортунистическое шифрование. Это такой метод установки соединения, при котором переключение между защищённым и открытым способом передачи данных может происходить по инициативе любой из сторон. Оппортунистическая модель совсем не обеспечивает защиту, это не многим лучше, чем полное отсутствие шифрования.
• Если программа неправильно использует доступные ей инструменты, это может свести на "нет" всё шифрование. Например, неправильное использование библиотек TLS, или опции -k/--insecure или CURLOPT_SSL_VERIFYPEER=false для curl.

Всё это можно отнести к уязвимостым конкретных приложений.​

Единственная рекомендация - использовать программы из проверенных источников (например, репозитории Debian) и помнить, что открытый код не всегда означает проверенный код.​

Совершенная безопасность "из коробки"

Даже при выполнении всех рекомендаций, механизм HTTPS ещё далёк от совершенства, вот почему:

• Домен передаётся открыто (пока эта проблема не решена)
• Обстоятельства могут вынудить стороны использовать слабое шифрование
• Необходимость доверять третьей стороне в виде CA (центра сертификации), который в теории может подписать поддельный сертификат (например, сотурдничая с государством)
• Невнятный механизм отзыва сертификатов (смотрите сами:
  Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
  )
  Справедливости ради отмечу, что у onion-доменов совсем нет такой процедуры, но там и необходимость в ней меньше

Для Alice есть кое-что получше - onion.
В объяснении принципа работы onion-доменов я допускаю некоторые упрощения, иначе статья получится вдвое больше. Всё сказанное ниже акутально для доменов v3.

В

Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.

объясняя принцип работы onion-доменов я провёл удачную аналогию с криптовалютой, использую её и здесь.

Onion-домен (например, rutorsiteo4ptjypl4dcx3n4gj2z6dkw476ntl26zisur6s3rcdcakqd.onion) - это аналог публичного адреса bitcoin (например, 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa).
У onion-домена, как и у bitcoin-адреса, есть приватный ключ. Приватный ключ onion хранится на сервере.
Чтобы отправить запрос onion-сайту, нужен его публичный ключ (это его адрес ......d.onion). Сделать это может любой, это как отправить bitcoin на конкретный адрес.
А чтобы ответить на запрос, нужен приватный ключ, это может сделать только владелец домена. Это как потратить BTC с конкретного адреса.

Работу всей этой магии обеспечивает сеть Tor. Домены onion не зависят ни от реального IP сервера, ни от DNS.
Так как onion-домен - это просто приватный и публичный ключ, сгенерировать его может кто угодно, это также просто и бесплатно, как сгенерировать адрес bitcoin. Владеет onion-доменом только тот, кто владеет приватным ключом.

Поскольку onion-адрес - это публичный ключ, килент (Alice) может устанавливать безопасное соединение без необходимости доверять третьей стороне. Поэтому onion-домены обладают двумя важнейшии свойствами:

• End-to-end аутентификация (из-конца-в-конец, end-to-end authentication)
  Вместо DNS и подписанных TLS-сертификатов используется распределённая таблица дескрипторов. Механизм работы совсем другой, но в упрощённом представлении можно сказать, что дескрипторы выполняют ту же функцию. Работает это так: сервер подписывает дескриптор приватным ключом и рассылает его на специальне узлы, а клиент на своей стороне проверяет подпись публичным ключом. Это намного лучше, чем TLS-сертификат, потому что тут нет необходимости доверять третьей стороне. Поэтому это и называется end-to-end authentication.
• End-to-end шифрование (end-to-end encryption)
  Пусть вас не смущает протокол HTTP у onion-доменов, это сделано только для совместимости (при прочих равных, HTTPS не сделает onion более безопасным). Соединение по onion-домену использует стойкое шифрование, данные шифруется от браузера к серверу. Ни один узел в цепи Tor не может посмотреть или подменить данные.

Bob в этой схеме не найдёт себе место. Куда бы он не встроился, у него не будет никакой возможности провести атаку на Alice.

Итог
Удивительно, но некоторые люди под влиянием изложенной в двух статьях информации приходят к выводу, что Tor - это очень опасная враждебная среда, рассадник Бобов, каждый из которых одним ловким движением когтистой мохнатой лапы вспарывает любые зашифрованные тоннели. Это интересное, но совершенно ошибочное представление.

Ни одна из описанных атак сама по себе не приведёт к деанонимизации. Против каждой атаки существуют простые и эффективные методы защиты. Помимо этого, TorProject выявляет вредоносную активность и удаляет причастные к ней узлы.
Есть и другие виды атак, направленные на деанонимизацию, но для этого недостаточно владеть выходным узлом и такие атаки очень сложны в реализации. Эта тема не затрагивалась и заслуживает отдельной статьи.

Вся статья написана в контексте атаки со стороны выходных узлов Tor, но сами атаки не имеют никакого отношения к Tor. Каждая из них становится возможной благодаря посреднику (MITM, человеку посередине), который может скрываться в Wi-Fi-роутере, интернет-провайдере, VPN, прокси.

Tor - это лишь один из способов поставить злоумышленника в позицию посредника
Одако, только Tor позволяет сбросить злоумышленника или эффективно противостоять ему.

Если не соблюдать рекомендации из этой статьи, безопасно не будет ни в клирнете, ни в Tor.
Если соблюдать рекомендации из этой статьи, Tor обеспечит лучшую безопасность, чем клирнет или VPN.

Итог подведу так:

• Выполняйте все рекомендации из этой статьи
• Всегда, когда это возможно, используйте onion!

---

Changelog (история редактирования):

• Сразу после публикации
  Добавлена инструкиця по настройке безопасного соединения в APT.

 

[Двуликий]

Ебать,много букв

 

[PANDORA]

Всегда, когда это возможно, используйте onion!

Хороший совет, хорошая статья.

 

[torgeneration]

Как можно запретить браузеру загрузку со сторонних доменов, которые не относятся к запрашиваемому сайту? (скрипты, шрифты стили, изображения)

По дефолту xmpp клиенты соединяются через http или https?
Или зависит от клиента?

Тот же вопрос про кошельки - ноду нужно обязательно пускать через тор, иначе фсб придет и отберет?

 

[misa amane]

По дефолту xmpp клиенты соединяются через http или https?
Или зависит от клиента?

http / https только для сайтов. Клиент чаще всего автоматически выбирают тип соединения, tls в приоритете(это меняется в настройках подключения).

Тот же вопрос про кошельки - ноду нужно обязательно пускать через тор, иначе фсб придет и отберет?

Не знаю 100% как работает сеть, но из вариантов деанонимизации:
после того как ты подписал транзакцию, ты отправляешь ее в сеть. Транзакция попадает к вредоносной ноде(с модифицированным кодом), собирает твой ip и txid транзакции.

 

[Per_Se]

Эх, если б ты перевёл документацию на Whonix, цены б тебе не было! Но это, к сожалению, трудоёмкий процесс.

 

[torinmyheart]

Ебать,много букв

Это я ещё сократил

Как можно запретить браузеру загрузку со сторонних доменов, которые не относятся к запрашиваемому сайту? (скрипты, шрифты стили, изображения)

Отличный вопрос!
Полный запрет нарушит работу многих сайтов и создаст персональный маркер поведения вашего браузера, а смысла в этом не много, поэтому не рекомендую.
Сама возможность запроса - это ещё не проблема. Проблема в запросах с атрибутом withCredentials к сторонним доменам. Иначе говоря, это запросы вместе с cookie и значимыми headers, которые и содержат данные идентификации/авторизации. Случайный сайт не может получить данные авторизации или данные ответа, но сам запрос уйдёт на сервер и будет там обработан, в этом и есть проблема. Последствия:

• CSRF-атака (защиту от этого вида атак должны делать разработчики сайтов).
• Возможность связать между собой одну личность на нескольких разных сайтах в пределах одной сессии браузера (для этого сайты, между которыми можно связать личность, обязательно должны работать сообща).

Однако, браузер Tor эту проблему решает. Атрибут withCredentials ведёт себя так, будто данных авторизации нет, как в приватном окне.
В Firefox для аналогичного поведения нужно включить специальную настройку: about:preferences#privacy > Enhanced Tracking Protection (Улучшенная защита от отслеживания) > Custom (Персональная) > Cookies (Куки) > установить All third-party cookies (may cause websites to break) (Все сторонние куки (может нарушить работу веб-сайтов)). Но это влияет только на куки, headers по-прежнему будут передаваться, поэтому в Firefox лучше использовать приватные окна и почаще чистить всю историю.

Наглядная демонстрация:

1. Открыть
   Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
   
   Нажать F12 (панель разработчика), открыть вкладку Network (Сеть).
   Сайт test-cors на этой вкладке нужен для того, чтобы делать запросы к другим доменам и смотерть на результат.
2. Проверяем cookies
   • Открыть в новой вкладке
     Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
     . Нажать F12, открыть вкладку Network (Сеть).
     Промотать страницу до раздела With Authentication Credentials и нажать на кнопку Make Request под этим заголовком. В панели разработчика появится запрос, нужно нажать на него и справа открыть вкладку Cookies (Куки), там будет ID сесии. При повторном нажатии на Make Request в новых запросах будет такой же ID сессии.
   • Вернуться test-cors из пункта 1. В поле Remote URL вставить: https://cors-server.digi.ninja/with_creds_allowed.php, нажать на кнопку Send Request. Здесь же нажать на запрос в панели разработчика и открыть Cookies (Куки). ID сессии должен отличаться от ID в вкладке c test-cors, а при каждом новом нажатии Send Request должен быть новый ID сессии.
3. Проверяем headers
   • Открыть в новой вкладке
     Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
     , ввести логин: foo, пароль: bar.
   • Вернуться к вкладке с test-cors из пункта 1. В поле Remote URL вставить: https://httpbin.org/basic-auth/foo/bar, нажать Send Request. Результат будет в панели разработчика:
     Код ответа 200 - плохо, заголовок отправляется
     Код ответа 401 или появляется форма аваторизации - хорошо, заголовок не отправился

По дефолту xmpp клиенты соединяются через http или https? Или зависит от клиента?

XMPP - это и есть протокол. Он поддерживает открытую и зашифрованную передачу данных, поэтому нужно не забывать включать шифрование в беседе.

Тот же вопрос про кошельки - ноду нужно обязательно пускать через тор, иначе фсб придет и отберет?

Поднимать ноду не противозаконно (пока), но в целях сохранения конфиденциальности кошелёк действительно лучше направить в Tor. Если хотите разрешить входящие соединения и при этом сохранить в тайне ваш IP, настройте входящие на onion-адрес.

Эх, если б ты перевёл документацию на Whonix, цены б тебе не было! Но это, к сожалению, трудоёмкий процесс.

Да уж, много времени займёт, но идея интересная

 

[Per_Se]

Да уж, много времени займёт, но идея интересная

Я только за. Офигительно было бы, если бы был целый аналогичный, русскоязычный сайт по Хуниксу.

 

[kuygui]

Пользуйтесь настройками по умолчанию, зачем целые мемуары писать ни о чём?

Хороший совет, хорошая статья.

Чем больше используешь onion, тем больше шансов тебя вычислить.

 

[Алюминевый Кейс]

Чем больше используешь onion, тем больше шансов тебя вычислить.

Чем больше фалоэмитатор в попе, тем больше натурал. Так ты считаешь?

Да кстати, пользуйся настройками по умолчанию на винде, везде вводи только свой номер/почту, а на аву селфи с паспортом.

 

[Nahema5]

Автору выплату.

Поддерживаю)

 

[Gypsy Quarter]

Поддерживаю)

И я +

 

[GIVENCHY]

Максимально информативно)
Кто шарит и нуждается - воспользуется, не гундите)

 

[_Frosty_]

дак что лучше в торе включать для всех HTTPS или наоборот отключать ?

 

[Silk Road User]

Очень объемная и информативная статья, благодарю автора.

ТС, вопрос немного не по теме, но что думаешь об эффективности разрыва цепочки отправитель-получатель с помощью промежуточного прокси узла, который создает Tor цепочки. Действительно ли это затрудняет детект пакетов и внушительно улучшает защиту? Или промежуточный сервер с MultiPathTCP — это панацея в этом вопросе? Ведь насколько я знаю, в таких соединениях даже перестроение Tor цепей не обрывает основную TCP- сессию.

Думаю я, да и многие участники форума были бы признательны любому вашему топику. Успехов.

 

[_Frosty_]

Тс , а что лучше запрашивать мосты в тор , или самому прописать? или прокси на тор?

 

[_Frosty_]

Что-то все на потом статью оставляют

не хотят щас читать , хотят потом прочитать)))

 

[torinmyheart]

---

Признателен всем за благодарности и вопросы​

---

_Frosty_​

дак что лучше в торе включать для всех HTTPS или наоборот отключать ?

Конечно включать режим HTTPS для всех сайтов. И у вас в подписи в ссылке нужно поменять http на https.
Рекомендую вам ещё раз перечитать третью колонку в таблице, там собраны готовые реокмендации.

Тс , а что лучше запрашивать мосты в тор , или самому прописать? или прокси на тор?

Если в вашей стране не блокируют Tor и вы решили использовать мосты, то лучше их запрашивать автоматически, хотя бы потому что это удобней.
Если в вашей стране блокируют Tor, то автоматический запрос мостов стоит оставить только до тех пор, пока он работает. Вероятнее всего, вскоре после блокировки он работать перестанет и вам придётся получать мосты вручную.
Главный минус ручного ввода мостов в том, что их нужно самостоятельно проверять на работоспособность.
Вот тут ещё пара слов по этой теме:

Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.

---

Silk Road User​

ТС, вопрос немного не по теме, но что думаешь об эффективности разрыва цепочки отправитель-получатель с помощью промежуточного прокси узла, который создает Tor цепочки. Действительно ли это затрудняет детект пакетов и внушительно улучшает защиту? Или промежуточный сервер с MultiPathTCP — это панацея в этом вопросе? Ведь насколько я знаю, в таких соединениях даже перестроение Tor цепей не обрывает основную TCP- сессию.

Не очень понял какую схему вы имеете в виду, но постараюсь ответить.
Для новой сессии Tor Browser я рекомендую после нажатия на соответствующую кнопку ("Новая личность") закрыть и открыть браузер повторно.
Предполагаешь поставить промежуточный прокси-сервер до тора и заставить его генерировать рандомные коннекты через tor? Получится некоторый спам для затруднения атаки на концы цепи.
Если речь об этом, то генерировать рандомные запросы нужно от рабочей машины без всяких промежуточных серверов, потому что суть такого спама в том, чтобы он исходил именно из начальной точки, тогда её труднее всего будет сопоставить с конечной.
Атаки на концы цепи и защита от них - это большая тема для отдельной статьи.
Можем продолжить обсуждение в ЛС, если есть вопросы.

 

[Noblesse Oblige]

Побольше бы таких познавательных тем для наших форумчан! Автор красавчик.