Журнал Витуса

http://www.cbc.ca/news/technology/tapdance-refraction-networking-decoy-routing-test-usenix-1.4249177

Забавная технология для того чтобы обеспечить жителям стран с репрессивными режимами доступ к заблокированному контенту.

Работать, правда, будет при условии, что большая часть мира управляется нерепрессивными режимами, которые не только ничего не блокируют, но и всячески поддерживают своих ISP по части преодоления блокировок.
Как раз в выполнение этого условия верится с трудом.

https://www.reuters.com/article/us-shipping-gps-cyber-idUSKBN1AN0HT

Из-за распорстранившейся практики глушения и подделки сигнала GPS разные страны рассматривают идею возвращения к наземным радионавигационным системам. Потому что передатчик Лорана находится на порядки блихе к судну, чем спутник GPS, ну и излучает куда более мощный сигнал. Имея антенну 100x100 метров и питание от электрической распределительной сети, это можно себе позволить. Такое карманной глушилкой уже не заглушишь.

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

В отличие от ToX там предусмотрена штатная возможнсоть подключения к аккаунту нескольких устройств. У меня, правда, не получилось - андроидный Ring после импорта туда аккаунта, созданного на десктопе, стал падать.

Попробовать с кем-то пообщаться пока не получилось потому что не с кем. Не знаю никого, кто бы из знакомых имел там аккаунт.

Выяснилось, что stretch я похвалить немного поторопился.

Как оказалось он молча, без вопросов апгрейдит keepass 0.43 на keepass 2.0.3.

Засада в том, что keepass <2 и keepass 2.x это программы у которых нет ничего общего, кроме названия и назначения.

Например, несовместим формат файлов. То есть keepass 2.x умеет один раз симпортировать базу от 1.x но записать обратно - уже никак.

А я держу keepass в качестве менеджера паролей ровно потому что он позволяет копировать базу как файл между разными устройствами с разными операционными системами. Поэтому ситуация когда на одном устройстве один формат, на другом другой - меня категорически не устраивает.

Поставил пока пакеты из jessie на hold. И думаю - стоит переходить на keepass 2.x
или не стоит?

Что-то мне все андроидные клиенты, совместимые с keepass2 вызывают подозрение:

У keepass2android интерфейс переписан с java на mono. Это для андроид-то!
KeePassMob содержит в себе код работы с сетью (dropbox), что по-моему для пассворд-менеджера под андроид категорически недопустимо. Поскольку уж если в этой дырявой системе есть способ защититься от доступа в сеть, то именно пассворд-менеджер обязан это сделать.

Поэтому я думаю о том, что может быть стоит еще какой password-manager поискать.

Требования:

1. Наличие клиентов для linux и android
2. Приемлемая usability для android, у которого жутко неудобная работа с clipboard
3. Приемлемая юзабилити под X11.
4. Возможность копирования базы паролей с устройства на устройство как файла по ЛЮБОМУ
протоколу передачи файлов scp, obex, smb.
5. Наличие в базе хотя бы пары дополнительных колонок кроме имя и пароль.
В качестве бонусов:
5. Команд-лайн интерфейс под linux.
6. Возможность хранения базы паролей в version control.

https://thenextweb.com/eu/2017/06/09/pirate-bay-founder-weve-lost-the-internet-its-all-about-damage-control-now/

Интервью с Петером Сунде, одним из основателей The Pirate Bay, в котором тот признает поражение децентрализованного и свободного интернета 90-х перед огромными централизованными корпорациями.

Впрочем, признаки поражения я замечал еще в 2011 году.

Что-то я не нашел очевидного (казалось бы) решения по защите хранящегося на (хостинговом, доступном всяким нехорошим людям) сервере почтового архива, которое бы работало так:

1. В распоряжении MDA есть открытый ключ gpg/сертификат X,509 для каждого пользователя.
2. Любое письмо, прилетающее по SMTP (в наше время в норме защищенное TLS по дороге) шифруется этим ключом конечного получателя перед тем, как сложиться в его maildir (но после того как оно прошло через фильтры sieve). Ну да, сеансовый ключ придется каждый раз генерировать. Ну и что?
3. В распоряжении IMAP-сервера есть зашифрованный приватный ключ. Когда пользователь логинится на IMAP-сервер, его аутентификация производится путем расшифровки этого ключа. После этого можно любую хранящуюся почту расшифровывать и пользователю выдавать.


Причем шифровать письма совершенно спокойно можно вместе с заголовками.
То есть и метаинформацию without user consent хрен достанешь.

