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

Вот есть у меня сейчас несколько опенсурсных проектов, которыми может быть стоит заняться, пока не устроился на фулл-тайм работу

1. переписать gost-engine на новый, появившийся в openssl 3.x интерфейс провайдеров.
2. Если уж взялся, за провайдеров то покопаться в pkcs11 провайдере - вдруг там можно малой кровью допилить до поддержки гостовских алгоритмов. Правда плату за это надо требовать с Aktiv, потому что играться я буду с ruToken. А они вряд ли так сильно заинтересованы в этом.
3. Посмотреть что у нас в Postgres с провайдерским интерфейсом openssl и может чего на коммитфест залить на предмет и алгоритмов, и токенов на клиенте. В 18 версию уже не успею, так хоть в 19.
4. По-моему в собственно утилите openssl явно не хватает ключиков для работы с ключами и, особенно, сертификатами на токенах. Но не уверен что пропихнуть соответствующий патчик будет легко даже с помощью beldmit.
5. Написать упрощенный CA для маленьких интранетов. Который будет ориентирован на генерацию ключа вместе с сертификатом, потому что и для внутрикорпоративных сайтов, и для openvpn это основной юз-кейс, когда администратор CA и администратор сайта/VPN - одно лицо. А то что CA.pl, что easy-rsa требуют два движения для получения сертифката - сначала создать ключ и заявку, а потом на заявку выписать сертификат. А здесь основное должен быть даже не код, а лежащий максимально близко к коду, чуть ли не в виде встроенного хелпа учебник по правильному обращению с сертифкатами и ключами. (надо irenedragon попытаться привлечь).
6. Вспомнить про ctypescrypto и переписать ее под 3-е версии и python, и openssl (возможно пригодится для юнит-тестов на провайдеры. А возможно, для юнит-тестов на провайдеры надо портануть ctypescrypto на Platypus )
7. Написать аналог calcurse но с бэкэндом пригодным для синрхронизации vdirsyncer. Под этот проект я даже когда-то репозиторий завел.
8. Была у меня еще идея про линуксовый management interface для openvpn Правда из-за отсутствия у меня теперь необходимости ходить в конторскую openvpn оно как-то менее актуально стало.
9. vws тоже надо бы переписать с нуля под третий питон и девятый qemu. Но может стоит подождать пока 12-й qemu выйдет.

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

В наше время когда бэкапы зачастую делаются на всякие s3 и прочие cloud services криптографиеская защита бэкапа еще более актуальна.

И тут возникает мысль шифровать бэкап открытым ключом ssh. А программа восстановления из бэкапа чтобы понимала протокол ssh-agent.(естественно на самом деле бэкап шифруется случайным симметричным сессиононным ключом, а уже тот с помощью RSA или с помощью общего ключа, выработанного на открытом ключе реципиента и приватном от эфемерной ключевой пары Cм описание EnveloedData )

Т.е. получается полностью прозрачная схема - при бэкапе используется содержимое authorized_keys админа(ов). А при восстановлении, если кто-то из тех чьи ключи были использованы при шифровании, заходит выполнять команду восстановления по ssh с agent forwarding, то ему даже и задуматься не придется о том, что бэкап расшифрован. А вот любому другому - хрен.

Правда, воспользоваться форматом cms не удастся. Ибо у нас тут не сертификаты x509, а ключи ssh, которые идентифицируются в агенте немножко по-другому. Ну так формат нарисовать дело нехитрое.

X-Post to LJ

Upd*: Как отметил tanriol ничего не получится. Нет в протколе ssh-agent команды session key decrypt. У gpg-агента есть, но у него с форвардингом сложности.

Поисследовал немножко вопрос перевода своей VPN с openvpn на sstp. sstp это фактически ppp over tls. То есть отличить это от веб-траффика существенно менее реально. Правда, наиболее распространенной реализацией sstp-сервера пол linux является softether на который у меня аллергия. Он какой-то цисковский по всей идеологии. а не юниксовый.

Правда, существует еще sstpd. Но он вообще на питоне написан. Зато, правда. заточен на работу за полноценным веб-сервером в качестве frontend-proxy.

Кроме этого вопроса с реализациями у SSTP есть проблема с аутентификацией Почему-то не поддерживается в sstpc аутентификация по клиентским сертификатам. Хотя вроде у микрософта в RAS она была. А тут вся аутентификация спихнута на pppd. А в пароли я как-то не верю в наше время. Даже в CHAP.

Upd Оказывается, в linux-овом pppd версии 2.4.9 и выше поддержка EAP-TLS, в том числе и с использованием аппаратных токенгов все же есть. Правда. исключительно хреново документирована.

Тут возникла идея для защиты от блокировки openvpn посредством dpi использвать openvpn-xor патч. Поглядел я на этот патч и у меня возникло устойчивое впечатление что от данной поделки надо держаться подальше

Обсуждение патча на сайте людей которые его распростнаяют со своим продуктом содержит следующие моменты

