Атаки на соединения в Tor: как работает HTTPS и как не сделать его бесполезным

Это продолжение и развитие темы "Как работает DNS в Tor и почему попытки его улучшить сделают только хуже"

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

Итак, напомню на чём мы остановились.
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. Рабочих способов это исправить пока нет.

Но так будет не всегда...

Открытый заголовок 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. Всё, что написано в данной статье, актуально для обоих браузеров.

Разработчики и 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: https://onion.debian.org/
   Не забудьте, что с 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 (центра сертификации), который в теории может подписать поддельный сертификат (например, сотурдничая с государством)
• Невнятный механизм отзыва сертификатов (смотрите сами: https://revoked.badssl.com)
  Справедливости ради отмечу, что у onion-доменов совсем нет такой процедуры, но там и необходимость в ней меньше

Для Alice есть кое-что получше - onion.

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

Onion-домен (например, rutordeepkpafpudl22pbbhzm4llbgncunvgcc66kax55sc4mp4kxcid.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!

Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!