id: Гость   вход   регистрация
текущее время 00:39 29/03/2024
Владелец: unknown (создано 30/07/2014 20:57), редакция от 31/07/2014 10:27 (автор: SATtva) Печать
Категории: криптография, софт, анонимность, приватность, анализ трафика, протоколы, прослушивание коммуникаций, tor, уязвимости, атаки
http://www.pgpru.com/Новости/2014/УведомлениеОДеанонимизацииОператоровИПользователейСкрытыхСервисовTor
создать
просмотр
редакции
ссылки

30.07 // Уведомление о деанонимизации операторов и пользователей скрытых сервисов Tor

Общие сведения


4 июля 2014 нами была обнаружена группа узлов, которые, как мы предполагаем, пытались деанонимизировать пользователей. Они пытались выделить людей, которые заходили на скрытые сервисы Tor или управляли ими. Атака включала в себя модификацию заголовков протокола Tor для реализации варианта атаки подтверждения.


Атакующие узлы стали присоединяться к сети 30 января 2014 года и мы удалили их из сети 4 июля. Поскольку мы не знаем, когда они начали проводить атаку, пользователи, администрировавшие или посещавшие скрытые сервисы с начала февраля по 4 июля, могут считать, что они были под угрозой.


К сожалению, до сих пор неясно, в чём заключается эта «угроза». Мы знаем, что атака основывалась на поиске пользователей, скачивающих дескрипторы скрытых сервисов, но скорее всего атакующие не могли видеть никакого трафика уровня приложений (например, какие страницы скачивались или даже какие пользователи посещали находящийся под прицелом скрытый сервис). Атака вероятно также пыталась выявить тех, кто публиковал дескрипторы скрытых сервисов, что позволило бы атакующему определить местоположение этих скрытых сервисов. В теории эта атака могла бы также быть использована и для вычисления местоположения пользователей обычных цепочек Tor, но мы не нашли доказательств того, что злоумышленники оперировали хотя бы на каких-то исходящих узлах, что делает такой вариант атаки маловероятным. Наконец, мы не знаем сколько данных собрали атакующие и судя по способу её выполнения (см. детали далее), их метод модификации заголовков протокола мог помогать деанонимизировать пользователей и другим атакующим.


Узлы должны обновиться до текущей версии Tor (0.2.4.23 или 0.2.5.6-альфа) для закрытия специфической уязвимости протокола, использованной атакующими — но стоит помнить, что предотвращение атак подтверждения трафика в общем случае остаётся открытой проблемой для исследования. Клиенты должны обновиться по мере выхода новых версий Tor-браузера, чтобы продвинуться в сторону уменьшения количества сторожевых узлов, способных просматривать их трафик, чтобы снизить вероятность подобного рода атак в будущем. Операторы скрытых сервисов должны предусмотреть сценарий смены местоположения своих скрытых сервисов.

Технические детали


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


Атака подтверждения трафика возможна в случае, если атакующий контролирует или наблюдает узлы на обеих концах Tor-цепочки и сравнивает время, объём и другие характеристики, по которым можно сделать вывод о том, что два узла находятся в однй цепочке. Если первый узел цепочки (называемый «сторожевым») знает IP-адрес пользователя, то последний узел в этой цепочке знает ресурс или местоположение, которое запрашивает пользователь, вместе эти сведения позволяют деанонимизировать пользователя. Больше об атаке подтверждения трафика, включая указания на множество исследовательских работ можно прочитать в блог-посте от 2009 года.


Особенностью происходившей атаки подтверждения является использование внесения активных меток в сигнал на стороне одного узла и считывании этих меток на другом узле. Такие атакующие узлы должны быть достаточно стабильными, чтобы получить флаг HSDir («подходящий для использования в качестве директории скрытых сервисов») и Guard («подходящий на роль сторожевого входящего узла»). Затем они вносят сигнал, когда они выступают в роли директории скрытых сервисов и высматривает сигнал, когда используются в качестве входящего узла.