Модификации требуемые для IMAP-сервера достаточно тривиальные.


Но почему-то никто так не сделал. Во всяком случае я такого не нашел.

Вместо этого предлагаются решения на базе двух мейлбоксов секьюрного и несекьюрного. С тем чтобы складывать в секьюрный мейлбокс можно было тоже только при наличии активной сессии.

Видиом, идея full-disk encryption (каковая есть зло) людям глаза застит. В то время как никто не мешает maildir шифровать пофайлово.

Правда, немножко непонятно как быть с тренировкой байесовского антиспама в такой ситуации. Ну ладно, допустим ham мы будем в sa-learn скармливать непосредственно в ходе сессии, когда мы его можем расширфровать (а спам и шифровать не обязательно). Но не явится ли байесовская база, которая должна быть доступна на чтение MDA каналом утечки информации?

https://www.schneier.com/blog/archives/2017/03/security_orches.html

У Шнайера интересный и обширный пост на тему того, почему не работают стандартные методы упорядочивания и автоматизации в военном деле и в области реагирования на инциденты в компьютерной безопасности.

Он делает вывод что централизация и предваарительное планирование рулят в том случае, если у нас есть определенность (certainity), а там где есть неопределенность, нужны децентралиаация и инициатива.

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

Кстати, по-моему это касается не только тех случаев, когда адаптивностью и инициативой обладает враг. Даже если контрагент тебе не враг, как не враг upstream-разработчик мейнтейнеру пакета, неопределенность он все равно вносит. Из самых благих побуждений. И попытка с этим бороться путем стандартизации процедур приведет только к тому, что ты не сможешь embrace the changes (как это по-русски сказать?) и сделаешь хуже.

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

Уже вторая новость за несколько дней выглядит как

1. У кого-то крадут ноутбук, на котором установлен какой-то софт для удаленного управления.
2. Вор, не переставляя системы, логинится с украденного ноутбука в свой Facebook.
3, Хозяин ноутбука или полицейский эксперт заходит в украденную машинку по сети, получает доступ к этому фейсбук-профайлу, и посредством содержащейся в нем информации карает преступника (в одном случае - затроллил его через друзей до удаления аккаунта, в другом - вычислил реальное имя и сдал полиции).

Мораль - только полный идиот в наше время ворует ноутбуки из машин. (умный - ворует информацию из ноутбуков так, чтобы никто не заметил).

И зарегистрировал компанию.

via Шнайер.

UpdCудя по URL beta.companieshouse.gov.uk, это тестовый сайт, где тестируют новый движок системы регистрации. И компания специально заведена с таким именем, чтобы проверить работу input sanitizing.

Продолжаю разбираться с letsencrypt. Понятно что это гадость. вроде systemd, но деваться некуда. Все альтернативные бесплатые CA за этот год были успешно уничтожены.

Обнаружил, что автор acme-tiny рекомендует по крону повторно выписывать сертификат на тот же самый ключ.

По-моему, в этом вопросе он глубоко неправ. Плтому что с точки зрения пользователя сайта смена сертификата и смена ключа полностью эквивалентны. Браузер не смотрит на ключ, браузер смотрит на то, что ключ соответствует указанному в сертификате.

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

Правда, как обычно, идея перегенерации ключа по крону несет свои собственные риски.
В текущем виде acme-tiny требует доступа только к ключу аккаунта на letsencrypt и к CSR. То есть скрипт, активно работающий с сетью и теоретически могущий быть проэксплойченным через дырки в стандартной библиотеке питона, самом питоне и libc, не имеет доступа к вашему закрытому ключу.

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

То есть нужно аккуратно поделить задачу на три части

1. Сгенерировать новый закрытый ключ и CSR. В принципе, для этого никаких прав не нужно. Нужно только не пересекаться по правам с шагом 2, чтобы у того доступа к закрытому ключу не было. С другой стороны, поскольку эта операция ничего особо принципиального не делает, только пишет в файлики в формате pem, то не жалко и от рута запускать.

2. Посредством acme-tiny или еще какого auditable клиента к letsencrypt получить сертификат.

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

Обдумывал мысль, как бы запихнуть операцию 2 в chroot но решил что для acme-tiny это явно не вариант - в chroot придется тащить всю питоновскую инфраструктуру. Пожалуй, с dehydrated это бы лучше получилось.

Идея, естественно в том, чтобы создавать дерево с бинарниками для chroot непосредственно перед запуском скрипта, копируя бинарники из основной системы, а потом уничтожать, откопировав оттуда только полученный сертификат.