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

Используя сервис RIPE NCC Atlas, я провёл пару простых измерений доступности сайта зимней Олимпиады www.sochi2014.com из разных регионов мира. Методика несложная: узлы сети Atlas “пингуют” (ICMP) хост, доступный под адресом www.sochi2014.com. Различие между измерениями в том, что в первом случае IP-адрес при помощи запроса в DNS определяет управляющий сервер (который раздаёт задания), а во втором – опрос DNS происходит на самих тестирующих узлах. Поэтому в результатах можно хорошо видеть, как работает балансировка, использующая DNS, в CDN Akamai.

Здесь, на картинке выше, определение имени проводил сервер, находящийся в Европе (вероятно, в Амстердаме), поэтому был получен IP-адрес для европейских пользователей, соответственно, для Штатов наблюдается большое время “отклика” (красные отметки). Типичные пользователи так с сервисом не работают, в Штатах должны использоваться местные DNS-резолверы.

На этой картинке – результаты второго измерения, метод скорректирован: определение IP-адреса для www.sochi2014.com проводится на тестирующем узле. Теперь всё окей: время отклика стабильно минимальное, в том числе, в Штатах. Это показывает, что работает хорошо распредлённая сеть серверов.

Отмечу, что для тестируемого имени используется большое количество IP-адресов, то есть, в ответ на запрос в DNS их возвращается несколько – “пинговался” же только один адрес из полученного списка.

Другой момент. Балансировка при помощи DNS имеет следующую особенность: вероятное местоположение пользователя, фактически, определяется про адресу DNS-резолвера, который его обслуживает. Так, запросы в DNS из, например, дата-центра в Дублине – возвращают для www.sochi2014.com одни адреса; выполнив запрос из московского дата-центра – получаем другие; а в случае использования Google Public DNS из Москвы – третьи. (Понятно, что опрос Google Public DNS из Штатов – даёт ещё один вариант.) Таким образом, если пользователь находится в Твери, но использует европейский DNS-резолвер, его браузер будет соединяться с европейскими серверами Akamai. Впрочем, в современном Интернете это чрезвычайно редкая конфигурация, так что её можно не принимать в расчёт.

(На картинках есть серые метки – это узлы Atlas, для которых запрос ICMP Echo в сторону олимпийского сайта не сработал. Такая ситуация вполне нормальна, и не означает, что недоступен сайт: “пинги” могут не ходить по сети, где установлен измеряющий узел, по самым разным причинам.)

Новый сайт Sochi2014.com вполне логично размещён на мощностях Akamai (один из крупнейших мировых провайдеров услуг CDN) – это хорошо. Но вот с HTTPS повторяется типичная для Akamai история: при попытке безопасного соединения с https://www.sochi2014.com/ – серверы отдают “провайдерские” SSL-сертификаты, выпущенные не для sochi2014.com, а для имён вроде *.akamaihd.net, a248.e.akamai.net и прочих. В результате – имеем в браузере предупреждение системы безопасности, что уже не очень хорошо.

Проблема, кстати, весьма старая, и Akamai её, похоже, так и не поправил.

По статистике сайта Blockchain.info, крупнейший пул GHash.IO приближается к 40% мощности всей сети Биткоин. Пул – это объединение узлов, занимающихся “майнингом” (добычей) биткоинов, то есть, обеспечивающих проведение транзакций. Захват большей части вычислительной мощности позволяет контролировать Сеть, так устроен протокол (подробнее о том, что и как – в отдельной заметке о биткоинах).

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

Так что, вероятно, близок очередной кризис биткоинов, а он будет сопровождаться шумихой в прессе, что добавит интереса теме. Посмотрим.

Сейчас в Сети массово внедряются новые домены верхнего уровня, с самыми разными именами (.link, .moscow, .shop и др. – список можно посмотреть на специальной странице). Уже на этапе обсуждения технических аспектов появления новых строк в корневой зоне DNS, возникли опасения, что возможен конфликт имён, так как некоторые корпоративные сети используют собственные, “локальные”, домены верхнего уровня, выбирая их произвольно. Примеры: .corp, .lan и так далее.

Во внутренней сети имена в таких доменных зонах работают потому, что так настроены локальные резолверы DNS. Если же компьютер с неверными настройками перемещается за пределы локальной сети, – или, что тоже бывает часто, администраторы ошибаются в конфигурации, – запросы об адресах в “собственных доменах” выходят наружу и хорошо видны в трафике корневых серверов DNS. Поэтому, появление в глобальной DNS соответствующих доменов верхнего уровня, теоретически, грозит некоторыми конфликтами адресации. Подробнее об этом явлении можно почитать в осеннем выпуске журнала “Доменные имена”. А в этой записке речь о несколько другом, но тоже занимательном моменте.

ICANN (организация, управляющая адресацией Интернета) решила зарезервировать в новых доменах имена второго уровня, которые наблюдались в трафике корневых серверов за некоторый промежуток времени. То есть, регистрация таких имён будет, как минимум в течение некоторого времени, невозможна. Резервирование должны осуществить администраторы соответствующих новых доменных зон. Cписки резервируемых имён опубликованы ICANN в соответствующих разделах сайта. Вот, например, список для .link (длинный, 34377 строк), а вот – для кириллического домена .дети (всего несколько десятков строк). Для домена moscow – резервируются 6236 строк.

Если взглянуть на приведённые списки, то, помимо редких осмысленных сочетаний символов, можно обнаружить большое количество строк, представляющих собой случайную последовательность из десяти букв, например: fnszofchcm. Судя по всему, это следы работы функций проверки DNS-окружения браузеров Chrome и Chromium (и некоторых других): запросы, содержащие случайные комбинации символов, выполняются для того, чтобы убедиться, что имеющийся в сетевом окружении DNS-резолвер не подменяет несуществующие адреса – в ответ на запрос о несуществующем в глобальной DNS имени должен приходить ответ, что такого имени не существует (банальность, казалось бы, но в реальности это не всегда так).

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

Эта заметка – популярный обзор того, как работает сеть Биткоин и соответствующая ей валюта. Основные темы: логика протокола, blockchain, некоторые расхожие мифы, связанные с биткоинами, “майнинг” и перспективы системы.

Читать полностью

Одной из основных особенностей протокола сети Биткоин является то, что транзакции и всю сеть контролирует тот, кто контролирует большую часть вычислительной мощности – грубо говоря, работает “правило 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.)