dxdt.blog: занимательный интернет-журнал

Одной из основных особенностей протокола сети Биткоин является то, что транзакции и всю сеть контролирует тот, кто контролирует большую часть вычислительной мощности – грубо говоря, работает “правило 51%”. Попробуем прикинуть, сколько стоит захват сети Биткоин.

Производительность этой сети измеряют в “хэшах в секунду”. Хэши возникают вот откуда: для включения транзакций в главную книгу (blockchain) узлы сети вычисляют значения хэш-функции SHA-256 от некоторого блока данных, подбирая числа в этом блоке таким образом, чтобы результат укладывался в заданный диапазон (так называемая “сложность”). Все эти детали я оставляю для отдельной заметки, потому что они сейчас не важны. Достаточно отметить, что поиск значения хэша – это вычислительно затратная операция, являющаяся одной из основ протокола.

Заявленная мощность сети (blockchain.info/stats) на данный момент – 9333937,66 GH/s, пусть будет чуть больше – 9500000 гигахэшей в секунду. Есть специализированные устройства, позволяющие вычислять биткоин-хэши очень быстро, это так называемые “майнеры” (от англ. mining – добыча; такое название дано потому, что “майнеры” позволяют “добывать” и вводить в оборот новые биткоины). Так вот, если верить сообщениям производителей этих устройств, то стоимость “майнера”, имеющего мощность около 3 терахэшей (3000 гигахэшей) в секунду – от 8 до 12 тыс. долларов США (с доставкой, заметьте). Мы будем покупать много, и у нас, допустим, есть грузовик, поэтому пусть – 8 тыс. за три терахэша в секунду. Нам нужно чуть более половины мощности всей сети, то есть примерно столько же, сколько есть сейчас.

Итак, считаем: 9500000/3000 * 8000 = 25,3 млн долларов США (примерно). Наши узлы, захватывающие сеть, должны обмениваться информацией с другими участниками, поэтому для размещения оборудования потребуется место в дата-центре, каналы связи, услуги монтажников и бригады инженеров. Увеличим затраты примерно в два раза. Итого: 50 млн долларов и – сеть под контролем. Сумма немалая, но, например, в бюджете АНБ она наверняка могла бы просто затеряться среди “прочих расходов”.

Update (22/12/13): мне подсказывают, что есть ещё пара показательных моментов, касающихся этой темы. Во-первых, вполне вероятно, что АНБ могут быть известны некоторые оптимизации для SHA-256, позволяющие, для известных типов входных данных, вычислять эту функцию быстрее в несколько раз (это как раз случай с биткоинами). Если это так, то вычислительных мощностей потребуется меньше, но аппаратуру придётся конструировать свою: доступная на открытом рынке не учитывает секретных оптимизаций. Во-вторых, только за внедрение нужного алгоритма генерации псевдослучайных чисел АНБ заплатило $10 млн компании RSA. В общем, это показывает, сколько может стоить сеть Биткоин, выступающая в качестве платёжной системы.

Reuters сообщает, что компания RSA Security несколько лет назад заключила с NSA контракт, согласно которому в криптографических продуктах RSA предпочтение должно было отдаваться алгоритму генератора псевдослучайных чисел Dual EC DRBG. Последний содержит потенциальный бэкдор, который хоть и оказался плохо спрятан, но неплохо сконструирован в смысле его использования в роли защищённого мастер-ключа.

Кстати, бэкдор в генераторе случайных чисел – весьма универсальный, очень удобный механизм избирательного снижения стойкости криптосистем. Предположим, что для незаметного перехвата HTTPS-соединений требуются секретные ключи удостоверяющего центра (УЦ), с их помощью можно выпустить перехватывающий сертификат, который не будет вызывать предупреждений системы безопасности браузера. Если вы представляете серьёзную структуру, то, конечно, можно прийти в УЦ и настоятельно попросить копии ключей. Но это прямо скомпрометирует данный УЦ в сколь-нибудь долгосрочной перспективе, что не очень хорошо.

Есть более изящный способ: удостоверяющие центры используют для генерации и работы с корневыми ключами специальную аппаратуру (HSM – Hardware Security Module); предложим УЦ приобрести сертифицированную аппаратуру, использующую заданный генератор псевдослучайных чисел – теперь, с помощью мастер-ключа, можно за разумное время вычислить секретный ключ УЦ, не нанося прямого вреда его репутации. Задача перехвата HTTPS решена.

