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

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

Видео:

Проект называется EXACTO. (Источник.)

На dxdt.ru появлялись заметки об управляемых (а также – о корректируемых и самонаводящихся) пулях, вот некоторые из них:

• Управление пулей влёт;
• Полёт и наблюдение пули;
• Управление пулями, баллистика;
• Самонаводящиеся пули: один из проектов;
• Пули точно в цель.

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

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

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

Хэш-функция SHA-1 уже несколько лет считается недостаточно стойкой для использования в подписях SSL-сертификатов. Сейчас идёт процесс вытеснения этой функции из действующих сертификатов, но пока что таких сертификатов много, они встречаются сплошь и рядом. Использование SHA-1 приводит к “неожиданным” эффектам в браузерах. Посмотрим на один из примеров – сайт nic.ru.

На сервере, где расположен nic.ru, установлен валидный сертификат с расширенной проверкой (EV). Однако если зайти на сайт при помощи браузера Chrome (42.0.2311.90 – актуальная на момент написания заметки версия), работающего в среде операционной системы Windows (версии 8.1, например), то в адресной строке браузера появляется предупреждение о том, что сайт использует устаревшие технологии безопасности. Выглядит это так:

Естественно, ожидается, что корректно установленный EV-сертификат приведёт к другому эффекту, отобразив “доверенную” адресную строку. Так происходит в браузере Internet Explorer 10, на той же тестовой машине:

А если воспользоваться браузером Mozilla Firefox, то эффект тоже положительный:

Впрочем, положительный эффект в Firefox имеет под собой другую почву, нежели случай IE. Что происходит, почему браузеры ведут себя именно так?

Посмотрим на набор сертификатов, возвращаемых сервером. Здесь есть три сертификата: серверный и два промежуточных; вот их свойства, указанные в полях Subject (s, предмет сертификации) и Issuer (i, удостоверяющая сторона):

0.
s:O=JSC ‘RU-CENTER’/OU=Project Department/CN=www.nic.ru
i:O=GeoTrust Inc./CN=GeoTrust EV SSL CA – G4

1.
s:O=GeoTrust Inc./CN=GeoTrust EV SSL CA – G4
i:O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority

2.
s:O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority
i:O=Equifax/OU=Equifax Secure Certificate Authority

(Имя nic.ru без www. указано в расширении SAN сертификата, так что адреса на скриншотах – корректны.)

Проблемным является сертификат под номером 2 (выпущенный для GeoTrust Primary Certification Authority), так как он использует SHA-1 в составе алгоритма генерации подписи. Согласно политике Google Chrome, если в цепочку сертификатов (исключая корень) входит хотя бы один, подписанный с использованием SHA-1, то в адресной строке выводится предупреждение. Посмотрим на цепочку:

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

А вот Firefox использует собственный набор корней, поэтому цепочка валидации тут иная:

Firefox содержит доверенный корень, обозначенный как GeoTrust Primary Certification Authority, от которого подписан промежуточный сертификат GeoTrust EV SSL CA – G4. То есть, те же сертификаты уже выстраиваются в цепочку, которая не содержит SHA-1, поэтому данная ситуация не может вызвать предупреждения, даже если бы такое предупреждение поддерживалось Firefox. Аналогично устроен и Google Chrome под Linux – там тоже встроен корень, позволяющий избежать использования промежуточного сертификата с SHA-1.

Выше я упомянул о том, что присутствие SHA-1 не учитывается для корневых сертификатов (встроенных в браузеры). Почему? Причина в том, что корневые сертификаты самоподписанные (по определению), а браузер доверяет не подписи, а открытому ключу, связанному с корневым сертификатом, и имени удостоверяющего центра, которое указано в сертификате. Раз подпись не играет ключевой роли, то и использованием SHA-1 в корневом сертификате можно пренебречь: оно никак не влияет на уровень доверия.

Что нужно делать веб-сайтам? Нужно перевыпускать сертификат в цепочке, которая не использует SHA-1.

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

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

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

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

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

Сейчас из некоторых российских сетей недоступны NS-ы GoDaddy, например, вот эти: ns20.domaincontrol.com, ns19.domaincontrol.com. На данные серверы имён делегировано много доменов, соответственно, как только завершится время кэширования, сайты под такими доменами станут недоступны для пользователей российских провайдеров. Из США и Европы – пока что всё работает, серверы “Премиум-DNS” GoDaddy – тоже доступны, пока что. Но, возможно, это авария, ну или ошибка в настройках маршрутизации (как обычно бывает).

