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

Мы тут обсуждаем смартфоны и сходную продукцию (ключевые слова: Apple, Android), в том смысле, что если сильно беспокоиться о том, что подобные устройства активно шпионят за “носителем” и “сливают информацию в центр”, то совсем нельзя пользоваться современными, удобными технологиями коммуникации. Действительно, удобно – и альтернативы нет. Куда податься? Ответ теоретика такой: в сторону открытых аппаратных платформ (ОС с открытым исходным кодом и так уже есть).

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

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

Если обретёт популярность идея, – озвученная даже в ООН, – о том, что доступ к Интернету находится в ряду основных прав человека, то возникнет интересный феномен “гуманитарного Интернета”. То есть, массовый доступ будут организовывать силами развитых стран в тех государствах, где собственными силами не справились. Но, конечно, при необходимости. Интересен вот какой аспект: формальные лозунги о доступе – они не связаны с действительным проникновением Интернета, потому что не понятно, как доступ измерить. Ну вот есть некий доступ к местным сайтам по списку и права человека, таким образом, не нарушаются.

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

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

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

Другими словами, если Skype был кривым внутри, в смысле криптографии, то и раскрытие/нераскрытие исходников никак ситуацию для пользователей не ухудшит (разве что улучшит, кстати, если ПО будет получать соответствующие сертификаты).

Благодаря бурному развитию технологий, методы определения местонахождения интернет-пользователя, обратившегося, например, к вашему интернет-сервису, приобрели чрезвычайную гибкость и эффективность. Если собрать методы вместе, то получается примерно вот такой (от простого к сложному) расклад.

Самое простое, это поиск IP-адреса пользователя в той или иной “геолокационной” базе. Такие базы содержат сведения о том, в какой регион выделялся данный IP-адрес. Так как первоисточником тут являются интернет-регистратуры, а уточнения часто делаются лишь по информации от провайдеров, то точность низкая. Определить местоположение “до дома” не выйдет.

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

Другой вариант: со стороны сервера можно построить (“оттрассировать”) сетевой маршрут до клиентскогого IP-адреса (с некоторой точностью, понятно). Если точно известно местоположение последнего перед клиентом узла, то можно предположить, что и клиент где-то неподалёку от этого узла находится. Опять же, работает не во всех случаях, но в большинстве.

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

Геопривязку не требуется ограничивать IP-адресами. Подходят другие уникальные идентификаторы, например, куки, выданные пользователям какого-то сервиса. Собственно, куки хорошо дополняют IP-адреса.

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

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

И, похоже, это ещё не все способы.

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

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

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

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

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

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

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

А занятнее всего тут то, что такой смартфон ещё и собирает сведения о местоположении других, так сказать, “абонентов поневоле”, которые даже и не догадываются о происходящем, и вообще не подписывались под всеми этими соглашениями. Например, приложение в смартфоне собирает MAC-адреса замеченных в эфире точек доступа Wi-Fi и, привязав их к координатам, полученным от GPS, отправляет “в центр”. История известная.

Так что сведения, доступные оператору связи, не только оказываются менее подробными (учитывайте и точность GPS), но и риски несут совсем другие, если сравнивать с продвинутыми мобильными программными платформами, которые, при этом, никто особенно и не регулирует, не ограничивает.

Сделали страничку для тестирования IPv6: http://ipv6.nic.ru/ – можно проверить, что IPv6 скорее всего у вашего провайдера ещё нет (ну или есть, да, что сильно вряд ли).

Как это работает, если интересно: сервер один, два виртуальных хоста, один отвечает по IPv4, второй – по IPv6. Домашняя директория у них общая, поэтому PHP-код, генерирующий страницу, един, и БД, понятно, общая. Ни с “Апачем”, ни с PHP проблем в использовании IPv6 не возникло. Но, как обычно, в некоторых местах IPv6 попытался вставить палку в колесо. Например, нужно специально следить за соединениями с внешними серверами: на той машине, где вертится страница, используется оба стека (v6+v4), поэтому по умолчанию соединение “наружу” устанавливается по IPv6 – точнее, пытается установиться, потому что далеко не везде есть нужная коннективность. Ну и отдельная история: сходят с ума некоторые старые фильтры/регулярные выражения, когда к ним из переменных окружения веб-сервера поступают IPv6-адреса. Тут будет отдельный пучок проблем с CMS.

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

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