(Забавно, кстати, что на сайте www.rsa.com используется кривой SSL-сертификат, выпущенный для *.emc.com – RSA Security ранее была приобретена EMC Corporation: видимо, попытка сделать HTTP-редирект через кривой сертификат, является одним из результатов слияния компаний.)

(Продолжаем криптографическую серию заметок.) Оказывается, в Firefox версии 26 включили поддержку OCSP staplig. Что это такое? OCSP (Online Certificate Status Protocol) – это протокол, позволяющий клиенту (браузеру) в режиме онлайн проверить не был ли представленный сервером SSL-сертификат отозван. Напомню, что отзыв сертификата – это специальная процедура, позволяющая исключить из списка доверенных сертификат, срок действия которого ещё не истёк. Это требуется, например, в том случае, если скомпрометирован закрытый ключ, соответствующий сертификату.

Логика OCSP довольно проста: получив сертификат, браузер обращается с запросом, содержащим серийный номер сертификата, по адресу специального ответчика (“респондера”), обычно работающего на серверах удостоверяющего центра (УЦ), и может получить ответ о том, не отозван ли этот сертификат. А может и не получить – дело в том, что ответчики OSCP некоторых УЦ работают не так надёжно, как хотелось бы. У OCSP есть и ещё одна особенность: владельцы ответчика получают информацию о том, какие пользователи ходят на сайты, где установлены соответствующие сертификаты (очевидно, что эту информацию передают браузеры, запрашивающие проверку отзыва сертификата).

OCSP stapling позволяет побороть оба неприятных аспекта, упомянутых в предыдущем абзаце. Ответ OCSP содержит электронную подпись, поэтому браузеру всё равно, по какому каналу этот ответ получен, главное, чтобы там была валидная подпись. Подпись действует некоторое время, соответственно, копию ответа может передавать веб-сервер, в момент установления TLS-соединения. Веб-сервер получает ответ OCSP от удостоверяющего центра, независимо от запросов посетителей веб-сайта. Просто и логично. OCSP имеет особое значение для так называемых сертификатов с расширенной проверкой (сертификаты EV), так что технология, прежде всего, актуальна именно для них, а точнее – для сайтов, их использующих.

Я некоторое время назад наладил демонстрационный сервер под доменом 1d.pw, там поддерживается и OCSP stapling – только сертификат там не EV, а простой. Посмотреть на работу OCSP stapling можно при помощи OpenSSL, вот так:

$ openssl s_client -connect 1d.pw:443 -tlsextdebug -status

В выдаче отыскиваем строки, следующие за “OCSP response”:

OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)

Забавно читать про полную анонимность платежей биткоинами. Вот почему: как известно, сеть Биткоин пригодна для осуществления расчётов только потому, что там существует общедоступная полная главная книга (blockchain), в которой содержатся абсолютно все транзакции, позволяющие вычислить текущий баланс всех возможных кошельков. Именно всех возможных, потому что кошелёк в сети Биткоин это просто 256-битное число. Вероятно, этот аспект, контрастирующий с кошельками классических платёжных систем, где при создании требуется указать некоторые данные владельца, и привёл к возникновению ложного представления об анонимности.

На практике, если транзакцию по переводу биткоинов удастся сопоставить с IP-адресом, а последний – с интернет-пользователем, то все его операции, проводимые с данного кошелька, сразу станут вполне персональными. То есть, практической анонимности здесь не больше, чем в той или иной традиционной интернетовской платёжной системе, позволяющей открыть кошелёк без визита в офис и предъявления паспорта. Конечно, для осуществления транзакций можно использовать средства анонимизации, но то же самое относится и к другим платёжным системам. Но в случае с биткоинами – доступность реестра расчётов (главной книги) позволяет деанонимизировать кошельки на основе анализа последовательностей операций: тут уже наработан некоторый инструментарий.

Более того, особенность биткоинов в том, что они позволяют проводить, так сказать, обратную деанонимизацию. Blockchain не имеет срока давности и сохраняется в распределённой сети в течение всего срока её, сети, действия. Это означает, что если однажды удалось сопоставить конкретный кошелёк с конкретным интернет-пользователем, то можно извлечь полную информацию о всех его прошлых операциях, которые он, скажем, проводил несколько лет назад. А ввиду того, что blockchain публичен по определению, сделать это может всяк желающий, а не только сотрудник уполномоченных органов, имеющий соответствующий допуск, как в случае с классической платёжной системой или банком. Какая уж тут анонимность.