Данные внедрялись в сигнал посылкой последовательностей "relay" или "relay early" — управляющих команд цепочки, что позволяло кодировать желаемое для отправки сообщение. При этом Tor имеет два типа ячеек: ячейки связи, которые предназначены для соседнего узла в цепочке и ячейки узла, которые доходят до конца всей цепочки. В 2008 году был введён новый тип узловой ячейки — "relay early", которая предназначена для предотвращения умышленного создания пользователями слишком длинных путей в Tor-сети: слишком длинные пути приводят к заторам и снижению анонимности. Но исправление путей бесконечной длины привело к проблемам с доступом к скрытым сервисам, и одним из побочных эффектов стало то, что ограничивая исходящие от клиента в цепочку ячейки "relay early", мы не ограничивали количество входящих от узла к клиенту ячеек "relay early".


В итоге, когда клиенты Tor контактировали с атакующими узлами в их роли директорий скрытых сервисов для публикации или получения дескрипторов скрытых сервисов (второй и третий шаги на диаграмме протокола скрытых сервисов), то узел мог отсылать имя скрытого сервиса (закодированного в чередовании ячеек "relay" и "relay early") обратно по цепочке. Другие атакующие узлы, когда они оказывались выбранными в качестве первых узлов в цепочке, смотрели наличие входящих ячеек "relay early" (поскольку никто другой их не мог послать) и таким образом узнавали, какую информацию клиент запрашивал о скрытых сервисах.


Есть три важных соображения по поводу этой атаки:


A) Атакующий кодирует имя скрытого сервиса во вброшенном сигнале (вместо того, чтобы, например, посылать случайное число и сохранять локальный список соответствий случайных чисел и скрытых сервисов). Кодированный сигнал шифруется, так как он посылается по TLS-каналу между узлами. Однако, такой сигнал легко может увидеть и разобрать каждый, кто запускает свой узел и принимает кодированный трафик. И мы также беспокоимся о глобальном наблюдателе (например, большом разведывательном агентстве), который записывает трафик на входящих узлах и затем пытается взломать шифрование Tor-соединений. Таким образом эта атака ослабляет анонимность Tor против всех возможных атакующих, даже от тех кто сохранил логи трафика Tor, чтобы анализировать их в будущем. Так что даже если эта атака является исследовательским проектом (т.е. не преследует злонамеренных целей), она проведена безответственным способом, поскольку подставляет пользователей под риск в неопределённом будущем.


(Это же соображение относится к общим проблемам законности исследований, которые атакуют реальных пользователей, модифицируя их трафик на одной стороне и прослушивая его на другой. Такие средства как Shadow замечательны для исследования идей в отношении Tor в лаборатории).


B) Данная атака модифицирования заголовка протокола довольно изящна с точки зрения перспективности исследований в том, что она отличается от предыдущих атак внедрения меток, которые действовали на уровне трафика приложений. Предыдущие тэггинг-атаки модифицировали завёрнутый трафик, проходящий входящий узел, чтобы затем отслеживать этот модифицированный завёрнутый трафик на исходящем узле (который мог видеть его в расшифрованном виде). Такие атаки не работали в обратном направлении (от исходящего узла обратно к клиенту), потому что завёрнутый трафик оставался шифрованным на входящем узле. Но поскольку этот новый подход модифицирует «тэг» клиентских заголовков, а не завёрнутый трафик, то любой узел в пути способен видеть этот тэг.


C) Следует напомнить читателям, что поскольку данный частный вариант атаки подтверждения трафика позволяет эффективно создавать корреляции с высокой достоверностью, то более общий класс пассивных (статистических) атак подтверждения трафика остаётся неисправленным мерами защиты и будет также хорошо работать в этой схеме. Хорошая новость в том, что атаки подтверждения трафика не являются новыми и неожиданными, а плохая новость в том, что они продолжают работать. См. обсуждение здесь.


Второй класс атак, который был осуществлён совместно с атаками подтверждения трафика — это стандартные сивилловые атаки — они заключаются в запуске быстрых неисходящих узлов, все в IP-диапазонах 50.7.0.0/16 и 204.45.0.0/16. Вместе эти узлы собрали на себя примерно 6.4% пропускной способности входящих узлов Tor-сети. Затем, частично по причине нашей текущей политики ротации сторожевых узлов, они успели оказаться в использовании у значительной части пользователей Tor в течении 5 месяцев проведения операции.


