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

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

А пока суд да дело, заведу-ка я себе еще один gpg-ключик. Вот такой:

-----BEGIN PGP PUBLIC KEY BLOCK-----

mG8EYEBz8hMFK4EEACIDAwTNf5AmxCx5W156BwJP7mpqW/0SO9byzm403ZSAfHWG
yjhlxEN2yiUKg1GaEJQw9scysZzd5PafTHeha3h6tHEfPpl928wSHy77W1wqfQ+n
8uUcJ/mrA7mYDmS3yhW3Vae0M1ZpY3RvciBXYWduZXIgKGVsbGlwdGljIGN1cnZl
KSA8dml0dXNAd2FnbmVyLnBwLnJ1PoiwBBMTCQA4FiEEMu3qE554kVqP2qlR1wmX
0G4GBQ0FAmBAc/ICGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1wmX0G4G
BQ02TQGAsdgIcn6w7pBZwNG3497GkfPDXJ5dv67acWw4cH9rCCPC5qD/4kAoe5Hs
DO01ApkZAX4h8zmqsG8g3q//rELDjoKrcUopIyi+LWbWXSA9/ga8ZUnphzem5/EJ
w6RUdrqZ8WC4cwRgQHPyEgUrgQQAIgMDBCQ7PY4n9u9EkkySjXx4jOH8QxoAyCEP
+GXDlOaRWnjxKDsoaSMey8T7MMeczoF8RCvDLHifKg2LKNbtpZy6eWAEhhD/Agej
5JzMh5gfT1epc65Y8SjeBzPONSlG0NOKMgMBCQiImAQYEwkAIBYhBDLt6hOeeJFa
j9qpUdcJl9BuBgUNBQJgQHPyAhsMAAoJENcJl9BuBgUNjb4BgLVR/djAOzzO/TzQ
fuBb4i69owWVB+AuJ5rut6u2N+aaT9V9pwlPJuxj7JsKrmliiwF+N2m2Toviod2B
tLncO/yuNxQg9V8PjRb3tRRPYVIZwyIal3Ld64hoyPN3LU1WUX7N
=l2bi
-----END PGP PUBLIC KEY BLOCK-----

1. Когда прикручивал резервное копирование к новой Raspberry PI, обнаружил что у меня оказывается уже больше года не бэкапится архив фотографий с VPS - с тех самых пор, как он переехал на отдельный виртуальный диск. Пришлось переделывать бэкап-скрипт для серверов, чтобы умел бэкапить не только корневую файловую систему. А то у меня там --one-file-system везде стоит, чтобы всякие sys и proc не мешались.

2. Ухитрился протоптать обновление сертификатов с Let's Encrypt. У меня оно устроено так - каждую ночь запускается кроновское задание, смотрит, есть ли сертификаты, которым осталось меньше недели до истечения срока действия, и если такие найдутся, запрашивает на эти домены новые. Перед установкой нового сертификата его всячески проверяет, чтобы сервис, его использующий, не оказался нерабочим. Эти проверки-то меня и подвели.

После обновления acme_tiny она теперь заботится о формировании цепочки доверия сама. И что-то там у Let's encrypt поменялось. Соответственно со старым файлом itermediate сертификатов оно не проверяется. Теперь нужно проверять командой

 openssl verify -untrusted filename.crt filename.crt

Т.е в качестве источнинка промежуточных сертифкатов использовать сам же проверяемый файл.

А у меня при непрохождении проверки удалялся не прошедший проверку сертификат и оставлялся старый. И так пять раз. На шестой день Let's Encrypt возмутился "что ты шестой раз подряд на один и тот же домен сертификат запрашиваешь? Приходи на следующей неделе".

И только в этот момент я обратил внимание на почту от крона. (и отключил задание, чтобы больше зря попыток не тратило)

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

Надо бы переписать скрипт деплоймента сертификатов, чтобы в subject письма писал важную информацию, в частности успех или неудачу.

Никто даже и не подумал в правильном направлении. Поставлю подсказку в виде тэга.

Я до сих пор всегда выкладывал свой открытй ключ gpg на своей домашней странице и считал что этого достаточно.

Ну и на какие-то кейсервера тоже его когда-то засабмитил, не помню уже.

А тут я выяснил что, оказывается, весь прогрессивный мир давно уже применяет протоколы публикации ключей, позволяющие владельцу если не ключа, то домена, в котором у владельца ключа e-mail, весь процесс контролировать.

По этому поводу настроил себе публикацию ключа через DANE и WKD.