(Наверное, имеет смысл написать обзорную записку о том, как работают биткоины.)

Update (02.12.14): подробно про биткоины.

Из Google сообщают об очередных недобросовестных SSL-сертификатах, выпущенных для гугловских доменов из-под промежуточного УЦ (который, в свою очередь, принадлежит некоему УЦ ANSSI). Сертификаты использовались в устройстве, перехватывающем HTTPS-трафик. Подробностей не сообщают.

Я раньше писал о том, что размещение в перехватывающем SSL-прокси сертификата промежуточного УЦ, выпущенного признаваемым браузерами удостоверяющим центром, – давно известная практика. Преимущество такой технологии в том, что перехват осуществляется прозрачно и стандартно настроенные браузеры не показывают предупреждений системы безопасности, поэтому не нужно менять параметры на клиентских машинах. Впрочем, в случае с браузером Chrome и сервисами Google, такой фокус не проходит: Chrome обнаруживает подмену, так как отпечатки верных ключей, а также другие криптографические параметры гугловских серверов, зашиты в его дистрибутив.

Есть такой небольшой проект – домен Nox.su, который я использовал для исследования и практической демонстрации технологии DNSSEC (это безопасное расширение DNS). Недавно, в конце ноября, исполнилось два года с момента внедрения DNSSEC в nox.su. (Я, как и прежде, полагаю, что это первый домен .su, подписанный DNSSEC.) Об очередной годовщине дал знать криптографический ключ KSK для зоны nox.su – он успел “протухнуть”. На смену ему уже заготовлен новый.

Нельзя сказать, что за пару лет DNSSEC “шагнула в массы”, а сейчас является штатным средством защиты в Рунете: в .ru, потенциально, подписано лишь что-то около двух сотен доменов (в статистике по ссылке ведётся учёт только DS-записей). Тем не менее, популярность DNSSEC набирает, но, конечно, слишком медленно.

(Отмечу, что я за это время подготовил ещё несколько ресурсов и публикаций, касающихся DNSSEC. Среди них, например: браузерный инструмент проверки поддержки DNSSEC; справочная страничка dnssec.pw и демонстратор DNSSEC + TLS 1d.pw.)

Популярная тема: давайте сделаем шифрование обязательным элементом HTTP. Речь, понятно, о новой версии протокола HTTP2 (2.0). Это такой способ борьбы с массовой “слежкой через Интернет”, которая сейчас регулярно фигурирует в газетных заголовках. Конечно, шифрование полезно. Но в случае с HTTP есть интересные моменты.

Так, с трафиком работает большое количество разнообразных программно-аппаратных комплексов, не занимающихся “слежкой” как таковой. Хороший пример: системы обнаружения атак и средства противодействия этим атакам. С зашифрованным трафиком они работать не смогут, так как там, по определению, не существует сигнатур, связанных с атаками уровня протокола HTTP, да и вообще – анализировать, с целью обнаружения атак, особенно нечего. Скажем, сейчас, при работе защищаемого веб-ресурса по HTTPS, анализаторы трафика (специальные брандмауэры и разные “гарды”) используют сеансовые ключи, которые в их сторону экспортирует веб-сервер. Эти ключи позволяют просматривать, фильтровать трафик и отрабатывать атаки. Естественно, в случае с тотальным шифрованием – владельцам важных веб-ресурсов поступать придётся точно так же, а ведь именно их трафик и представляет интерес.

Что это означает? А вот что: за периметром, во внутренней сети, трафик всё равно будет нешифрованным. И тотальное введение шифрования HTTP всего лишь сузит круг тех организаций, которые смогут читать “шифрованный” трафик, резко подняв порог доступа. Да, не смогут работать провайдерские системы DPI, пытающиеся балансировать нагрузку и выявлять всякую вредоносную активность, а попутно – строить поведенческие профили пользователей. Но если для анализа трафика используется порт, установленный во внутренней сети крупного сервиса, проблем с анализом не будет. И, естественно, если сервис передаёт вам сеансовые ключи, то трафик можно расшифровывать самостоятельно, записывая его на любой доступной точке.

