VPN-ное.

[vitus_wagner]

Дописал к sstp-client-у поддержку клиентских сертификатов и engines, чтобы можно было авторизовываться ключом с eToken-а. Первый раз в жизни послал на github-е pull-реквест.

Оказалось, что для того, чтобы ходить в нашу корпоративную VPN, этого мало. Нужна еще поддержка PEAP в pppd. А её там из коробки нет. (удивительно, уже семь лет существует Windows server 2008, в котором RAS эти извращенные способы доступа умеет, а в апстрим это еще не пропихнули).

Нашел, правда, готовый патч. Судя по комментариям автора, довольно наколеночный, нужно будет внимательно проаудитить.

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

Comments

Оффтоп

[beldmit.livejournal.com]

Возвысил бы ты свой голос за поддержку ГОСТ в openssl. А то там охаивают engine в рассылке, и надо бы массовость создать.

Re: Оффтоп

[vitus_wagner]

Была у меня мысль, что надо опять на эту рассылку подписаться.
Кстати, в которой охаивают - в -devel или -users?

Re: Оффтоп

[beldmit.livejournal.com]

Devel.

Re: Оффтоп

[vitus_wagner]

Почитал я этот тред.

Вообще, Мэтт Кэсвелл дело говорит - надо заводить отдельный публичный репозиторий для GOST-engine, куда сможем коммитить по крайней мере мы с тобой, возможно кто-то ещё. С со своим трекером и прочими прибамбасами. И главное - со своей release schedule.

Правда, мы сразу наступим на необходимость коренной переделки build system, потому что то, что там сейчас, совершенно не рассчитано на off-tree сборку. (правда, можно из криптокомовских репозиториев утащить сборочную систему для open-engine от 0.9.8, да и test suite заодно)

Что характерно, скрипты mkerr.pl и ck_errf.pl вообще не ставятся ни с какими libssl-dev пакетами. А нам их надо.

Re: Оффтоп

[beldmit.livejournal.com]

Ну вот я ему написал, что готов мейнтейнить engine, ща торгуемся. Кроме тебя и меня есть ещё пара человек, кому я доверил бы коммиты.

Проблема, как я ему писал, нифига не в engine. А в TLS-ном коде, PKCS12 и куче мелких мелочей, которые нифига не pluggable, начиная с OIDов.

Про систему сборки я понимаю. Я ща код пишу, так без mkerr.pl при сборке тяжко, а при дистрибуции он наоборот, вреден.

Re: Оффтоп

[vitus_wagner]

За что торгуетесь - за право коммита в основной репозиторий или что-то менее ценное?

Re: Оффтоп

[beldmit.livejournal.com]

За право коммита, как мне представляется, торговаться бессмысленно. Не дадут. Торговаться имеет смысл за прямой канал на core team на будущее и очередной квант добавления хуков.

Возможно, получится договориться о том, что часть кода они одноразово инкорпорируют.

Re: Оффтоп

[vitus_wagner]

Надо что-ли пробежаться по списку хуков, понять не забыли ли чего. Ты, конечно, сейчас более в теме, поскольку я последнее время ни в TLS, ни в PKCS12 не лазил. Но тем не менее.

Ну и надо им обещать те fprintf-ы, кооторые не под #ifdef DEBUG
повычистить. Впрочем, те которые под - тоже.

Кстати, не помнишь, почему у нас попытка повторного вызова bind_gost считается ошибкой?

Может быть стоит, обнаружив что все уже проинициализировано, возвращать успех?

Re: Оффтоп

[beldmit.livejournal.com]

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

Re: Оффтоп

[vitus_wagner]

НЕ понравится - раскритикую.

Вообще надо в два приема.

Сначала на концептуальном уровне:

Вот нам нужны такие-то такие-то идентификаторы. Сейчас аналогичные идентификаторы hardcoded туда-то и туда-то.

А вообще нам бы надо OID-ы регистрировать по-нормальному. (насколько я посмотрел, ситуация с регистрацией OID_ов с 0.9.8 не изменилась.

Можно было бы смириться с OID-ами в конфиге, но есть уйма приложений, в том числе такие важные как mod_ssl , stunnel и openvpn, которые этот конфиг не читают, причем по принципиальным соображениям.

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

Насколько я понимаю, как раз с micalg-ами все довольно дешево получается - добавить поле в EVP_MD, и, возможно, к нему accessor.

А вот с TLS-ом там и правда сильно сложнее.

Re: Оффтоп

[beldmit.livejournal.com]

Там в ряде мест надо указать флаг "Это ГОСТ". И сразу можно будет не перечислять NID-ы.

OID-ы можно регистрировать нормально. Уже тогда можно было. Но там есть чёртова тонна псевдомассивов с константами, в которые надо бы что-то добавлять, но получится это тяжеловесно. В лучшем случае это массивы непубличных структур, в худшем - набор #define.

Любимый пример от Игуса - русские буквы в X.509 extension по какому-то документу, устанавливающему требования к квалифицированному сертификату. Коллбеки пляшут от NID-ов, NID-ы упорядочиваются по возрастанию. Структура закрытая, хрен что добавишь.

Re: Оффтоп

[lumag]

Извините, что влезаю. Жаль, что никто не берется поддерживать ГОСТ в основной базе OpenSSL.

В LibreSSL поддержка ГОСТ вкручена в основную кодовую базу (т.к. они убрали engine dynamic), код упростился, по-моему. Например, кривые, которые честно прописаны в ec_curve.c Или gost_key, который стал одним из вариантов evp_pkey_st.pkey.

Re: Оффтоп

[vitus_wagner]

Ну не нужен нафиг ГОСТ в ядре. Интересны сертифицирвоаныне реализации. Если у нас гост реализован внешним модулем, то можно этот модуль сертифицирвовать и поставлять в бинарном виде. А остальная криптобиблиотека будет в открытом виде, со своевременынми security updates и все такое.

Собственно открытая реализация ГОСТ была туда в свое время законтрибучена только потому, что для полноценной поддержки ГОСТовской криптографии требуются определенные изменения в коде реализации SSL и CMS, и нужно было что-то с чем вместе их можно протестировать.

Сам по себе ГОСТ ничего особо интересного не представляет. Отличия от ECDSA - чисто косметические.

Мне скорее жалко что никто из японцев не поддержал почина и не законтрибутил японский национальный алгоритм подписи. Должно быть много алгоритмов, хороших и разных и все они должны быть pluggable.

Re: Оффтоп

[lumag]

Витус, вот поскольку ГОСТ не в ядре, периодически возникают разные странности. Например, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611054 .

Я предполагаю, зачем Вам сертифицированная реализация. Но, по-моему, в том же OpenSSL было бы проще внести ccgost в основную библиотеку (не отменяя отдельного engine в MagPro/Lissi и т.п.). В конце концов, если надо, engine прекрасно (в идеале) переопределяет поддержку алгоритмов, а у разработчиков, например, dnssec все работает без дополнительных хаков.

Когда разбирался с ГОСТ, было четкое ощущение, что pluggable легко делаются симметричные шифры/хэш-функции. А pluggable ассиметрия дается очень сложно. В libgcrypt, например, специальный lisp-подобный язык используется, чтобы API у ассиметричных алгоритмов был одинаковый.