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

Nokia анонсирует смартфон с камерой в 41 мегапиксел. Видимо, расчёт как раз на то, что такое число все кинутся обсуждать. Вообще, они честно пишут, что, мол, пикселы собираются в группы по семь штук, поэтому реальное разрешение где-то около 5 мегапикселей. Показатель более разумный, потому что 41 мегапиксель для матрицы размером примерно 12х8 мм (если я не ошибаюсь) – это за пределами физического разрешения всякой световой оптики, а особенно далеко за пределами разрешающей способности небольшого объектива, который можно запихнуть в смартфон. С другой стороны, даже в случае с объединением пикселей, не ясно, достаточно ли там света, чтобы было, что “семь раз отмерить”.

Число пикселей – это ж важный инструмент маркетинга смартфонов, наверное, скоро будут гигапиксельные устройства, да?

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

Автор теста – Артемий Ломов.

(По воскресеньям – немного технократического юмора.)

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

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

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

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

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

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

Понятно, что собственное производство обеспечивает некоторую дополнительную независимость для государства. Вопрос в том, является ли этот момент ключевым, дающим какое-то уникальное преимущество. Исследование микросхем – ничуть не менее высокотехнологичное направление, чем их производство, так что всякие дополнительные бонусы, вроде развития прикладной науки, сохраняются. При этом доступ к глобальному рынку позволяет получить более широкий ассортимент комплектующих. Какой подход, в итоге, оказывается эффективным? Постройка собственного производства или развитие инструментов контроля?

Вот даже Алекс Экслер в Испании подключается к “соседскому” открытому Wi-Fi, и исследует сетевые сервисы (я надеюсь, при помощи специально сконфигурированного ноутбука). А вы говорите! Что же ожидать от простых пользователей? Они тоже подключаются куда попало. В том числе, и всякими смартфонами, в которых куча персональной информации.

Кстати, есть специальные программные пакеты, имитирующие некую живую “открытую” сеть, с точкой входа через Wi-Fi. Для чего? Чтобы приманивать любопытных. Ну не только для этого, ещё и для своевременного обнаружения вторжений и исследования угроз. Вообще, понятно, что можно поднять такое приманивающее окружение самостоятельно, используя свободное ПО. Да.

А потом удивляются, что почту взламывают.

(Ага, это юмор по выходным.)

Кстати, обсуждение заметки про VPN в чужих сетях, навело на другую интересную мысль. Учитывая, что устройств, использующих доступ к Интернету, при себе всё больше, логичным решением для, например, отеля, является своя точка доступа Wi-Fi с тем же самым VPN-ом, засунутым внутрь. Должно быть удобно, потому что позволит использовать даже те устройства, которые с OpenVPN не дружат.

Чтобы проверить решение на практике, я взял валявшийся без дела роутер Wi-Fi ASUS RT-N12, залил в него прошивку DD-WRT, с поддержкой OpenVPN, загрузил сертификаты (там есть панелька в веб-интерфейсе даже, можно не браться за консоль) и – всё работает, благо, внутри у него Linux. Сложностей настройки не выявил. То есть, теперь сценарий такой: подключаем к чужой проводной сети (Ethernet, понятно) роутер, он поднимает внутри VPN, и получаем собственный зашифрованный и безопасный Wi-Fi, через который могут работать и смартфоны, и планшеты, и старый КПК. Удобно.

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

На фото – F-35 в полёте, пристыкованы пилоны для внешней подвески вооружения. Даже пара муляжей (?) ракет присутствует:

(Фото: Lockheed Martin)

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

We have requested that any such certificates be revoked, and their HSMs destroyed. We have requested the serial numbers of those certificates and fingerprints of their signing roots so that we, and other relying parties, can detect and distrust these subCA certificates if encountered. We have requested that any CAs who have issued subCA certificates fulfill these requests no later than April 27, 2012.

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

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

Другое дело, что только в прошлом году вся эта история с практикой SSL/TLS стала активно обсуждаться в популярных СМИ, а не только в забитых всякой математикой специализированных списках рассылки, которые мало кто читает. Теперь вот довольно-таки паникёрское заявление сделала Mozilla. Интересно, какую реакцию можно ожидать? Что, известные УЦ повинятся? Сдадут свои сертификаты? Перестанут сотрудничать с крупными и очень влиятельными клиентами? Что-то с трудом верится. Тем более, что отловить “кривые” сертификаты довольно трудно, они не светятся на весь Интернет, а пользователь, даже высококвалифицированный, столкнувшись с таким сертификатом, не сможет его распознать. Сейчас нельзя просто взять и выкинуть из браузеров корни всех тех УЦ, которые не смогли убедить разработчиков в том, что они белые и пушистые, подорвав тем самым бизнес этих УЦ – есть риск, что тут будет усмотрено нарушение законов о защите конкуренции. Просматривается, так сказать, полезный выход – это разработка новой технологии управления доверием в Интернете, и такая технология, вероятно, должна быть распределённой, ориентированной на пользователей. Собственно, об этом тоже сказано в исходном сообщении Mozilla. Но возможен и вариант, когда пользователи просто начинают доверять другому корню, скажем, корню DNS.