В Renesys нашли много подтверждений тому, что целевой перехват трафика в Интернете реализуется и путём подмены маршрутов через BGP. Странно, конечно, что они в заголовке называют такое явление “новой угрозой” (The New Threat) – подобные методы известны достаточно давно: например, я писал об одном из сценариев BGP-перехвата в начале 2010 года, это равно тот механизм, который пронаблюдали в Renesys. Но, похоже, сейчас к этой теме привлекут внимание.

Проблема там следующая. Логическую основу Интернета, как сети передачи данных, составляют автономные системы (AS) – это обособленные вычислительные сети, имеющие собственную административную и техническую политику. Существует старый протокол BGP, по которому пограничные узлы-маршрутизаторы автономных систем обмениваются информацией об известных путях доставки пакетов данных. Эти пути (“роуты”) формируют динамическую глобальную систему маршрутов, благодаря которой пакеты от узла в одной автономной системе могут быть доставлены узлу в другой автономной системе, проследовав через ряд транзитных автономных систем. Так работает глобальная Сеть. У BGP есть фундаментальные особенности, которые позволяют автономным системам, активно манипулирующим маршрутами, “заводить” к себе трафик, предназначенный для любой другой автономной системы. Делать так можно даже в том случае, если атакующая система не являлась, в штатном варианте, транзитной для перехватываемого пути (маршрута). Другими словами – узел, находящийся, например, в Праге, может слушать IP-трафик между двумя узлами, находящимися в Вашингтоне.

Почему это возможно? Грубо говоря, потому, что в BGP нет эффективных механизмов проверки того, какие маршруты могут проходить через данную автономную систему. Глобальная таблица заполняется на основе так называемых анонсов, которые выдают пограничные маршрутизаторы, если маршрутизатор анонсирует “чужой” маршрут, то, часто, обнаружить это удаётся только после того, как трафик уже утёк. (Англоязычное название явления: Internet route hijacking.) Очевидно, что трафик, следующий по перехваченному маршруту, может прослушиваться в транзитной автономной системе – для чего и делается перехват. При этом существуют методы, позволяющие скрыть следы такого перенаправления.

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

(Кстати, а в материале Renesys, отчего-то, упоминаются белорусские сети, замеченные в описанной выше подмене маршрутов.)

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

А вот если рассматривать Интернет как новое “виртуальное пространство”, то ситуация тут хитрее. “Посольства” здесь есть у многих государств, а вот принимающей стороной выступает ряд “надгосударственных” образований (например, ICANN). При этом, если взять – и огородить суверенный национальный сетевой сегмент, с целью предотвращения в нём “бурной иностранной деятельности”, то окажется, что, из-за технических особенностей организации Сети, потеряны выходы в общее пространство, где можно было бы вести самостоятельную, вполне активную, деятельность по сбору полезной информации и анализу разных “метаданных”. И не так просто определить, что тут важнее: закрытие сетевых границ или игра на чужом, пока что, информационном поле.

Кстати, в записке, которой уже больше года, оценивается объём ресурсов, нужных для работы системы тотального мониторинга перемещений владельцев смартфонов мощностью в 500 млн абонентов. И такая система, несмотря на то, что описана под грифом “Технологический юмор”, сейчас вообще не выглядит фантастической. Потоки данных там минимальные, для их приёма достаточно всего двух коммуникационных портов, имеющих пропускную способность в гигабит. Порты эти могут быть разделены (пусть их будет, например, семь). Располагаться им лучше всего неподалёку от точек концентрации интернет-трафика, чтобы компенсировать возможные флуктуации пропускной способности в Интернете (ведь наблюдаемые абоненты перемещаются по всему миру).

Другими словами: ждём информации о практической реализации.

В корне DNS работает уже несколько совсем новых, тематических, доменов верхнего уровня, которые выглядят весьма непривычно. Проверьте, например: nic.camera, nic.guru, nic.equipment.

У адресов в этих доменах, при наборе из адресной строки некоторых браузеров (пример – Сhrome), возникает конфликт со встроенной функцией поиска браузера. В Chrome это выглядит вот так (предлагается кликнуть по ссылке, следующей за вопросом о том, хотели ли вы перейти на данный сайт):

Для того чтобы ручной набор сработал, нужно набирать перед именем домена http://.

Странный Интернет, да.