Нет, к сожалению не поможет, это то же самое что datacompboy предлагает выше. К тому же, с точки зрения реализации, это классическая атака slow read, она приведет к увеличению потребления ресурсов на entry node.
В случае двуглавого орла получатель ID это оборудование СОРМ, в случае других орлов — его аналоги. Т.е. если спецслужбы захотят знать, кто посещает, например, сайты определенной тематики, им достаточно промаркировать часть трафика от этих сайтов вблизи этих сайтов (если они на подконтрольной территории) или на exit node'ах и на оборудовании отслеживать получателей маркировки. Там где маркировка вошла и не вышла — там и конечный получатель.
Затрудняет, но все-такие не решает: атакующему придется использовать более явные бёрсты трафика и более длительные тайминги между ними, т.е. «передавать данные» между двумя своими точками на меньшей скорости с большей амплитудой.
Да, но к сожалению, только в том случае, если у атакующей стороны нет возможности получить контроль над сервером или контролировать трафик где-то ближе к серверу.
Как видно выше — рамеры фиксированные, но есть как минимум два разных размера блобов, 3648 и 560.
Специально против скрытых сервисов не пробовал, но не вижу причин, почему она не могла бы быть проведена, можно «модулировать» данные запроса от клиента к серверу.
Подозреваю, что на практике эта атака уже может использоваться, но, возможно, это просто моя паранойя. Отследить атаку очень сложно, особенно если не используются слишком заметные шаблоны. Если немного сдвинуть тайминги, то полученная картинка будет гораздо менее заметна на глаз, хотя будет нисколько не хуже определяться алгоритмически.
С lynx ситуация интересная. Теоретически, отследить может быть возможным. lynx «выкинет» из трафика часть данных (теги, служебную информацию), но в целом, он передаст данные дальше в ssh-соединение. Но здесь могут иметь значение детали, например верстка HTML на таблицах может задерживать их отображение, в данном случае это критично. + через любой прикладной шлюз, включая и такой не пройдет невидимая атака, надо модулировать реальные данные.
Насколько я знаю, подтвержденной информации нет, но разработчики tor предполагают, что речь идет об атаке через relay-early cells, CVE-2014-5117, т.к признаки этой атаки были обнаружены «вживую».
Любая технология начинается как хак. Если бы не люди, которые разбивались на фанерных крыльях, носили радий в карманах, обжигали пальцы паяльником в гараже и портили глаза, то не было бы и новых технологий.
Да, все так, в этом плане XSS это действительно в какой-то степени эквивалент доступа к сессии пользователя (не важно, с кукой или без), на то время, пока открыта вкладка.
Если по пунктам:
1й — не получится из-за X-Frame-Options на главной странице.
2й — shell of the future не обходит ограничения HTTPOnly, это реверс-шел на JS и имеет доступ только к тому, к чему имеет доступ JS. JS не имеет доступа к HTTPOnly кукам. Кроме того, загрузить внешний скрипт на наших основных проектов может быть немного сложно из-за CSP (Content Security Policy).
3й — НО, даже если полуилось загрузить скрипт и даже если бы скрипт имел доступ к кукам на главной странице, для того, чтобы получить доступ к сессии электронной почты, не достаточно куки с главной страницы, это как раз заслуга разделения сессий. Чтобы получить доступ к электронной почте, XSS должен быть именно в электронной почте.
Это почти тот же интересный и правильный вопрос, что обсуждался чуть выше, про то, что не проще ли внедрить принудительный https. Таким образом vk.com решается проблему относительно безопасного использования сессионных кук на небезопасном сайте без поддержки . Это в общем-то костыль, решение не надежно — если у вас в интернет-кафе отснифили привязанную к IP куку, то пока вы сидите в кафе и даже когда вы из кафе уходите, у похитителя остается доступ к сайту вместе с вашим прошлым IP адресом. Конечно, через некоторое время эта сессия проэкспайрится, но до тех пор ваш эккаунт доступен.
В почте Mail.Ru эта проблема решается именно путем принудительного https и HSTS, что гораздо надежней. vk.com уже внедряет https на добровольной основе и, надеюсь, в итоге придет к тому же решению с принудительным https + HSTS.
В этой же статье описывается решение несколько другой проблемы, с которой ВКонтакте пока не приходилось сталкиваться: это наличие в рамках одного домена второго уровня большого количества разных проектов, между которыми разделяется общая аутентификация пользователя. Требуется, чтобы ошибка в менее критическом проекте, например флеш-открытке с котиками, не затрагивала безопасность критических проектов, например ПочтыMail.Ru.
Вы заблуждаетесь относительно tor. Обычно для проведения MitM требуется доступ к физической среде передачи данных, эта атака трубет «близости» к пользователю. В случае tor трафик пользователя идет через exit node. В качестве exit node может выступать любой желающий с любыми намерениями. Например, Вы можете у себя поднять exit node и снифить пароли пользователя/авторизационные куки. Улов будет очень высоким, порядка 500-1000 в сутки на достаточно быстром канале.А если подменять сертификат для SSL-соединений — то еще больше.
Это одна из причин, почему tor ни в коем случае не следует использовать при повседневном браузинге — он снижает безопасность среднестатистического пользователя, а не повышает ее.
Принудительный HTTPS (перенаправление + HTTP Strict Transport Security) обязательно нужен на критичных проектах, но он не отменяет необходимости реализовывать разделение сессий, потому что:
Без разделения сессий компрометация одного из проектов приведет к компрометации всех проектов. В качестве примера можно привести Heartblead. Несколько проектов у нас были поддвержены этой атаке. По счастью, почту и центр авторизации «пронесло». Это как раз тот случай, когда нас спасло разделение сессий, т.к. компрометация второстепенных проектов не привела к компрометации учетных записей пользователей и почты.
Если у кук нет флажка HTTPOnly, то XSS приводит к угону сессии, наличие https никак не влияет на это
HTTP Strict Transport Security работает не во всех браузерах + не работает, когда пользователь долго не заходил на сайт.
Если у куки нет флажка Secure, то MitM все равно может угнать куку, заставив пользователя посетить незащищенный сайт, т.к. в запросе на незащищенный сайт кука будет присутствовать. Принудительный HTTPS в данном случае тоже не спасет.
Т.е. надо использовать И принудительный https И разделение сессий.
Не очень правильно организовывать некую анонимность ради анонимности. Любые меры, которые вы предпринимаете, не должны быть абстрактными, они должны решать конкретную задачу. Мне не очень понятно, какую именно задачу вы хотите решить внедряя tor для доступа к ящику электронной почты. В большинстве сценариев то, что вы предлагаете сделать, негативно влияет на безопасность как tor так и электронной почты, т.к. пуская трафик через tor, вы всегда даете доступ к нему недоверенной стороне, открывая возможности Man-in-the-Middle. Использовать tor для электронной почты без очень веских на то причин я бы не рекомендовал. SSL не самая надежная защита трафика, она достаточна только для самых общих задач. Доступ через tor не дает никаких дополнительных преимуществ по сравнению с прямым доступом к почтовому серверу, который скрывает IP-адрес отправителя письма, но добавляет дополнительные риски.
vk.com действительно самый посещаемый сайт рунета, но не портал. Mail.Ru это не только главная страница или почта — это несколько сотен проектов. Месячная аудитория портала Mail.Ru – 59 млн. Для сравнения: ВКонтакте, — 52,1 млн (TNS, все население России в возрасте от 12 до 64 лет, март 2014 г.) и он только третий.
В mail.ru когда-то использовался похожий подход, но отказались от него довольно давно, хотя для многих проектов он вполне пригоден. Единственное замечание — с точки зрения разделения доступа использование симметричного ключа является ошибкой, т.к. ключ компрометируется при компрометации любого хоста. Правильно использовать ассиметричную криптографию или комбинацию.
Но у такого подхода есть и свои недостатки, например, достаточно сложно завершить сеанс пользователя на всех проектах одновременно.
Правильно сделать так, чтобы код, который обслуживает запросы пользователей, и код, который производит авторизацию запросов и работает с эккаунтами пользователями были изолированы друг от друга. Изоляция может быть в рамках одной машины, если это небольшой проект — разнести его по разным виртуальным хостам, системным эккаунтам, возможно, виртуальным машинам. В случае двух сильно удаленных хостов с негарантируемой связью это единственный вариант. Если проект большой — то чем больше уровней изоляции — тем лучше — т.е. желательно разносить не просто по разным виртуальным хостам, системным эккаунтам — но и по разным физическим машинам и сегментам сети.
Если вопрос о том, как безопасно связать 2 сервера — то ответ: через VPN.
Специально против скрытых сервисов не пробовал, но не вижу причин, почему она не могла бы быть проведена, можно «модулировать» данные запроса от клиента к серверу.
Подозреваю, что на практике эта атака уже может использоваться, но, возможно, это просто моя паранойя. Отследить атаку очень сложно, особенно если не используются слишком заметные шаблоны. Если немного сдвинуть тайминги, то полученная картинка будет гораздо менее заметна на глаз, хотя будет нисколько не хуже определяться алгоритмически.
С lynx ситуация интересная. Теоретически, отследить может быть возможным. lynx «выкинет» из трафика часть данных (теги, служебную информацию), но в целом, он передаст данные дальше в ssh-соединение. Но здесь могут иметь значение детали, например верстка HTML на таблицах может задерживать их отображение, в данном случае это критично. + через любой прикладной шлюз, включая и такой не пройдет невидимая атака, надо модулировать реальные данные.
1й — не получится из-за X-Frame-Options на главной странице.
2й — shell of the future не обходит ограничения HTTPOnly, это реверс-шел на JS и имеет доступ только к тому, к чему имеет доступ JS. JS не имеет доступа к HTTPOnly кукам. Кроме того, загрузить внешний скрипт на наших основных проектов может быть немного сложно из-за CSP (Content Security Policy).
3й — НО, даже если полуилось загрузить скрипт и даже если бы скрипт имел доступ к кукам на главной странице, для того, чтобы получить доступ к сессии электронной почты, не достаточно куки с главной страницы, это как раз заслуга разделения сессий. Чтобы получить доступ к электронной почте, XSS должен быть именно в электронной почте.
И кстати, у нас есть программа поиска уязвимостей, за XSS в почте мы платим около $500, присоединяйтесь.
В почте Mail.Ru эта проблема решается именно путем принудительного https и HSTS, что гораздо надежней. vk.com уже внедряет https на добровольной основе и, надеюсь, в итоге придет к тому же решению с принудительным https + HSTS.
В этой же статье описывается решение несколько другой проблемы, с которой ВКонтакте пока не приходилось сталкиваться: это наличие в рамках одного домена второго уровня большого количества разных проектов, между которыми разделяется общая аутентификация пользователя. Требуется, чтобы ошибка в менее критическом проекте, например флеш-открытке с котиками, не затрагивала безопасность критических проектов, например ПочтыMail.Ru.
Это одна из причин, почему tor ни в коем случае не следует использовать при повседневном браузинге — он снижает безопасность среднестатистического пользователя, а не повышает ее.
Принудительный HTTPS (перенаправление + HTTP Strict Transport Security) обязательно нужен на критичных проектах, но он не отменяет необходимости реализовывать разделение сессий, потому что:
Если у куки нет флажка Secure, то MitM все равно может угнать куку, заставив пользователя посетить незащищенный сайт, т.к. в запросе на незащищенный сайт кука будет присутствовать. Принудительный HTTPS в данном случае тоже не спасет.
Т.е. надо использовать И принудительный https И разделение сессий.
Но у такого подхода есть и свои недостатки, например, достаточно сложно завершить сеанс пользователя на всех проектах одновременно.
Если вопрос о том, как безопасно связать 2 сервера — то ответ: через VPN.