- Сообщения
- 76
- Реакции
- 215
Эксклюзивно для
Это продолжение и развитие темы "
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
" (
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
)Ознакомьтесь с первой статьёй, если ещё не читали или успели забыть прочитанное.
Итак, напомню на чём мы остановились.
Bob поднял выходную ноду Tor, запустил свои зловредные алгоритмы и затаился в ожидании жертвы.
Alice заходит в Tor и ощущает себя в полной безопасности, не подозревая, что на неё открыта охота.
Почему защищать DNS-запросы - это бесполезное занятие
В предыдущей статье мы выяснили, что выходная нода Tor видит DNS-запросы и может подменять ответы. Представим, что Alice не послушала мои рекомендации и включила DoH (DNS over HTTPS) в Tor, пожертвовав анонимностью ради лучшей защиты соединения. Что же поменялось?
Не верно. Действительно, выходная нода не может вмешаться в процесс общения по протоколу DoH и мы получим истинный IP (если только DNS-сервер не был заражён). Однако, сразу после этого следует установка связи с искомым сервером, и тут выходная нода с лёгкостью может направить нас на любой другой IP.
Не верно. Действительно, выходная нода не сможет посмотреть какие домены Alice ищет в DNS. Однако, сразу после этого браузер Alice начинает строить HTTPS-соединение. Этот процесс не моментальный, он начинается с обмена данными в открытом виде. В числе других, в открытом виде передаётся заголовок SNI (Server Name Indication), который содержит доменное имя. Bob это видит.
На данный момент (начало 2022 года) заголовок SNI передаётся в открытом виде даже в самой последней версии TLS 1.3. Рабочих способов это исправить пока нет.
Но так будет не всегда...
Открытый заголовок 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-серверов, поэтому процесс распространения может затянуться на долгие годы.
Важные для понимания термины:
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, которое использует
Правильно настроенный HTTPS выполняет две основные задачи:
- Подтверждает соответствие домена и сервера, чтобы никто, кроме подлинного сервера, не мог вести обмен данными с клиентом.
- Шифрует данные таким образом, чтобы посредник (внешний наблюдатель) не мог прочитать или изменить их. Шифрование должно обладать прогрессивной секретностью (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.htmlhttps://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 может этим воспользоваться:
| Сохраняя ссылки, всегда следует приписывать к ним протокол. Примеры: Неправильно 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 это может). |
|
| 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 не требуется совершать никаких ошибок. | Перехват и расшифровка трафика. Подобные атаки можно разделить на два типа:
В данном случае слабый - это не обязательно уязвимый. Шифры на 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, достаточно не включать на сервере поддержку слабых и уязвимых шифров и такой вид атаки будет не страшен.
Bob не угомонился
Сайтов ему мало, ведь много всего другого может работать через Tor.
SSH, SFTP
Эти протоколы имеют надёжное шифрование. Но к ним нельзя привязать домен c tls-сертификатом. Как Alice удостоверится в том, что она подключается к настоящему серверу?
Здесь Alice сама себе центр сертификации.
При подключении к незнакомому серверу любая программа показывает его отпечаток (fingerprint, обычно вычисленный по алгоримту sha256). В этот момент задача Alice подтвердить подлинность отпечатка или отклонить соединение, если отпечаток не соответствует настоящему. В случае подтверждения отпечаток сохраняется локально (например, для ssh-соединений в файле
/home/user/.ssh/known_hosts). При каждом следующем соединении с сервером отпечаток сверяется автоматически. Верефикация Alice потребуется снова только если знакомый сервер вернул незнакомый отпечаток.Bob имеет отличную возможность подменить сервер и надеяться на невнимательность Alice.
Alice, чтобы оставаться в безопасности, достаточно выполнить два простых правила:
- При первом подключении к серверу.
Записать полученный отпечаток (fingerprint, тот, что получен по sha256 (sha2), отпечатком MD5 не стоит пользоваться). Затем отклонить соединение без подтверждения отпечатка, обновить цепочку Tor и соединиться повторно, и так несколько раз. Каждый раз нужно сверять полученный отпечаток с тем, который был скопирован ранее. Подтверждать отпечаток можно только когда он совпал более трёх раз подряд. - Если при подключении к уже знакомому серверу появляется верефикация отпечатка, нужно вернуться к первому пункту и выполнить его алгоритм снова. При этом очень желательно разобраться в причинах возникновения такой ситуации, по возможности до подтверждения нового отпечатка.
Если 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 в настройке не нуждается, там это есть из коробки).sudo apt install apt-transport-https apt-transport-tor- Открыть файлы с источниками и прописать на месте протокола tor+https (именно HTTPS, не упустите это из вида):
Было:debhttp://security.debian.org/debian-security ...
Стало:debtor+https://security.debian.org/debian-security ...
Файлы источников:/etc/apt/sources.listи все файлы в директории/etc/apt/sources.list.d/
А для самыхпродвинутых (как раз для меня) у Debian есть официальные зеркала в onion:Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
Не забудьте, что с onion-доменом протокол должен быть tor+http, вот так:
debtor+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-доменов совсем нет такой процедуры, но там и необходимость в ней меньше
В объяснении принципа работы 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.
Последнее редактирование:
Но это, к сожалению, трудоёмкий процесс. 
