Журнал Витуса. Голосов: 2 Адрес блога: http://vitus-wagner.livejournal.com/ Добавлен: 2008-02-19 12:48:41 блограйдером Lurk

OpenSSL, сертификаты и юникод

2014-10-03 13:04:51 (читать в оригинале)

Провел тут небольшое исследование того, как openssl (в смысле утилита командной строки, в библиотеке-то еще десять лет назад все хорошо было) относится к русским буквам в Distinguished name сертификатов.

1. У команд. в которых может потребоваться вводить поля distinguished name (req и ca) есть опция -utf8, позволяющая нормально вводить с консоли текст в utf8. У req можно еще в конфиге написать utf8=yes

2. У команд req и x509 есть опция -nameopt, позволяющая задать опции отображения строк.
Если указать -nameopt utf8, то утилита радостно завершится без всякой диагностики при первой же попытке вывести distinguished name. Надо сказать -nameopt sep_comma_plus,utf8. (ну или какой другой sep их есть 4 варианта, но ни один из них не умолчательный).

3. На отображение расширения X509 Authority Key Identifier эта опция не влияет, равно как и на все прочие расширения.

4. У команды ca и такой опции нет (зато есть параметр name_opt в конфиге с совершенно другой с той же семантикой).

5. У команды crl опция -nameopt есть, но влияет только на работу опции -issuer и игнорируется при -text. У функции X509_CRL_print нет аналога X509_CRL_print_ex, позволяющего передать флаги отображения строк.

6. Кроме этого в командах s_client, s_server и ts используется функция X509_NAME_oneline, принципиально нелокализуемая, а в командах nseq, pkcs12 и pkcs7 - dump_cert_text, которая в свою очередь использует X509_NAME_oneline. Правда, она в принципе пишет не на консоль, а в какой-нибудь файл.

7. Принципиально нелокализуемая функция X509_print (которая не ex) используется в командах ca, pkcs7, sess_id и s_server

8. Команды ca и x509 (с опцией -x509toreq) используют X509_REQ_print без ex

И это все про 1.0.1i

Надо бы из этого багрепорт сделать. Но сначала надо понять, как выглядит правильное поведение.

Пока идеи следующие:
1. Предусмотреть у X509_NAME_print_ex умолчательный разделитель полей, чтобы -nameopt utf8 или name_opt=utf8 выводила нечто осмысленное. (однострочный патч)

2. Научить ca и x509 всегда использовать _ex-функции и всегда передавать в них nameopt, раз уж они умеют его откуда-то брать. Там тоже патчи тривиальные, но просто мест много.

3. Для консистентности приделать req name_opt в конфиг, а ca - -nameopt в командную строку. Опять же тривиальный патч.

4. Приделать X509_CRL_print_ex и использовать его в команде crl. Тривиально, но изменение public API, правда, не нарушающее обратную совместимость.

5. Вот что делать с pkcs7, pkcs12, s_client и s_server? Ко всем прикрутить -nameopt (благо парсинг соответсвующего параметра все равно в apps.c)?

6. А с расширениями вообще труба. Там такое количество indirection levels, что даже из X509_print_ex фиг передашь нужный флаг куда надо.
http://vitus-wagner.dreamwidth.org/1017161.html. Please comment there using OpenID. Now there are comments

---

про версионирование

2014-10-01 16:33:40 (читать в оригинале)

Известно, что команда ver у windows до сих пор не дошла до версии 7.

Windows 7 рассказывает о себе, что она 6.1, 8 - 6.2, 8.1 - 6.3.

Теперь вот интересный вопрос - а что будет показывать команда ver в будущей Windows 10?

6.5? 7.0 (что вызовет страшную путаницу)? Или все-таки 10.0?

Предлагайте свои варианты.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1016909.html. Please comment there using OpenID. Now there are comments

---

Serval Mesh

2014-10-01 12:31:09 (читать в оригинале)

В комментах к предыдущему посту подкинули ссылку на Project Serval - еще одно решение по поводу mesh-сети на базе сотовых телефонов.

Статья на cloudzone|

По многим параметрам эта система лучше, чем FireChat. По-первых там поддерживается не только чат, но и голосовые звонки и передача файлов, во-вторых оно open source. В-третьих, уже запущен сбор средств на производство Mesh Extender-ов - таких коробочек, вроде автономных базовых станций, которые позволят организовать связь на расстояние до нескольких километров.

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

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1016651.html. Please comment there using OpenID. Now there are comments

---

На правах рекламы

2014-09-30 15:31:51 (читать в оригинале)

Поставь FireChat на свой смартфон/планшет сегодня. Когда отключат интернет, Гугль плей будет недоступен.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1016345.html. Please comment there using OpenID. Now there are comments

---

SSH сертификаты

2014-09-30 10:53:39 (читать в оригинале)

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

Раньше как-то меня устраивала схема с authorized_keys. Но сейчас развелось планшетов, ноутбуков, виндовых виртуалок (в которых я держу отдельные ключи, поскольку они более подвержены всяким троянам, и может понадобится отозвать ключ виртуалки, не отзывая ключ хоста). В общем authorized_keys на моей домашней машине содержит уже 15 строчек. И распространять его по всем машинам, на которые приходится заходить, надо как-то слишком часто.

А known_hosts вообще под 200 строчек, и большая часть из них про несуществующие уже машины и их ключи. А с тех пор как ssh стал имена хостов хэшировать, чистить его стало неудобно.

В общемя, ч я призадумался над вопросом, а не стоит ли перейти на использование сертификатов.
Сертификаты появились в OpenSSH довольно давно. Более менее вменяемое описание как ими пользоваться можно найти здесь

В этом случае в authorized_keys и known_hostsо станется по одной строчке со ссылокй на ключ CA (ну в known_hosts может быть две - для домашнего CA и для рабочего, чтобы не подписывать своим CA ключи не принадлежащих мне серверов).

Остаются пока следующие вопросы:

1. Как организовать распространение файла RevokedKeys (учитывая что значительная часть машин не всегда влючены)
2. Поддерживаются ли сертификаты во всяких альтернативных по сравнению с openssh клиентах и серверах, которыми приходится пользоваться - putty, vx-connectbot, dropbear, acrosync? Вот sftp-plugin к total commander по-мему их как раз поддерживает, не поддерживая старой схемы с authorized_keys.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1016149.html. Please comment there using OpenID. Now there are comments