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

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 непосредственно перед запуском скрипта, копируя бинарники из основной системы, а потом уничтожать, откопировав оттуда только полученный сертификат.

http://www.zerohedge.com/news/2016-11-26/these-are-48-organizations-now-have-access-every-brits-browsing-history

Тут вот в Великобритании приняли аналог нашего "закона Яровой". Теперь британские провайдеры обязаны хранить историю посещения своими пользователям всяких сайтов. И есть список из 48 государственных организаций, которые имеют право доступа к этому списку.

Год назад я написал про сертификаты от WoSign, что-де это не сертификат, а китайская подделка.
Оказалось, что в каждой шутке есть доля шутки и в этой она очень небольшая.

Mozilla тут собирается перестать доверять WoSign-овским сертификатам.

А тут еще выясняется, что WoSign скупил StartCom, и, следовательно, startssl.com тоже накрывается.

Соответственно, единственным провайдером free ssl certificates становится letsecncrypt, который, на мой взгляд, куда дырявее WoSign и startssl. Но ему почему-то мозилла доверяет.

Есть, конечно, еще cacert.org, но тут мозилла сказала много мата про сертифкат его собственного сайта, хотя я так и не смог понять что там не так с signature algorithm - RSA 4096+sha256.

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

Большинство коммерческих CA хотят за Class 1 сертификат каких-то совершенно немерянных денег, от 70 до 150 долларов в год.

Я пока нашел только sslmate у которого стоимость сертификата сопоставима со стоимость регистрации домена. Правда, тут, как и у letsecrypt предлагается устанавливать на свой сервер специальный софт, для работы с сервером CA. Но, в отличие от letsencrypt беглый взгляд на список зависимостей и на сам скрипт матерных слов у меня не вызвал.

Может кто еще какой сервис подскажет - чтобы бесплатно или меньше 20 долларов в год на домен и из коробки работало во всех распространенных браузерах (необходимость установки intermediate CA сертификата на сервер - допустима. У startssl.com он есть, и ничего, год уже живу).

Представьте себе: идет по телевизору популярный сериал. Рекламная пауза. И вдруг, вместо рекламного ролика на экране появляется широко известный мультяшный персонаж - Баба-Яга там, домовой или леший, быстро произносит качетсвенное проклятие в адрес какого-нибудь миллиардера или политика, вытаскивает куклу оного, втыкает булавку и ролик кончается. Сериал продолжается как ни в чем не бывало.

Через несколько дней проклятый заболевает редкой инфекционной болезнью и умирает.

Расследование выясняет, что на месте ролика с инволтацией должен был ролик, оплаченный покойным.

Кто и как подменил ролик на служебном сервере телецентра выяснить не удается, специалисты центра "К" работают, но без большой надежды на успех.

Анализ голоса, которым прочитано проклятие, приводит к выводу что этот голос синтезирован популярной text to speech программой.

Тут узнал о существовании таких забавных инструментов как password maker и SS64.com password generator.

Идея заключается в следующем - не хранить паролей от сайтов, ни в зашифрованном, ни в каком бы то ни было еще виде, а выводить их при помощи одностороннего криптографического алгоритма из общего для всех сайтов мастер-пароля и URL. Алгоритм выведеня получается простым - вот шелл-скрипт, генерирующий пароль, совместимый с ss64.com (оттуда и взят).

# Bash version
strongpw() {
    read -rs -p 'Encryption key: ' key
    echo '' # line break
    echo -n "$key:$1" | sha256sum | perl -ne "s/([0-9a-f]{2})/print chr hex \$1/gie" | 
       base64 | tr +/ Ea | cut -b 1-20
}

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



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

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

Всякие single sign-on-ы которые вообще-то жизнь упрощают, тут ее вдруг начинают портить.

Так что лучше я пока не будут переходить на эту систему, а потаскаю с собой базу keepass, поскольку уж сейчас-то есть на чем таскать.