Мы сразу обратили внимание на эти узлы в момент их присоединения к сети по отчётам сканера DocTor. Мы определили множество новых узлов в промежуток времени, но решили, что их не столько много, чтобы повлиять на большую часть сети. Понятно, что следует учитывать пространство возможностей роста Tor-сети при одновременном учёте социальных контактов с владельцам очень больших наборов узлов. (В целом, возможность распределённости по местоположению и операторам без возможности включения плохих узлов, выглядит сложной проблемой; с другой стороны наши скрипты уведомляют об этом, так что следует надеяться на появление улучшенного решения).


В качестве ответа мы принимает ряд краткосрочных шагов:


1) Удаляем атакующие узлы из сети.


2) Вносим обновление в программу для предотвращения использования ячеек "relay early" данным способом.


3) Вносим изменения для клиентов, которые по мере апгрейда смогут использовать только один входящий узел вместо трёх, чтобы уменьшить раскрытие информации между разными узлами в большой промежуток времени.


4) Клиенты смогут определять, получают ли они "relay" или "relay-early" ячейки. Для пользователей-экспертов появится возможность просматривать соответствующее предупреждение в логах: "Received an inbound RELAY_EARLY cell".


Долговременные вопросы, требующие исследования, включают:


5) Дальнейший рост разнообразия операторов и размера Tor-сети, уменьшающий ущерб от появления противников определённого уровня.


6) Использование улучшенных механизмов, например социальной коммуникации, для уменьшения воздействия злонамеренных множеств узлов. Мы также формируем группу, уделяющую больше внимания наблюдению за подозрительными узлами в сети.


7) Дальнейшее уменьшение раскрытия сторожевых узлов путём уменьшения периода их ротации.


8) Улучшение понимания атак статистической корреляции трафика и выяснение вопроса, поможет ли дополнение трафика и другие методы противостоять им.


9) Улучшение дизайна скрытых сервисов, в том числе создание затруднений узлам, поддерживающим HS-директорию, для выявления скрытых сервисов, дескрипторы которых хранятся на данных узлах.

Открытые вопросы


Q1) Это то, из-за чего было отозвано недавнее выступление на Black Hat 2014?
Q2) Сможем ли мы найти все злонамеренные узлы?
Q3) Могут ли злонамеренные узлы внедрять сигнал куда-либо ещё, помимо HSDir?
Q4) Сколько данных смогли собрать атакующие, собираются ли они уничтожить эти данные? Защищали ли они как-то эти данные при хранении?


Мы потратили несколько месяцев, пытаясь получить информацию от исследователей, пытавшихся выступить на Black Hat, и с их подсказок догадались, что ячейки "relay early" могут быть использованы для атак подтверждения трафика, после чего мы стали искать эти атаки в реальном мире. Они нам не ответили, так что мы считаем, что ответ на вопрос Q1 — «да». Фактически, мы надеемся, что это именно они проводили атаку, иначе это делал кто-то ещё. Ответов на вопросы Q2, Q3 и Q4 мы пока не знаем.


Источник: The TorProject Blog


 
На страницу: 1, 2, 3 След.
Комментарии [скрыть комментарии/форму]
— unknown (04/08/2014 12:20, исправлен 04/08/2014 12:34)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Тогда она будет гораздо сильнее уязвима не к административным, а к техническим методам деанонимизации. Да и с административными будет не всё так гладко. Tor за счёт чего и получил часть преимущества, что вынес все нерешённые проблемы протокола на контроль авторам проекта и сообществу вокруг него: синхронизация статистики через корневые узлы — это единственное реальное пока решение, которое может избавить от наводнения сети полностью виртуальными узлами, которых не существует в действительности. Принудительный выброс плохих узлов из статистики — тоже такой компромисс. Да, слишком много власти и ответственности в руках руководителей проекта и ведущих групп узлов. Но пока ничего принципиально нового не изобретут, всё остальное на долгое время будет хуже.