Да, есть баллистика и полёт пули. Для конкретного типа пули, понятно, важны параметры полёта, но вовсе не сами по себе, а лишь в рамках конструкции оружия, которая как раз и задаёт диапазон для “баллистических” параметров. Похоже, что во многом по этой причине – то есть, из-за конструктивных различий в типах огнестрельного оружия, – и появилось современное разделение по распространённым калибрам для пистолетов, штурмовых винтовок, пулемётов.

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

Перспективные системы противоракетной обороны обсуждаются на dxdt.ru давно. Например, в одной из прошлых записок эффективная ПРО разобрана “по слоям”. Понятно, что без самого первого эшелона, который действует на этапе старта и разгона ракет противника, построить надёжную систему нельзя. При этом технологии, – имеющиеся в наличии, а также и те, создание которых выглядит реальным в обозримом будущем, – позволяют построить первый эшелон только с использованием сверхбыстрых противоракет, в том или ином варианте. (Действительно, огромное число мощных лазеров – это скорее для кинематографа.)

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

Да, технически, перехватчики можно и отозвать в любой момент. Но такой шаг оправдан только в том случае, если гарантированно известно, что старта ракет не последует – иначе первый эшелон оказывается заранее выведен из строя и действия остальной ПРО, в общем-то, теряют эффективность. А теперь можно вспомнить о том, что массированный налёт перехватчиков – уже более чем достаточное основание для старта тех самых МБР, за которыми перехватчики и прилетели. То есть, необратимость ПРО работает очень логично. И, конечно, строгости ситуации добавляет тот факт, что ПРО, после команды “Пуск”, обязательно должна управляться лишь собственными вычислительными системами, полностью автономно. А компьютер не станет отыгрывать назад. Потому, что у него и “обратных” ходов-то не будет в программах.

На прошлом авиасалоне МАКС экспозиция ВВС США выглядела так:

(То есть, “очень пусто”.)

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

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

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

Зарисовки практического освоения IPv6. 8 июня проводится всемирный день IPv6. Соответственно, нужно подготовиться. Что выясняется: во-первых, шишки набиваются при внедрении нового протокола на пользовательских рабочих местах; в теории всё ПО (в том числе ОС) готово и должно работать, на практике оказывается, что по отдельности работает, а вот чтобы вместе – нет, тут наблюдаются неожиданные эффекты, типа автоматического получения ОС Windows сразу нескольких адресов для одного интерфейса, потому что так были восприняты анонсы ближайшего роутера.

Во-вторых, админы пока не воспринимают новый протокол как неотъемлемую часть админской реальности: нужно понимать, что в ближайшие годы придётся жить с двумя протоколами, соответственно нужно “задвоить” все навыки и прикладные настройки. На практике выходит, что для одного и того же прикладного использования (например, отправка электронной почты), где IPv4-доступ настроен раньше, при вводе IPv6 внести соответствующие изменения в контроль доступа забывают. Хотя, казалось бы, для одной и той же физической машины, получившей IPv6 в дополнение к v4, нужно автоматом сохранить все прикладные доступы.

В-третьих, очень интересной станет жизнь у веб-разработчиков: у многих скриптов будет начисто сносить крышу после того, как веб-сервер вместо привычных IPv4 принесёт в переменные окружения новую запись новых адресов. Там проблем уже сейчас просматривается много, а ещё больше запрятано внутри всяких фильтров и валидаторов. Ещё веселья добавит только что упомянутый факт, что речь не идёт о пересаживании с v4 на v6 – будет сразу два протокола.

И текущий расклад подтверждает простую мысль: дешевле всего будет строить IPv6-инфраструктуру с нуля, а не обновлять существующую.

Вот.