А если вернуться в сугубо практическое русло, то нужно сказать, что криптография пока что не сломана. Если использовать собственную инфраструктуру ключей и сертификатов, то перехватывать трафик “специальные” сертификаты других УЦ не позволят.

Ну и развитие истории подтверждает то, что производители браузеров всерьёз занялись игрой на рынке безопасности.

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

Я, впрочем, использую VPN. Это хорошее со всех сторон решение. Посудите сами, в случае с чужой сетью, можно выделить два разумных “канала утчеки” или “направления атак”, – называйте, как хотите. Первый канал: ваш сетевой трафик, связанный с типичным использованием сервисов Интернета (страницы сайтов, электронная почта и так далее). Второй канал, о котором обычно забывают: DNS – позволяет отправить ваш трафик куда угодно, буквально, куда угодно; чем и пользуются, обычно, правда, в “благих” целях, например, для того, чтобы предложить оплатить доступ. Да, есть HTTPS. Но это, на мой вкус, полумера, к тому же, она не распространяется на DNS.

Технически решение выглядит вполне ожидаемо: виртуальный сервер из Amazon EC2, пакет OpenVPN и BIND, в качестве рекурсивного резолвера на том же сервере. В ноутбуке (на клиентах вообще) – Ubuntu (или другой дистрибутив) и тот же OpenVPN.

Не стану описывать детали настройки, на сайте OpenVPN есть подробное описание и примеры конфигурационных файлов, никаких проблем с тем, чтобы поднять сервер и настроить клиент не возникает. Более того, схема работает даже для клиентских машин под Windows, есть специальная оболочка.

Самый простой вариант настройки VPN это решение типа “точка-точка” с общим секретом (файл с ключом и для сервера, и для клиента). Решение простое, но малоинтересное. Например, потому, что нельзя реализовать одновременное подключение нескольких клиентов к серверу. Поэтому следует использовать вариант с сертификатами SSL. Естественно, покупать какие-то сертификаты для этого не нужно: берём OpenSSL и либо руками, либо при помощи скриптов от OpenVPN, генерируем всё, что нужно. А нужно: сертификат общего удостоверяющего центра, сертификат сервера, сертификаты для всех клиентов.

Другие особенности. Для VPN-сервера нужно взять фиксированный IP-адрес, это позволяет устанавливать соединение, не используя DNS. Я, впрочем, держу А-запись, указывающую на сервер. Так, на всякий случай. В конфигурационных файлах на клиентах, конечно, указан IP-адрес. Кроме того, на клиенте нужно указать и адрес собственного резловера (resolv.conf). Я использую тот же IP – VPN-сервера, потому что всё крутится на нём. На сервере в настройках BIND требуется дополнительно разрешить обработку рекурсивных запросов, приходящих от клиентов OpenVPN. А для того, чтобы трафик ходил наружу, нужно настроить NAT, в моём случае это делается при помощи правил в iptables.

Что мы получаем? Вот что: в результате весь трафик ходит через защищённый канал, который автоматически создаётся при подключении ноутбука к любой внешней сети. Есть потенциальная проблема с фильтрацией пакетов в чужой сети. Поэтому в качестве транспорта для VPN я использую TCP, ходящий на 80-й порт. Такое направление редко где закрыто, потому что, как известно, это HTTP от Веба, а Веб нужен всем. Есть и другие варианты: TCP и 443 (HTTPS) или даже “стандарт” – UDP и 1194, обычно работает.

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

(И, кстати, весь популярный “геотаргетинг” по IP-адресу – ломается. Например, “Яндекс” предлагает мне посмотреть карту Дублина и почитать дублинские новости.)

На прошлой неделе в NY Times появилась статья, в которой очень давно известные элементарные меры обеспечения информационной безопасности преподносят как некий признак разгула “электронного шпионажа”, касательно поездок в Китай и Россию. Вот, к примеру, цитата:

McAfee, the security company, said that if any employee’s device was inspected at the Chinese border, it could never be plugged into McAfee’s network again. Ever. “We just wouldn’t take the risk,” said Simon Hunt, a vice president.

(В компании McAfee, занимающейся вопросами безопасности, сообщили, что если принадлежащее сотруднику электронное устройство “инспектировалось” на китайской границе, его больше не станут подключать к сети McAfee. Никогда. “Мы просто не готовы принять на себя такой риск”, – сказал Simon Hunt, вице-президент.)

Вот, вдруг – вспомнили. Занятно, что наверняка же используют в своей сети устройства, которые ну не то чтобы “исследовались” китайскими пограничниками, а которые вообще произведены в Китае, ага.