Закрытый Tor можно делать штатно на основе существующего: прописываете свои DA в конфиге и вперёд. Только ни массовости, ни анонимности, ни разницы интересов это не добавит. А доверяемые люди — это те же самые, которые будут заинтересованы сдать каждый друг друга, если начнут распутывать цепочки доверия и отношений. Получится, что по интересам будет сеть хакеров, сеть диссидентов, сеть финансового криминала, сеть педофилов, сеть наркоторговцев, сеть госшпионов и пр. Каждая сеть будет иметь свой специфический паттерн, профилирование по интересам, туда внедрят агентов и стукачей, которые её и распутают. А обычные пользователи со средними потребностями в анонимности не смогут получить доверие каких-то заинтересованных кругов и найти себе сеть по интересам.


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

— Гость (04/08/2014 12:54)   <#>
Но пока ничего принципиально нового не изобретут, всё остальное на долгое время будет хуже.
Так изобретайте же! Тору недолго осталось, нужно уже сейчас готовить замену чтобы не остаться с голой жопой.

Закрытый Tor можно делать штатно на основе существующего: прописываете свои DA в конфиге и вперёд.
Это не то. Нужен не централизованный тор, а полностью другая архитектура. В торе любой участник сети имеет список всех нод, а надо чтобы он не знал никого кроме своей точки входа.

Получится, что по интересам будет сеть хакеров, сеть диссидентов, сеть финансового криминала, сеть педофилов, сеть наркоторговцев, сеть госшпионов и пр
Нет, предполагается что сеть будет одна, но все узлы приватные. Чтобы подключиться, нужно найти узел и получить туда доступ (можно подключаться к нескольким узлам сразу, для отказоустойчивости). Узлы соединяются друг с другом тоже на основе неформальных отношений. Каждый из них знает ограниченное количество других. Согласно теории шести рукопожатий, такая сеть будет глобально связанной.

А обычные пользователи со средними потребностями в анонимности
Обычные пользователи тоже кого нибудь знают, если не в лесу живут. Наверняка будут открытые узлы которые можно найти через гугл. Их будут ликвидировать, но новичок успеет освоиться в сети и найти приватные точки для подключения.