1) As the OpenVPN developers point out, the patch has never been through a thorough review for security, coding, etc. However, a Tunnelblick developer has reviewed the patch, found some problems, and modified it in Tunnelblick to resolve those problems. The problems that were found and fixed involved insufficient parameter validation, null pointer dereferences, division by zero errors, and a buffer overflow. Some defensive programming was also added to the modified version of the patch to increase its robustness.

2) The original post proposing the patch claims that using the patch is sufficient to secure communications and that no other encryption is necessary:

"With this obfuscate option, I think that it is ok to use "cipher none", because working out the method used would take a lot of cryptoanalysis. The obfuscate option is also much easier on the CPU than any cipher options This is incase you are using ddwrt or openwrt or have a low speed cpu."

Do not take this advice! The obfuscation provided by this patch appears to be extremely rudimentary. Beware of cryptographic advice from amateur cryptographers!

Сам патч при этом близок к тривиальному см исправленную версию. При этом попатчить man-страницу, добавив описание опции scramble не осилил ни оригинальный автор, ни разработчики tunnelblick.

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

Основной мой резон, почему мне не нравится идея применить этот патч - это правило 13-удара часов. "Если часы бьют 13 раз, то это заставляет сомневаться не только в 13 ударе, но и в остальных 12".

Если автор сумел насажать буфер оверфлоу в таком простеньком патче, то может ну его всё-таки нафиг, пользоваться его творчеством. Хотя говорят, Великий Китайский Файрволл пробивает по-прежнему, несмотря на то, что патчу уже больше 10 лет.

X-Post to LJ

Коллеги, а как правильно снять ascii-armor с GPG-шного ключа, пользясь только coreutils?

У меня получилось вот так:

sed -n '/^$/,/=$/p' public_key.asc |base64 -d> public_key.gpg

Но мне самом это решение не нравится, потому что вообще говоря никто не обещал, что в последней строчке base64 будет '=' на конце. Если размер бинарного файла случайно получится кратным 3, его там не будет. И то что последняя строка будет короче предыдущей - тоже никто не обещал.

Контекст задачи следующий - есть скрипт подключения репозиториев. Он поддерживает три десятка разных дистрибутиов - и redhat-подобные. и sles, и debian-подобные. И, естетсвенно носит в себе ключ для проверки подписей под метаинформацией или пакетами. Носит его в ascii-armored виде, так как rpm-y его именно в таком виде скармливать надо. А в debian и ubuntu после того, как решили отказаться от apt-key, ключи в /etc/apt/trusted.gpg.d надо класть в бинарном формате. При этом у меня почему-то имеется упорное впечатление что shell у нас не 8-bit clean, и не надо без base64 закладывать ключи в скрипт. При этом наличия полнофункциональногп gpg на системе, куда будет подключаться репозиторий (весьма вероятно это будет какой-нибудь минимальный контейнер) никто не обещал. Только gpgv, которы ключи менеджить не умеет.

К сожалению, формат GPG ascii armor это не pem, где бы вопрос решался условием '/-----BEGIN/,/----END'. Впрочем. в pem в наше время тоже норовят напихать какой-нибудь гадости в виде MIME-пододных заголовков после ----BEGIN (См например ближайший секретный ключ ssh). Но в GPG-шном ключе почеу-то после основного base64 блока присутствует маленький второй, на который base64 из coreutils реагирует болезненно.

Upd Как написано в RFC2240 этот хвост всегда начинается с = Поэтому вот такой скрипт будет лучше работать:

sed -n '/^$/,/^=/{
s/^=.*$//
p
}' public_key.asc |base64 -d > public_key.gpg

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

Вот думаю, а не перейти ли мне с openvpn на wiregard для создания приватной сети, объединяющей мои компьютеры.Преимущества wireguard - бо́льшая скорость, более простая ключевая инфраструктура, меньше любителей резать протокол на файволлах.

Недостатки - более простая ключевая инфраструктура, требующая дописывания в конфиг на сервере всех peer-ов. С openvpn-то в этом плане всё просто - предъявил peer при коннекте сертификат, подписанный УЦ, которому сервер доверяет, и сервер его пустил. Еще и в DNS оно само прописывается. Потребности в отзыве сертификатов VPN-клиентов у меня пока не возникало, хотя я знаю как это делается. У wg конечно отлучить клиента от сети проще - никаких crl-ей не надо, выкинул его ключ из конфига сервера и всё. Кроме того, жесткая завязка на протокол. openvpn умеет udp, умеет tcp, умеет делить порт с веб-сервером, умеет ходить через прокси. В общем варианты обхода резки на файрволлах там многообразны.

Кстати, я вот если я вдруг соберусь перейти на wireguard, мне мой личный удостоверяющий центр X.509 совсем перестанет быть нужным. Сейчас у меня все сервисы на wagner.pp.ru (web, jabber, smtp, imap) используют let's encrypt-овские сертификаты. Хотя это и менее секьюрно и подтверждать смену сертификата (вернее двух imap и smtp) в почтовом клиенте на каждой машине, где он у меня стоит, приходится раз в квартал.