Подумал, а не добавить ли к этому ключи идентичность vitus@spacians.net, благо этот домен я тоже контролирую. Но пока не стал.

https://www.schneier.com/blog/archives/2019/10/dark_web_site_t.html

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

Хотя тут наоборот, все прозранчо, все подписано.

Завел себе новый GPG-ключ.
А то как-то в 2018 году пользоваться ключом с 1024-битным DSA (который по определению для хэширования только sha-1 может использовать) некузяво.

fingerprint 146E 1042 1041 F57D 8A85 8B8E 2CA8 1D40 F4AA 65EC

Новый ключ опубликован на keys.gnupg.net подписанный старым. Чтобы цепочка доверия хоть как-то выстраивалась.

lumag тут завел на гитхабе проект для системы подписывания ELF-бинарников. (кстати, лично мне непонятно почему gnutls, а не openssl или libnss, в которых код работы с X509 куда более mature).

А я подумал и пришел к выводу, что существует достаточно простое решение для того, чтобы подписывать не только бинарники, но и скрипты.

Почти все скриптовые языки, распространенные в наше время, поддерживают однострочные комментарии, начинающиеся со знака #.

Следовательно если в начало файла (в идеале сразу после шебанга), вставить блок комментариев, содержащих pem-энкодед PKCS7 подпись, выполняться оно будет точно также (ну там еще в питоне нужно позволить до подписи encoding указывать). Ну и проверить подпись тоже не слишком сложно - сначала хэшируем те строчки, которые до

# ----BEGIN PKCS7-----

пототом те, что после

# -----END PKCS7-----

Надо вообще тестовую реализацию наваять на питоне с ctypescrypto. Хотя боевая реализация должна быть на C и подписанным elf-бинарником. В принципе, можно сделать такой проверяющий враппер для интерпретаторов, который будет передавать интерпертатору открытый файловый дескриптор проверенным скриптом, вроде того, как раньше suidperl работал, и запускать эту систему там, где поддержки подписей на уровне ядра нет.

P.S. А еще можно подписывать JAR-файлы.

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

Поскольку все равно выходные, и я еще не настолько выздоровел, чтобы носиться колбасой по лесам, собрался и таки сделал ctypescrypto совместимым с python3.

Ну во всяком случае тесты проходят. В одном месте, правда пришлось изменить поведение.
Функция repr от объекта X509 теперь возвращает конструкцию, содержащую pem, а не der-представление сертификата.

А так в основном обошлось конструкициями вида

 
   def __bytes__(self): 
       ...
   def __unicode__(self):
       ...
   if sys.version[0]=='2':
       __str__ = __bytes__
   else:
       __str__ = __unicode__

и определением своих названий для того, что проверяется в isinstance.
В одном месте сделал

    if sys.version[0]=='2':
        bintype = str
        chartype = unicode
        inttype = (int, long)
     else:
        bintype = bytes
        chartype = str
        inttype = int

ну и в дальнейшем этими переменными пользуюсь.

Еще была идея определить несколько декораторов для фукнций, которые должны возвращать
строку. Чтобы в python2 они возвращали то, что вернула сишная функция как есть, а в python3 конвертили из того, что указано аргументом в юникод. Поскольку у меня, как правило, очевидно откуда конвертить - если на выходе pem или какой идентификатор алгоритма, его из ascii, если поле asn1-структуры или пароль - из utf-8.

Но пока не собрался.

Новой версии пока не выпускал. Сначала надо проверить, не сломал ли я что на Windows и 32-битных архитектурах.

А еще стал отваливаться один тест на верификацию сертификата. Когда я этот тест писал и генерировал для него сертификаты, алгоритм SHA1 считался вполне кошерным. Пришлось новые сертификаты генерировать. Интересно, доживут ли эти сертификаты до естественной смерти (в смысле notAfter)? Или за долго до 2028 года их придется менять потому что опять что-нибудь взломают?

Вот интересно, почему проект DigSig сдох почти десять лет назад, а от bsign-а вообще следов не найдешь, кроме как в древних-древних архивах дебиана и убунты?

В принципе ж классная идея. Намного лучше чем всякие aide и integrit.

Особенно если вместо gpg-шных подписей туда положить CMS-ные. Ну и соответствующую ключевую инфраструктуру выстроить (ровно ту, которая у меня в Детях Пространства описана - корень доверия - ключ владельца компьютера, который выписывает на ключ производителя дистрибутива сертификат с pathLen=1).

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