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

В продолжение темы про IPv6. У этого нового протокола есть интересное математическое (вычислительное, если хотите) отличие от IPv4. Так, в старом протоколе есть не более 2³²=4294967296 (около 4 млрд) потенциально различимых адресов. Предположим, что мы задумали каждому возможному адресу сопоставить один байт с некоторой информацией. Массив займёт примерно 4 гигабайта. Это объём ОЗУ обычного современного настольного компьютера. То есть, подобные таблицы, “перечисляющие” некоторым образом всё пространство IPv4, можно “ворочать” без особых вычислительных затрат. Не важно, для чего используются такие массивы-таблицы, для обозначения каналов доставки пакетов, для подсчёта обращений к некоторым узлам, для балансировки нагрузки глобально доступных сервисов или для чего-то ещё. Главное, что возможен простой, “прямой” способ работы со всем множеством адресов.

Реализовать подобное для IPv6 – не выйдет. 2¹²⁸ элементов невозможно уместить в память никакого существующего суперкомпьютера. Хуже того, их невозможно даже перебрать за разумное время ни на каком суперкомпьютере. Другими словами, множество адресов IPv6, перечислимое математически, не “перечислимо” в суровой программистской реальности, потому как “нет таких компьютеров”. Казалось бы – ну и ладно, кому нужны эти гигантские таблицы?

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

Хотя, понятно, конечно, что “на свободе” не должно ходить IPv6-адресов сильно больше, чем существует устройств, способных такие адреса использовать.

Технократический юмор по выходным.

Следом за кем-то из популяризаторов новой версии IP, всё чаще повторяют, что (в отличие от IPv4) “число адресов в новом протоколе – IPv6 – практически бесконечно”. Конечно, 2¹²⁸ – число большое. Но если сравнивать его с бесконечностью (даже потенциальной), то оказывается столь малым, что им можно просто пренебречь в расчётах. Другими словами, понятно, что новое адресное пространство не бесконечно. И можно придумать способы, приводящие к его исчерпанию за некое разумное время.

Хотя это будут непростые способы. Так, если задаться целью и выделить специальный класс адресов для геолокации, то ушедшие для обозначения каждого квадратного метра (а кому нужна точность выше?) земной поверхности IPv6-адреса практически никак не уменьшат пул свободных адресов. (Площадь Земли – примерно 5*10¹⁴ квадратных метров, а адресов доступно примерно 3*10³⁸; то есть, можно примерно все планеты в наблюдаемой Вселенной покрыть адресами, в несколько сотен слоёв.) А кроме того, использование IP-адресов для геолокационной привязки – не самое правильное решение, если только речь не идёт о фантастической глобальной сети связи с очень высокой плотностью узлов.

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

Надежды можно связывать всё с теми же нанотехнологиями. Так, IPv6-адреса могут присваиваться нанороботам, имеющим размер примерно как десяток вирусов. Адреса используются для управления роботами. Тут, кстати, есть интересная проблема: как такой длинный адрес (128 бит!) записывать на самом роботе? Если один атом сохраняет один бит, то 128 атомов – это расточительство, если вы работаете в масштабах мира молекул. Наверное, можно отрезать идентификатор класса и сети от адреса и в самом нанороботе сохранять только последние несколько бит, а маршрутизацию управляющих команд, как обычно, поручить неким коммуникационным узлам. В общем, более или менее всё укладывается в схему протокола.

Нанороботы должны как-то там самокопироваться и, таким образом, множиться довольно быстро. Если каждую секунду робот “удваивается”, а мы начинаем с одного робота, то… ну, сами понимаете, при равномерном развитии процесса, уже примерно через две минуты станет ощущаться острая нехватка IPv6-адресов (как и всего другого на нашей родной планете). И проблема тут не в том, что скорость выдачи блоков IPv6 слишком мала и роботы не будут успевать адреса получать. Нет. Проблема в том, что даже если кубический миллиметр пространства может быть порабощён лишь одной тысячей нанороботов, то на момент исчерпания адресного пространства они уже захватят Землю, плотно заполнив собой океаны.

Мы тут обсуждаем смартфоны и сходную продукцию (ключевые слова: 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 давно. Например, в одной из прошлых записок эффективная ПРО разобрана “по слоям”. Понятно, что без самого первого эшелона, который действует на этапе старта и разгона ракет противника, построить надёжную систему нельзя. При этом технологии, – имеющиеся в наличии, а также и те, создание которых выглядит реальным в обозримом будущем, – позволяют построить первый эшелон только с использованием сверхбыстрых противоракет, в том или ином варианте. (Действительно, огромное число мощных лазеров – это скорее для кинематографа.)

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

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

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

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

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