Локальные postfix-ы (которые у меня по-прежнему есть на десктопе и на всех ноутбуках) уже давно перешли с авторизации у сервера по сертификатам на парольную. (впрочем, локальные постфиксы надо вообще обязать ходить по smtp внутри VPN и там их пускать без SSL и авторизации). Остается, пожалуй только локальный веб-сервер, который для тестовых целей на десктопе. Но в принципе, и на него можно летсэнкриптовский сертификат получать. Надо только отдавать letsencrypt-у для него AAAA запись и не отдавать A. Дома-то у меня провайдер IPV6 поддерживает.

Вот интересно, реально ли для ноутбуков, которые заметную часть времени проводят в сетях, где ipv6 нет, сделать wireguard-овскую vpn окном в ipv6 мир. в принципе ничто не мешает раздать им адреса из какой-нибудь /112 или даже /80 подсетки той /64 которая у меня на сервере есть. Благо в конфиге wg все равно пишутся конкретные адреса. А роутить ::/0 через wireguard - штатное и рекомендуемое поведение, благо будучи ядерным модулем, он как-то сам разбирается где его пакеты, а где остальное.

Тонкость тут заключается в том, чтобы заметить, выдали ли в локальной сети ноутбуку globally routable ipv6 адрес или нет. И если не выдали сделать wireguard-овский сервер дефолтным route для ipv6. Еще желательно это уметь делать вручную. На случай если вдруг выяснится что в данной сети есть нехорошие ipv6 firewall-ы.

Интересно, правда, как это уживется с dyngo. Не придется ли туда какую-нибудь извращенную логику дописывать, чтобы соображало какой из двух адресов слать на сервер, чтобы тот создал AAAA-запись, соответствующую более подходящему ipv6-адресу? В смысле тому, на который по ssh пустят. Или наплевать, и всегда ходить через wireguard, считая его оверхед пренебрежимо малым?

Я как-то придумал эту идею и хотел реализовать на какой-то ролевой игре. Но так и не собрался.

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

Предлааемое решение - некая n+1 сторона привозит и продает руководителям этих n партий шифроблокноты. Блокноты - пронумерованы. И в каждом n (лучше n+m, есть несколько запасных блокнотов на случай компрометации или утраты) страниц.

Каждая страница представляет собой поворотную решётку 10x10 или 12x12. Соответсвенно, если мы хотим отправить письмо владельцу блокнота i (а список владельцев доверенная сторона-организатор сети распространяет по своим абонентам абсолютно открыто. Более того, если список сторон известен заранее. его можно прям на форзаце напечать, а там уже вопрос только в том, выкупила соответсвующая партия свой блокнот или нет), мы открываем i-тую страницу нашего блокнота и шифруем этой решеткой письмо.

Получаетель письма смотрит список абонентов, находит там нас (j) открывает j-тую страницу своего блокнота и расшифровыает посление.

n+1 сторона-организатор криптосети мамой клянется, что у неё нет копий решёток, содержащихся в проданных блокнотах.

n, кстати, может быть достаточно большим. Количество возможных решеток равно 4^m2/4 где m - сторона квадрата, т.е для решетки 10x10 - 2⁵⁰. А число нужных для шифрования решеток (n²-n)/2. Так что можно еще и при генерации решеток спокойно выкидывать те, у которых расположение дырок не обеспечивает механической прочности или слишком много подряд идущих дырок, позволяющих увидеть кусок открытого текста.

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

( Генератор решеток )

Купил Ирине новый ноутбук - вместо того Dell, которому было уже 4 года. Asus FX506LI. Продавец меня предупреждал "А вы точно справитесь с установкой винды? Может доплатите немножко мы ее вам поставим". Я не поверил, что не справлюсь, но оказалось именно так.

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

В общем, повозившись вечер, плюнул и поставил туда Debian Bullseye. Правда, выяснилось что с ядром 5.10 MEDIATEC-овский wifi не работает, надо из testing тащить 5.14. А с ним не компилируются имеющиеся в дистрибутиве проприетарные драйвера NVIDIA. (правда, сегодня вроде в unstable уже появилися исправленный пакет, но пока у меня работает с поправленным вручную dkms.conf).

Поскольку я первый раз ставил Debian 11 с нуля, а не посредством dist-upgrade, да к тому же и на машину с UEFI, для меня некоторой неожиданнсотью было появление kernel_lockdown. Ну в общем, оказалась относительно вменяемая фича, с возможностью нормально установить machine owner key, и подписать самособранный модуль.

Конечно система еще сырая и там нет возможности, например, организовать автоматический trusted path от мейтенйнера пакета с DKMS-модулем до загрузки этого модуля в ядро. (это, по-моему, не реально без подписи user-space бинарников, а bsign у нас пока в диструбитив не вернулся). Но в принципе потенциал у решения есть.

Про rot13 все знают. А вот про rot8000. Оно превращает русский или английский в китайский (ну или то, что европеец может принять за китайский). В какую смесь европейских алфавитов превратистя реальный китайский текст даже подумать страшно...

А тем временем OpenSSL выпустила версию 3.0.0 Еще вчера была актуальна 1.1.1, а сегодня уже 3.0.0. Любят они проскакивать номер. Ну ладно, после 0.98 вместо 0.99 сразу 1.0 выпустили. Но после 1.1.1 сразу 3.0.0...