туда внедрят агентов и стукачей, которые её и распутают
Это будут мелкие локальные неприятности. Надо сделать так чтобы владельцы узлов не могли никого деанонить, а локальные ликвидации ячеек сети не страшны, откроют новые.
— unknown (04/08/2014 13:39, исправлен 04/08/2014 13:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Это принципиальные ворота для огромного числа способов деанона. Клиенту могут впарить всё что угодно под видом подключения к сети, о которой он ничего не знает. А клиенты с разными картинами сети (статистикой) — разделяемы в ней для стороннего и внутреннего наблюдателей.


Обсуждалось уже, что в теории анонимных полностью распределённых P2P-сетей очень плохо с защитой от активных атак. Могут быть атаки разделения и изоляции клиентов, атаки наводнения ложной статистикой и виртуальными узлами. Пока эта проблема теоретически не решена, в Tor решили ограничиться групповой (консенсус группы DA) централизацией. Собственно, взяли самые консервативные идеи, их и продвигают, стараются выжать максимум пока из них.

— Гость (04/08/2014 15:56)   <#>
Так изобретайте же!
Рыбак приходит домой, ничего не поймал, злой и голодный:
-Мама, что у нас сегодня пожрать?
-Ну так пожарьте ж рыбы.
-Та рыбы ж нету...
-Ну так чего ж вы пи%@ите?
Ну вы поняли. А вообще лично вы будете платить зарплату разработчику? И таки сеть должна быть для всех, да.
— Гость (08/08/2014 03:58)   <#>

Предлагаю бюджетную атаку на HS со стороны АНБ или ФБР. Строим множество цепочек к HS, они чисто статистически пройдут через все guard-узлы HS. Guard-узел знает IP самого HS (хотя и не знает его адрес). Сейчас guard'ов штуки 3, но хотят их сделать практически постоянными и сократить до одного (это немного затруднит такие атаки).

Итак, в сети Tor около 6000 нод, лишь часть из них может быть выбрана в качестве guard'ов. Мы будем DDoS'ить по очереди все узлы, которые могут быть guard'ами. Если узел действительно guard для HS, наша конкретная цепочка, идущая через этот guard, перестанет работать, и мы это заметим. Чем больше у HS guard'ов, тем быстрее мы найдём его. DDoS'ить можно буквально несколько секунд, чтобы провести своего рода атаку пересечения и подтверждения.

Оценочно за несколько дней таким макаром можно перебрать все узлы и найти все guard'ы любого HS, потом идём к guard'ам и выясняем, с кем они связывались — достаточно повторить атаку и посмотреть, с кем нужно оборвать связь, чтобы цепочка сдохла. Впрочем, раз IP нужного HS будет висеть в прямых соединениях, найти его будет легко в любом случае.

А в ордерах потом можно будет писать про чудеса с пустыми паролями на административный аккаунт, про длительные расследования и найденные зацепки в реале и т.д. Когда знаешь, что искать и где, найти всегда легко (parallel reconstruction).
— Гость (08/08/2014 04:12)   <#>
В тему новости была мысль о том, как связать ключ onion-узла и PGP-ключ его администратора. Понятно, что админ может выложить у себя на сайте свой ключ, но было бы лучше, чем б каждый мог непосредственно проверить, что владелец данного PGP-ключа также владеет и приватным ключом определённого HS. На уровне криптографического материала ключей, наверно, это можно реализовать? Ну, чтоб самозванцы до момента компрометации HS не могли заявить, что это именно они его админы, даже если б могли размещать на его веб-страницах всё, что хотят.

Аналогичный вопрос может быть поставлен и про связывание каких-то других ключей — допустим, PGP и OTR. Понятно, что я могу добавить на свой ключ uid с содержимым «my OTR fpr is...», но так же сможет сделать и Ева, даже если у неё нет этого ключа (а вдруг мой клиент знает только мой OTR-ключ, но не знает PGP-ключа?). Т.е. нужно как-то, чтобы оба ключа заверяли друг друга одновременно — OTR-ключ заверял PGP, а PGP-ключ заверял OTR. Я слишком много хочу?
— unknown (08/08/2014 10:59)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Проект Tor приглашает помочь в разработке скрытых сервисов, см. п. «защита от DoS-атак на точки выбора соединения». Это было опубликовано в работе 2006 года, там авторы предупреждали о DDoS-атаках и методах защиты от них (внедрение Valet-узлов, помимо гвардов). В работе не упомянуто напрямую, что это имеет отношение к деанонимизации, но позднее где-то авторы указывали и на это.


На доверяемом ключе повесить открытый UID ониона. А чтобы при каждом обращении заверять — ну только если подписывать все выкладываемые там материалы.


Передать подписанный этим PGP-ключом совместно оговорённый текст, потеряв отрицаемость.
— Гость (09/08/2014 04:09)   <#>

Ева это тоже может сделать. Допустим, я хочу получить PGP-ключ владельца конкретного HS. Как я узнаю, что это он? Т.е. что это именно он владеет приватным ключом этого HS. Ну, и хотелось бы, чтоб такое решение масштабировалось (один владелец и тысячи клиентов, каждый может проверить соответствие).


Такой вопрос мной не ставился.


Имелся в виду более-менее стандартизированный интерфейс, который бы позволил это делать всем и каждому, причём без необходимости контакта. Например, с onion-ключа я мог бы выудить какие-то секретные криптографические параметры и потом подписать ими параметры публичного PGP-ключа, после чего повесить на свой PGP ключ некий дополнительный открытый подключ, как бы заверяющий основной ключ. Раз в PGP ввели ECC, может быть, уже можно такое провернуть, написав обёртку вокруг gpg. Правда, там по стандарту, наверно, не все криптографические параметры (длины экспонент или что там в ECC) возможны, поэтому может оказаться так, что ECC в PGP несовместимо с ECC в Tor.
— unknown (09/08/2014 16:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664


Пусть на HS запущен вебсервер. На нём есть админский раздел, куда может помещать текст только админ ресурса. Там он может поместить отпечаток своего PGP-ключа.

Поскольку соединение до HS шифровано и аутентифицировно, то такой отпечаток также будет шифрован и аутентифицирован — никто не может подменить его в пути. С другой стороны, если противник может взломать HS и разместить там другой отпечаток ключа, то можно полагать, что HS скомпрометирован, противник может также и украсть закрытый onion-ключ HS и имеет возможность подделывать доказательства любым другим способом, так что необходимости никакого дополнительного протокола здесь не просматривается.
— Гость (09/08/2014 21:13)   <#>
Всё равно тут много сущностей: нужно заходить по веб, нужно искать, где админ разместил свой ключ (и разместил ли он его вообще хоть где-то на сайте) и т.д. А могло бы это выглядеть так: хочу узнать PGP-ключ HS-сервиса — делаю запрос:
$ gpg --recv-keys xxx.onion
Если ничего не находится, значит, админ или не имеет PGP-ключа, или он его таким образом не аутентифицировал. Если находится, то вот — список PGP-ключей, принадлежащих админу HS. Наверное, такое пока малореально.
— Гость (10/08/2014 14:31)   <#>

gpg нельзя настроить работать через прокси, а значит через Tor тоже, а значит заходить на onion сайты
— SATtva (10/08/2014 14:38)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

man не читай @ сразу отвечай. О параметре --keyserver-options http-proxy= Вы не в курсе?
— unknown (10/08/2014 23:02)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Неизвестно насчёт возможной утечки DNS при использовании такого параметра. В Unix-подобных ОС для таких программ лучше использовать прозрачную торификацию средствами файрволла. Есть принципиальные противники прозрачной торификации, но они больше приводят свои аргументы для TorBrowser'а. Само обсуждение прозрачной торификации и вообще способов продвинутого использования Tor лучше обсуждать в соответствующих темах.
— Гость (10/08/2014 23:10)   <#>
Хабр ещё доставляет в тему новости. Интересное:

Причем в случае СОРМ детектируемость этой аномалии достаточна для доказательной базы.

Спорное утверждение. Для начала методика должна пройти апробацию, сертификацию и всё такое.

Аналогичный способ можно применить и в большинстве VPN, но, к счастью, он не сработает с прокси и другими прикладными шлюзами.

Атака в целом работает с прокси, не работает только передача маркировки через полузакрытое соединение, когда маркировку можно передать скрытно от клиентского приложения, не затрагивая передачу реальных данных. Именно потому, что прикладной шлюз одновременно является и клиентом и сервером. Клиент не считает«скрытых» данных — соответственно и не передаст их в сервеную часть и дальше следующему клиенту.

С UDP все даже легче, т.к. в нем Нагла нет. Т.е. потеря возможности управлять размером пакетов с лихвой компенсируется очень прогнозируемыми таймингами.

Плохо понял, что они всем этим хотели сказать.

А еще год назад на одной из выставок (не помню — или Zero Nights или PHD) показывали активное оборудование СОРМ, которое встает в разрыв между абонентской сетью и интернетом и умеет шейпить трафик. Exit node под контролем такого оборудования — это готовое условие для атаки. И не факт что в других странах уже не так.

Поскольку хабр есть хабр, нет самого главного — собственно ссылки на саму презентацию и/или статью, где всё формально описано. По всей видимости, речь идёт об этой презентации. Сайт написан по всем канонам говна и на JS, поэтому презентация не скачивается через TBB даже при включённом JS (хотя смотреть онлайн можно). Автор из Нижегородского университета им. Лобачевского. Кстати, он же — автор 3proxy.

Пока гуглил, на сайте конференции нашлось что-то странное:

16) What obsession does the CEO have? :) (58% correct answers)

This task ended up being rather simple: many competitors solved it, and several almost met. Pay attention to .onion domain, enable Tor and get the background from the competition’s authoring JPEG format. EXIF tags included the correct answer.

Correct answer: Zillaphilya
— Гость (10/08/2014 23:16)   <#>

В принципе — да, интересная мысль. Можно на каждом HS поднять свой сервер ключей и там выкладывать нужный ключ, но если HS вдруг в дауне, это не сработает, поэтому лучше всё-таки не привязываться к конкретному серверу ключей. А раз так, то мы возвращаемся к исходной проблеме — как параметрами onion-ключа заверить параметры PGP-ключа, оставаясь в рамках универсальности и практичности.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3