Update (17/04/15): исправили; проблема наблюдалась для нескольких групп серверов, и не только для России.

Первая ступень ракеты-носителя Falcon 9 снова совершила жёсткую посадку на плавучую платформу: ступень опрокинулась после достаточно сильного удара о платформу. Но, вроде бы, дела обстоят лучше, чем в прошлый раз.

US-CERT распространил новое предупреждение об угрозе: “трансфер зоны DNS может раскрыть информацию о домене“. Это довольно странно, потому что известно очень много лет, соответственно – какая новая угроза? (В предупреждении, впрочем, сказано, что причина в большом распространении серверов, разрешающих трансфер зроны для всех желающих.)

Запросы AXFR (Asynchronous Transfer Full Range) – трансфер зоны – позволяют получить с сервера имён полный список записей в зоне DNS, то есть, фактически, увидеть все настройки адресации домена. Эти запросы используются для передачи сведений между разными авторитативными серверами, поддерживающими зону, а также в других случаях. Разумное толкование подсказывает, что все данные, публикуемые в глобальной DNS, должны являться публичными, по определению. Те не менее, доступ на трансфер зоны обычно ограничивают некоторыми доверенными серверами, чтобы не всякий мог скачать всю зону одним запросом, а только те узлы, которым это нужно. Так делается много лет.

Вообще, споры о том, нужно ли считать угрозой возможность получения полного (или близкого к полному) списка записей в той или иной доменной зоне – идут уже сильно дольше десяти лет. Например, этот момент повлиял на технологию DNSSEC. Для того, чтобы подтвердить, что записи для некоторого имени не существует, в DNSSEC нужно передавать в ответ на запрос указание на “ближайшую” существующую запись (на имя записи). Изначально разработчики DNSSEC пошли по “открытому пути” и предложили решение с записями NSEC, которые, в ответ на запрос о несуществующем имени, просто включают одно из имён в зоне, в открытом виде. Естественно, это позволяет быстро перебрать все записи и получить полный список имён, реконструировав зону. Защитники “безопасности через сокрытие” выставили кучу возражений, в результате появилось расширение NSEC3, где ответы содержат не сами имена, а значения хеш-функций, что делает перебор вычислительно трудным.

Так вот теперь, похоже, нужно ждать свежего “открытия” “угрозы” раскрытия списка имён доменной зоны через NSEC в технологии DNSSEC. Хотя, DNSSEC пока что не имеет должного распространения.

Существуют EV-сертификаты для TLS. Это сертификаты с расширенной проверкой организации, для домена которой выпускается сертификат. Технически, они такие же, как и обычные, но красят адресную строку в некоторых браузерах в зелёный цвет. Теперь для EV-сертификатов нужна поддержка Certificate Transparency (согласно рекомендациям разработчиков браузеров; сейчас требование актуально только для линейки Google Chrome). Посмотрим, как это выглядит на практике, для пользователя браузера Chrome (англоязычный интерфейс). Для примера я возьму сайт интернет-банка “Альфа-банка”. Сведения о статусе аудита Certificate Transparency (CT) отображаются в выпадающем окошке, по клику на название организации в адресной строке браузера:

Наличие строки Transparency information говорит о том, что в сертификате содержатся записи из логов CT. По клику открывается окно с дополнительной информацией:

О чём данные из этого окна говорят типичному пользователю? Да, к сожалению, ни о чём. Разобраться в них сложнее, чем в структуре сертификата, потому что для понимания требуется знание того, как работает технология CT. Ну, разве что, можно обратить внимание на то, что указана дата, когда сертификат был внесён в лог (в нашем случае эта дата совпадает с датой начала действия сертификата), да и на то, что наличие сертификата в логе подтверждено подписями (статус Verified), а это означает, что данный сертификат, скорее всего, был действительно выпущен для указанного сервера, согласно соответствующим процедурам.

Сведения о включении сертифката в лог CT содержатся в самом сертификате, для этого в расширения X.509 внесено специальное поле:

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

Сейчас корни китайского УЦ CNNIC не поддерживается браузерами (Chrome и Firefox) в полном объёме, это результат истории с выпуском “перехватывающих” промежуточных сертификатов. Google ставит в качестве условия возврата доверия CNNIC-у – полную поддержку Certificate Transparency (CT). Интересно, что если CNNIC такую поддержку реализует, то это будет первый УЦ, который реализовал CT в полном масштабе даже не потому, что есть RFC, а лишь под давлением разработчиков браузеров.