[devel] I: TLS/SSL policy - broken packages

[devel] I: TLS/SSL policy - broken packages

[Mikhail Yakshin]

Приветствую!

У нас формально введена в действие новая TLS/SSL policy. Ниже приведен
некий анализ пакетов, которые ей пока (возможно, я ошибаюсь) не следуют.
Текст получился довольно объемным, но я очень прошу всех мейнтейнров
перечисленных пакетов найти время и прочитать его внимательно.

==========================================================================
Клиентские пакеты
==========================================================================

curl - несет в себе ca-bundle.crt в формате PEM, вытащенный аж из
Netscape Communicator 4.72. Ввиду довольно нетривиальной обработки
местоположения этого файла, предлагается просто убрать из пакета файл
ca-bundle.crt и в вызове configure указать на наш файл.

kdelibs - несет в себе /usr/share/apps/kssl/ca-bundle.crt, не очень
понятно откуда. Либо патчить на OPENSSL_config, либо просто показать при
сборке на наш единый файл. Некие патчи есть, насколько я понял, в Fedora
и Debian, к сожалению, быстро разобраться не удалось.

libgwenhywfar - несет в себе /etc/gwen-public-ca.crt в формате PEM,
вытащенный из какой-то неопознанной версии Netscape. Есть функция
GWEN_NetLayerSsl_new, которую теоретически несложно пропатчить на
предмет использования OPENSSL_config(3).

libqca2 - моя библиотека, все в курсе, все знаю, буду делать.

mutt1.5 - несет в себе древний
/usr/share/doc/mutt1.5-1.5.13/samples/ca-bundle.crt из Netscape 4.72,
который рекомендуется копировать в ~/.smime/ca-bundle.crt, чтобы mutt
его нашел и использовал. Прошу пояснений мейнтейнера, можно ли заставить
mutt использовать стандартные механзимы поиска списка CA через openssl?

firefox, thunderbird, xulrunner, seamonkey, libnspr - общая замечание ко
всем, использующим NSS - имеет смысл, видимо, при сборке добавлять новый
ALT CA таким builtin token, как сейчас добавляется старый (в файле типа
firefox-0.9-alt-ssl-addon-certs.txt). В идеале - не просто добавлять
один CA, а устроить обратное преобразование из PEM в формат файла
сертификатов Gecko-образных.

==========================================================================
Особые случаи:
==========================================================================

unreal - несет в себе некий серверный самоподписанный сертификат с
такими параметрами:

Issuer: C=RU, ST=Moskovskaya Oblast, L=Korolev, O=Fly Net, OU=Server
development team, CN=irc.fly
Subject: C=RU, ST=Moskovskaya Oblast, L=Korolev, O=Fly Net, OU=Server
development team, CN=irc.fly
Validity
    Not Before: Apr 19 17:46:40 2005 GMT
    Not After : Apr 19 17:46:40 2006 GMT

Самое главное - он уже давно просрочен. Прошу комментариев у
мейнтейнера, что это за сертификат и не имеет ли смысл заменить его либо
на автоматически генерящийся, либо на подписанный нашим CA, например?

ntop - несет в себе самоподписанный /etc/ntop-cert.pem, который точно
так же выдан на некоего не очень понятного субъекта и очень давно просрочен:

Issuer: C=IT, ST=Pisa, O=ntop.org, CN=Luca Subject: C=IT, ST=Pisa,
O=ntop.org, CN=Luca Deri/emailAddress=deri@ntop.org
Deri/emailAddress=deri@ntop.org
Validity
    Not Before: Dec 23 16:58:34 2001 GMT
    Not After : Dec 23 16:58:34 2002 GMT

Прошу комментариев мейнтейнера - зачем такой сертификат лежит в пакете?	

MySQL-server - несет в себе в документации пример сертификата CA,
который используется как сервером, так и клиентом. Несмотря на то, что
сертификат в документации и отключен по умолчанию, при реальном
использовании его или аналогов требуется указание положения некоего CA
bundle через ключ типа "ssl-ca=SSL/cacert.pem". Вопрос к мейнтейнеру -
нет ли возможности / стоит ли патчить или что-то менять в MySQL, чтобы
по умолчанию он имел в виду наш общий CA bundle?

freeradius - практически тот же вопрос, что и про MySQL. Пакет несет у
себя внутри примеры сертификатов и CA, но после прочтения
/etc/raddb/certs/README возникает вопрос - что будет, если положить ему
просто один сертификат, подписанный тем CA, что указан у нас в bundle?
Подхватится ли?

nut-server - несет в себе файл /etc/nut/upsd.pem, который пуст. Хотелось
бы услышать комментарии мейнтейнера, зачем он такой?

==========================================================================
Языки программирования
==========================================================================

erlang, plt2, php5-devel, perl-Net-SSLeay, python-module-m2crypto,
python-module-twisted

- это все языки программирования, имеющие биндинги на OpenSSL внутри
самого пакета с языком или в отдельном пакете.

Здесь сложная ситуация: по логике вещей во всех приведенных пакетах тоже
просто примеры (правда, лежащих в довольно нетрадиционных местах вроде
/usr/lib/erlang/lib/ssl-3.0.11/examples/certs/etc/erlangCA), но
возникает резонный вопрос: если в этих языках программирования
использовать их встроенные биндинги на OpenSSL - будет ли автоматически
подхватываться наш CA bundle?

Это вопрос к мейнтейнерам или лучше даже просто тем, кто знает эти
языки. К сожалению, я erlang и scheme не знаю в той степени, чтобы
ответить на такой вопрос. Про php, perl и, возможно, python, посмотрю
либо позже сам, либо ответят мейнтейнеры.

==========================================================================
Нет major претензий к серверным пакетам:
==========================================================================

apache2-mod_ssl, mod_ssl, sendmail - просто несут в себе примеры
сертификатов

openvpn-docs - примеры сертификатов в документации

courier-imap, dovecot, exim, monit, uw-imap, stunnel - генерят простые
самоподписанные сертификаты автоматически в пост-инсталл скрипте.
Единственное - есть предложение - не плодить столько много разных хитрых
скриптов - может быть сделать один макрос на всех?

Ко всем этим пакетам есть minor замечания по поводу п.5 полиси.

==========================================================================

Финальное замечание: рассмотрены были пока только пакеты, которые явно
несли в себе некие признаки использования openssl, не соответствующего
policy. Кроме того, нужно просто вручную рассмотреть все пакеты, которые
зависят от libssl с куда более пристрастной проверкой: внутри каждого из
них может быть инициализация openssl с использованием наших общих CA или
без. Во втором случае это предполагается исправлять.

Дополнительный список:

appliance-fake-utm
aria2
asterisk1.4
asterisk1.4-res_crypto
astmanproxy
AutoScan
balsa
bloom
captive
centericq
claws-mail
claws-mail-plugin-spamassassin
cups
cyrus-imapd
cyrus-imapd-murder
cyrus-imapd-utils
cyrus-sasl2
dillo
dsniff
elinks
fetchmail
fuse-encfs
gftp-gtk
gftp-text
git-core
gkrellm
gnubiff
gnubiff-gnome
gnugk
gq
gtkjournal
hostapd
httperf
httping
hydra-common
imapfilter
inn
ipsec-tools
ipv6calc
irssi
iscsitarget-utils
jabber
jabberd2-c2s
jabberd2-resolver
jabberd2-router
jabberd2-s2s
jabberd2-sm
jpilot
kasablanca
kdebase-kcontrol
kdebase-konqueror
kdenetwork-kopete
keyring-link
kftpgrabber
kvirc
lftp
libbind
libchipcard
libchipcard-tools
libclip-common
libcups
libdar
libecore
libesmtp
libesmtp-devel
libfwbuilder
libgnomedb
libldap2.3
libmnetutil
libmutil
libMySQL41
libMySQL
libneon
libneon0.25
libneon0.26
libnet-snmp
libomniORB
libopal
libopenh323_1.19
libopensc
libopenslp
libpq4.0
libpq4.1
libpw
librtorrent
libsasl2
libsmbclient-devel
libssl-devel
libucd-snmp
libxmlsec1-openssl
libyaz
licq-common
licq-msn
lighttpd
links1
links2
lynx
mailfilter
mail-notification
mcabber
micq
msmtp
msmtp-ssl
mtree
mutt
MySQL41-client
MySQL41-server
nagios-nrpe
nagios-plugins-network
nagios-plugins-nrpe
netams
net-snmp
nginx
nmap
nut
nut-cgi
openldap-servers
openntpd
opensc
openslp-daemon
openssh
openssh-clients
openssh-keysign
openssh-server
openssl-engines
osec
pam_mount
pam_usb
parsecvs
pavuk
perl-Crypt-OpenSSL-Bignum
perl-Crypt-OpenSSL-Random
perl-Crypt-OpenSSL-RSA
perl-Crypt-SSLeay
perl-Cyrus
php5-imap
php5-openssl
php-imap
php-openssl
pine
postal
postfix-tls
postgresql8.0
postgresql8.0-server
postgresql8.1
postgresql8.1-contrib
postgresql8.1-server
proftpd-mod_tls
python-module-OpenSSL
python-module-pycurl
python-modules
qca-tls
qpamat
rdesktop
ruby-module-digest
ruby-module-openssl
seirospbx1.4
seirospbx1.4-res_crypto
sendmail-submit
siege
sim
sim-qt
sipp
snort-snmp
snort-snmp+flexresp
socat
spamassassin-spamc
squid-helpers
squid-server
ssmtp-ssl
sylpheed
tcl-tls
tcpdump
tinc
tor
vtund
w3c-libwww
w3m
wget
wine
wpa_supplicant
x11vnc
xchat
X-Downloader
xen
xrdp
yaz

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] I: TLS/SSL policy - broken packages

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

* Mikhail Yakshin <greycat@> [070209 01:25]:
> mutt1.5 - несет в себе древний
> /usr/share/doc/mutt1.5-1.5.13/samples/ca-bundle.crt из Netscape 4.72,
> который рекомендуется копировать в ~/.smime/ca-bundle.crt, чтобы mutt
> его нашел и использовал. Прошу пояснений мейнтейнера, можно ли заставить
> mutt использовать стандартные механзимы поиска списка CA через openssl?
Это одно из значений опции smime_ca_location, используется для
проверки S/MIME подписи.  Передаётся (если выставлена) значением
опции -CAfile/-CApath при запуске openssl ("%C").

3.214. smime_ca_location

   Type: path
   Default: ""

   This variable contains the name of either a directory, or a file which
   contains trusted certificates for use with OpenSSL. (S/MIME only)

3.216. smime_decrypt_command (для всех smime_*_command одинаково)
...
   %C
          CA location: Depending on whether $smime_ca_location points to a
          directory or file, this expands to "-CApath $smime_ca_location"
          or "-CAfile $smime_ca_location".

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy - broken packages

[Mikhail Yakshin]

Alexey I. Froloff пишет:
> * Mikhail Yakshin <greycat@> [070209 01:25]:
>> mutt1.5 - несет в себе древний
>> /usr/share/doc/mutt1.5-1.5.13/samples/ca-bundle.crt из Netscape 4.72,
>> который рекомендуется копировать в ~/.smime/ca-bundle.crt, чтобы mutt
>> его нашел и использовал. Прошу пояснений мейнтейнера, можно ли заставить
>> mutt использовать стандартные механзимы поиска списка CA через openssl?
> Это одно из значений опции smime_ca_location, используется для
> проверки S/MIME подписи.  Передаётся (если выставлена) значением
> опции -CAfile/-CApath при запуске openssl ("%C").
> 
> 3.214. smime_ca_location
> 
>    Type: path
>    Default: ""
> 
>    This variable contains the name of either a directory, or a file which
>    contains trusted certificates for use with OpenSSL. (S/MIME only)
> 
> 3.216. smime_decrypt_command (для всех smime_*_command одинаково)
> ...
>    %C
>           CA location: Depending on whether $smime_ca_location points to a
>           directory or file, this expands to "-CApath $smime_ca_location"
>           or "-CAfile $smime_ca_location".

То есть, насколько я понял, без патчей - нельзя. Встает вопрос, что делать:

1. (самое сложное) Пропатчить mutt, чтобы он использовал 
OPENSSL_config(3) и подхватывал наш CA bundle.

2. (самое простое) Убрать из пакета ca-bundle.crt и положить README.ALT 
с упоминанием, что default CA bundle доступен в системе там-то и личная 
задача каждого пользователя, который хочет S/MIME - настраивать mutt на 
использование этого CA bundle.

3. (сомнительное) По умолчанию настроить в mutt system-wide на наш CA 
bundle. Не очень знаю mutt и не представляю, возможно ли это технически 
и что от этого сломается.

-- 
WBR, GreyCat

Re: [devel] I: TLS/SSL policy - broken packages

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

* Mikhail Yakshin <greycat@> [070209 11:21]:
> То есть, насколько я понял, без патчей - нельзя. Встает вопрос, что делать:

> 1. (самое сложное) Пропатчить mutt, чтобы он использовал 
> OPENSSL_config(3) и подхватывал наш CA bundle.
Нет.  mutt не использует libssl для этих целей.  Он использует
/usr/bin/openssl и при необходимости передаёт ему опцию
-CAfile/-CApath если выставлена опция (по умолчанию там пусто).
Как работает openssl без этих опций?

> 2. (самое простое) Убрать из пакета ca-bundle.crt и положить README.ALT 
> с упоминанием, что default CA bundle доступен в системе там-то и личная 
> задача каждого пользователя, который хочет S/MIME - настраивать mutt на 
> использование этого CA bundle.
С удовольствием приму патч ;-)

> 3. (сомнительное) По умолчанию настроить в mutt system-wide на наш CA 
> bundle. Не очень знаю mutt и не представляю, возможно ли это технически 
> и что от этого сломается.
Можно, но нафиг не нужно, IMHO.

2lakostis: Кость, ты вроде пользуешься S/MIME в mutt?
Прокомментируй пожалуйста?

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy - broken packages

[Mikhail Yakshin]

Alexey I. Froloff wrote:
> * Mikhail Yakshin <greycat@> [070209 11:21]:
>> То есть, насколько я понял, без патчей - нельзя. Встает вопрос, что делать:
> 
>> 1. (самое сложное) Пропатчить mutt, чтобы он использовал 
>> OPENSSL_config(3) и подхватывал наш CA bundle.
> Нет.  mutt не использует libssl для этих целей.  Он использует
> /usr/bin/openssl и при необходимости передаёт ему опцию
> -CAfile/-CApath если выставлена опция (по умолчанию там пусто).
> Как работает openssl без этих опций?

Надо проверять. Проверять S/MIME нам сейчас, я так понимаю, не на чем.
Нужно хотя бы 1-2 именных сертификата выписать от ALT CA с этими проверками.

2ldv: можно попробовать это проверить? Я так понимаю, шаги следующие:

1. Выписать сертификат на человека с возможностью S/MIME (cert.pem)
2. Создать файл с сообщением message.txt
3. openssl smime -sign -in message.txt -out message-signed.txt cert.pem
4. openssl smime -verify -in message-signed.txt

> 2lakostis: Кость, ты вроде пользуешься S/MIME в mutt?
> Прокомментируй пожалуйста?

Было бы неплохо, да :) Присоединяюсь к просьбе.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] I: TLS/SSL policy - broken packages

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

Hi Mikhail!

Saturday 10, at 12:36:32 PM you wrote:

> Надо проверять. Проверять S/MIME нам сейчас, я так понимаю, не на чем.
> Нужно хотя бы 1-2 именных сертификата выписать от ALT CA с этими проверками.
> 
> 2ldv: можно попробовать это проверить? Я так понимаю, шаги следующие:
> 
> 1. Выписать сертификат на человека с возможностью S/MIME (cert.pem)
> 2. Создать файл с сообщением message.txt
> 3. openssl smime -sign -in message.txt -out message-signed.txt cert.pem
> 4. openssl smime -verify -in message-signed.txt
> 
> > 2lakostis: Кость, ты вроде пользуешься S/MIME в mutt?
> > Прокомментируй пожалуйста?
> 
> Было бы неплохо, да :) Присоединяюсь к просьбе.
Проверяю :) Письмо подписано сертификатом, CA которого есть в
общестистемном ca-bundle

-- 
WBR et al.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1495 bytes --]

Re: [devel] I: TLS/SSL policy - broken packages

[Mikhail Yakshin]

Konstantin A. Lepikhov wrote:
> Hi Mikhail!
> 
> Saturday 10, at 12:36:32 PM you wrote:
> 
>> Надо проверять. Проверять S/MIME нам сейчас, я так понимаю, не на чем.
>> Нужно хотя бы 1-2 именных сертификата выписать от ALT CA с этими проверками.
>>
>> 2ldv: можно попробовать это проверить? Я так понимаю, шаги следующие:
>>
>> 1. Выписать сертификат на человека с возможностью S/MIME (cert.pem)
>> 2. Создать файл с сообщением message.txt
>> 3. openssl smime -sign -in message.txt -out message-signed.txt cert.pem
>> 4. openssl smime -verify -in message-signed.txt
>>
>>> 2lakostis: Кость, ты вроде пользуешься S/MIME в mutt?
>>> Прокомментируй пожалуйста?
>> Было бы неплохо, да :) Присоединяюсь к просьбе.
> Проверяю :) Письмо подписано сертификатом, CA которого есть в
> общестистемном ca-bundle

И в том, и в другом случае - никак. Что я делаю не так?

Для полного текста письма:

$ openssl smime -verify -in message.signed
Error reading S/MIME message
10965:error:2107A083:PKCS7 routines:SMIME_read_PKCS7:invalid mime
type:pk7_mime.c:364:type: multipart/mixed

То есть даже прочитать не может внешнюю MIME-оболочку.

Если отрезать multipart и оставить только 2 части - письмо и подпись:

$ openssl smime -verify -in message2.signed
Verification failure
10944:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify
error:pk7_smime.c:233:Verify error:unable to get local issuer certificate

$ openssl smime -verify -CAfile /usr/share/ca-certificates/ca-bundle.crt
-in message2.signed
Verification failure
10955:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify
error:pk7_smime.c:233:Verify error:unable to get local issuer certificate

И в том, и в другом случае - проверить не получается.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] I: TLS/SSL policy - broken packages

[Konstantin A. Lepikhov]

[-- Attachment #1.1: Type: text/plain, Size: 1314 bytes --]

Hi Mikhail!

Saturday 10, at 01:23:49 PM you wrote:

...
> И в том, и в другом случае - никак. Что я делаю не так?
> 
> Для полного текста письма:
> 
> $ openssl smime -verify -in message.signed
> Error reading S/MIME message
> 10965:error:2107A083:PKCS7 routines:SMIME_read_PKCS7:invalid mime
> type:pk7_mime.c:364:type: multipart/mixed
> 
> То есть даже прочитать не может внешнюю MIME-оболочку.
> 
> Если отрезать multipart и оставить только 2 части - письмо и подпись:
> 
> $ openssl smime -verify -in message2.signed
> Verification failure
> 10944:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify
> error:pk7_smime.c:233:Verify error:unable to get local issuer certificate
> 
> $ openssl smime -verify -CAfile /usr/share/ca-certificates/ca-bundle.crt
> -in message2.signed
> Verification failure
> 10955:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify
> error:pk7_smime.c:233:Verify error:unable to get local issuer certificate
> 
> И в том, и в другом случае - проверить не получается.
а вот и первый кандидат на добавление в ca-certificates :) Это Thawte
Freemail. Если положить приложенный сертификат в /var/lib/ssl/certs и
потом сказать там c_rehash, то проверка возвращает что-то полее вменяемое
- типа certificate expired.

-- 
WBR et al.

[-- Attachment #1.2: thawte-freemail.pem --]
[-- Type: text/plain, Size: 3440 bytes --]

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 13 (0xd)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting, OU=Certification Services Division, CN=Thawte Personal Freemail CA/emailAddress=personal-freemail@thawte.com
        Validity
            Not Before: Jul 17 00:00:00 2003 GMT
            Not After : Jul 16 23:59:59 2013 GMT
        Subject: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte Personal Freemail Issuing CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:c4:a6:3c:55:73:55:fb:4e:b9:ca:99:5a:1e:68:
                    c0:75:04:70:9d:df:e9:ff:a3:1e:ec:bd:cd:f5:5b:
                    f2:1a:76:bd:7f:0c:3a:61:f2:bf:51:ce:01:d4:e5:
                    50:0a:30:d7:02:63:5a:2c:89:15:70:8e:dd:c9:f0:
                    2b:85:5a:aa:3f:71:56:cb:af:3c:0b:07:e7:f1:1f:
                    91:36:24:2a:13:cf:2b:d5:f3:82:77:3d:03:be:2b:
                    fe:bb:18:3e:07:bf:40:80:02:64:d7:a7:a6:bb:9f:
                    65:d1:c5:2a:54:85:0f:48:04:7f:a7:b6:d1:3c:61:
                    04:40:1e:64:19:72:60:b7:fb
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 CRL Distribution Points: 
                URI:http://crl.thawte.com/ThawtePersonalFreemailCA.crl

            X509v3 Key Usage: 
                Certificate Sign, CRL Sign
            X509v3 Subject Alternative Name: 
                DirName:/CN=PrivateLabel2-138
    Signature Algorithm: sha1WithRSAEncryption
        48:8c:d1:50:83:ea:0b:2e:cc:0d:a3:66:ac:67:0f:7f:af:ac:
        be:c2:17:a1:43:96:94:9d:7f:4c:21:b8:f8:36:1f:aa:2d:9f:
        36:2f:c0:f4:1c:50:20:93:70:3c:fd:ad:e1:61:62:c3:d9:3a:
        19:7e:84:b1:99:1b:00:c5:1a:0b:82:74:9e:25:50:94:62:c7:
        db:27:71:57:25:8d:dd:a9:9c:39:8e:8c:20:4f:65:5f:95:da:
        f7:f7:87:d6:c6:08:4e:ae:f6:ea:34:e5:10:1a:5b:35:4d:77:
        e3:56:21:78:82:dc:21:19:35:de:24:b1:d3:1d:46:ff:5d:5f:
        65:4f
-----BEGIN CERTIFICATE-----
MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD
VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT
ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu
Y29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31
W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2
JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ
cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4
oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h
aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQ
cml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as
Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsA
xRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj
ViF4gtwhGTXeJLHTHUb/XV9lTw==
-----END CERTIFICATE-----

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy - broken packages

[Mikhail Yakshin]

Konstantin A. Lepikhov wrote:
> ...
>> И в том, и в другом случае - никак. Что я делаю не так?
[...]
>> И в том, и в другом случае - проверить не получается.

> а вот и первый кандидат на добавление в ca-certificates :) Это Thawte
> Freemail. Если положить приложенный сертификат в /var/lib/ssl/certs и
> потом сказать там c_rehash, то проверка возвращает что-то полее вменяемое
> - типа certificate expired.

Итого, в сухом остатке:

1. mutt и openssl smime - будут работать без опций -CAfile / -CApath,
все претензии к ним снимаются, я правильно понял?

2. Нам нужно добавить 1 CA в пакет ca-certificates.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] I: TLS/SSL policy - broken packages

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

* Mikhail Yakshin <greycat@> [070210 15:52]:
> Итого, в сухом остатке:

> 1. mutt и openssl smime - будут работать без опций -CAfile / -CApath,
> все претензии к ним снимаются, я правильно понял?

> 2. Нам нужно добавить 1 CA в пакет ca-certificates.

3. Я жду патча к /usr/share/doc/mutt1.5-*/samples/smime.rc if
any.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy - broken packages

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

On Sat, Feb 10, 2007 at 03:17:13PM +0300, Konstantin A. Lepikhov wrote:
[...]
> а вот и первый кандидат на добавление в ca-certificates :) Это Thawte
> Freemail.

А что это за сертификат, откуда он взялся и какая на него лицензия?
В файле thawte-roots.zip, который раздают с http://www.thawte.com/roots/,
этого сертификата
(SHA1 Fingerprint=BC:F0:3A:B1:BD:9A:08:9B:EB:46:8D:AF:99:47:5E:83:18:39:99:0F)
нет.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy - broken packages

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

Hi Dmitry!

Saturday 10, at 06:31:32 PM you wrote:

> On Sat, Feb 10, 2007 at 03:17:13PM +0300, Konstantin A. Lepikhov wrote:
> [...]
> > а вот и первый кандидат на добавление в ca-certificates :) Это Thawte
> > Freemail.
> 
> А что это за сертификат, откуда он взялся и какая на него лицензия?
> В файле thawte-roots.zip, который раздают с http://www.thawte.com/roots/,
> этого сертификата
> (SHA1 Fingerprint=BC:F0:3A:B1:BD:9A:08:9B:EB:46:8D:AF:99:47:5E:83:18:39:99:0F)
> нет.
А тут http://terrencemiao.com/Webmail/msg00907.html он упоминается (aka
thawte Personal Freemail Issuing CA).

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy - broken packages

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

On Sat, Feb 10, 2007 at 08:13:17PM +0300, Konstantin A. Lepikhov wrote:
> Saturday 10, at 06:31:32 PM you wrote:
> > On Sat, Feb 10, 2007 at 03:17:13PM +0300, Konstantin A. Lepikhov wrote:
> > [...]
> > > а вот и первый кандидат на добавление в ca-certificates :) Это Thawte
> > > Freemail.
> > 
> > А что это за сертификат, откуда он взялся и какая на него лицензия?
> > В файле thawte-roots.zip, который раздают с http://www.thawte.com/roots/,
> > этого сертификата
> > (SHA1 Fingerprint=BC:F0:3A:B1:BD:9A:08:9B:EB:46:8D:AF:99:47:5E:83:18:39:99:0F)
> > нет.
> А тут http://terrencemiao.com/Webmail/msg00907.html он упоминается (aka
> thawte Personal Freemail Issuing CA).

В thawte-roots.zip есть
CN=Thawte Personal Freemail CA/emailAddress=personal-freemail@thawte.com
но это другой сертификат.  А этого
"CN=Thawte Personal Freemail Issuing CA", который подписан
"CN=Thawte Personal Freemail CA", там нет.

Вопрос: мы будем добавлять все сертификаты, или только рутовые?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy - broken packages

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Hi Dmitry!

Saturday 10, at 08:47:30 PM you wrote:

...
> В thawte-roots.zip есть
> CN=Thawte Personal Freemail CA/emailAddress=personal-freemail@thawte.com
> но это другой сертификат.  А этого
> "CN=Thawte Personal Freemail Issuing CA", который подписан
> "CN=Thawte Personal Freemail CA", там нет.
> 
> Вопрос: мы будем добавлять все сертификаты, или только рутовые?
по-идее, надо оба, иначе пользователям придется включать в письмо кроме
персонального сертификата еще и этот Issuing CA.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy: broken packages

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On Fri, Feb 09, 2007 at 01:22:07AM +0300, Mikhail Yakshin wrote:
> nut-server - несет в себе файл /etc/nut/upsd.pem, который пуст. Хотелось
> бы услышать комментарии мейнтейнера, зачем он такой?

/etc/nut/upsd.pem -- это не пустой файл, а ссылка на пустой файл
/var/lib/nut/etc/nut/upsd.pem, который является местом для приватного
ключа и сертификата, которые может создать администратор сервера upsd для
того чтобы клиенты могли его аутентифицировать; аналог файлов
/etc/httpd/conf/ssl/server.* из пакета mod_ssl с тем отличием,
что ключ и сертификат с пакетом не поставляется.

> Финальное замечание: рассмотрены были пока только пакеты, которые явно
> несли в себе некие признаки использования openssl, не соответствующего
> policy. Кроме того, нужно просто вручную рассмотреть все пакеты, которые
> зависят от libssl с куда более пристрастной проверкой: внутри каждого из
> них может быть инициализация openssl с использованием наших общих CA или
> без. Во втором случае это предполагается исправлять.
> 
> Дополнительный список:

В этот список попали пакеты, которые из libssl используют только
libcrypto.  Такие пакеты рассматривать нет смысла.

> elinks
> lftp
> wget

Эти по умолчанию используют для проверки тот CA bundle, на который настроен
openssl.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy: broken packages

[Mikhail Yakshin]

Dmitry V. Levin пишет:
> On Fri, Feb 09, 2007 at 01:22:07AM +0300, Mikhail Yakshin wrote:
>> nut-server - несет в себе файл /etc/nut/upsd.pem, который пуст. Хотелось
>> бы услышать комментарии мейнтейнера, зачем он такой?
> 
> /etc/nut/upsd.pem -- это не пустой файл, а ссылка на пустой файл
> /var/lib/nut/etc/nut/upsd.pem, который является местом для приватного
> ключа и сертификата, которые может создать администратор сервера upsd для
> того чтобы клиенты могли его аутентифицировать; аналог файлов
> /etc/httpd/conf/ssl/server.* из пакета mod_ssl с тем отличием,
> что ключ и сертификат с пакетом не поставляется.

Вообще, есть желание как-то зафиксировать и тут ситуацию. У нас есть 
куча пакетов, таскающих с собой бесполезные (потому как не совпадает 
hostname), обычно еще и просроченные, примеры сертификатов. Один пакет 
вот вообще таскает пустой файл под видом файла с сертификатом.

Может быть сделать на всех один макрос, который бы генерил свежие 
самоподписанные сертификаты и проследить, чтобы все его использовали?

>> Финальное замечание: рассмотрены были пока только пакеты, которые явно
>> несли в себе некие признаки использования openssl, не соответствующего
>> policy. Кроме того, нужно просто вручную рассмотреть все пакеты, которые
>> зависят от libssl с куда более пристрастной проверкой: внутри каждого из
>> них может быть инициализация openssl с использованием наших общих CA или
>> без. Во втором случае это предполагается исправлять.
>>
>> Дополнительный список:
> 
> В этот список попали пакеты, которые из libssl используют только
> libcrypto.  Такие пакеты рассматривать нет смысла.

Согласен. Хотел еще заметить, что в этом списке уже те пакеты, которым 
хуже точно не будет, т.е. если кто-то из них и раньше не поддерживал CA 
из общего CA bundle (того же openssl'ного), то он не работал ни раньше, 
ни теперь, если мы только этот факт не выявим и не исправим.

>> elinks
>> lftp
>> wget
> 
> Эти по умолчанию используют для проверки тот CA bundle, на который настроен
> openssl.

Сейчас сделаю страничку на wiki, будем там вычеркивать. Вешать на такие 
пакеты баги нельзя, хотя бы не проверив. Проверять-то просто - взять и с 
помощью такого пакета приконнектиться к https://heap.altlinux.org или 
чему-то подобному.

-- 
WBR, GreyCat

Re: [devel] I: TLS/SSL policy: broken packages

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On Fri, Feb 09, 2007 at 11:26:01AM +0300, Mikhail Yakshin wrote:
[...]
> Сейчас сделаю страничку на wiki, будем там вычеркивать. Вешать на такие 
> пакеты баги нельзя, хотя бы не проверив. Проверять-то просто - взять и с 
> помощью такого пакета приконнектиться к https://heap.altlinux.org или 
> чему-то подобному.

Простой тест на https-клиента:
1. должно работать: https://heap.altlinux.ru/
2. должно не работать: https://newstat.netbynet.ru/ (самоподписанный сертификат)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy - broken packages

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

Hi Mikhail!

Friday 09, at 01:22:07 AM you wrote:
..
> firefox, thunderbird, xulrunner, seamonkey, libnspr - общая замечание ко
> всем, использующим NSS - имеет смысл, видимо, при сборке добавлять новый
> ALT CA таким builtin token, как сейчас добавляется старый (в файле типа
> firefox-0.9-alt-ssl-addon-certs.txt). В идеале - не просто добавлять
> один CA, а устроить обратное преобразование из PEM в формат файла
> сертификатов Gecko-образных.
кажется, у нас все-таки сделано наоборт ;)

> MySQL-server - несет в себе в документации пример сертификата CA,
> который используется как сервером, так и клиентом. Несмотря на то, что
> сертификат в документации и отключен по умолчанию, при реальном
> использовании его или аналогов требуется указание положения некоего CA
> bundle через ключ типа "ssl-ca=SSL/cacert.pem". Вопрос к мейнтейнеру -
> нет ли возможности / стоит ли патчить или что-то менять в MySQL, чтобы
> по умолчанию он имел в виду наш общий CA bundle?
только если вынести сервер из chroot'а - поскольку в chroot все равно
придется bundle вручную запихивать.

BTW, то же самое придется и делать с postfix.
 
> Финальное замечание: рассмотрены были пока только пакеты, которые явно
> несли в себе некие признаки использования openssl, не соответствующего
> policy. Кроме того, нужно просто вручную рассмотреть все пакеты, которые
> зависят от libssl с куда более пристрастной проверкой: внутри каждого из
> них может быть инициализация openssl с использованием наших общих CA или
> без. Во втором случае это предполагается исправлять.
> 
> Дополнительный список:
> 
...
> nginx
тут все очень простенько и неинтересно. Даже патчить не надо, т.к.
подобный функционал еще не предусмотрен.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: TLS/SSL policy - broken packages

[Mikhail Yakshin]

Konstantin A. Lepikhov пишет:
> Hi Mikhail!
> 
> Friday 09, at 01:22:07 AM you wrote:
> ..
>> firefox, thunderbird, xulrunner, seamonkey, libnspr - общая замечание ко
>> всем, использующим NSS - имеет смысл, видимо, при сборке добавлять новый
>> ALT CA таким builtin token, как сейчас добавляется старый (в файле типа
>> firefox-0.9-alt-ssl-addon-certs.txt). В идеале - не просто добавлять
>> один CA, а устроить обратное преобразование из PEM в формат файла
>> сертификатов Gecko-образных.
> кажется, у нас все-таки сделано наоборт ;)

Надо как-то закрепить технологический процесс. По идее - если мы - сами 
себе хозяева, то и CA bundle тоже должен собираться самостоятельно, на 
основе каких-то мотиваций мейнтейнера соответствующего пакета (или может 
быть создать tls team?) Т.е. единовременная конвертация из сертификатов 
из gecko - хорошо, но дальше может быть ее поддерживать самим? И, 
соответственно, строить преобразование именно в сторону ca-certificates 
=> gecko?

>> MySQL-server - несет в себе в документации пример сертификата CA,
>> который используется как сервером, так и клиентом. Несмотря на то, что
>> сертификат в документации и отключен по умолчанию, при реальном
>> использовании его или аналогов требуется указание положения некоего CA
>> bundle через ключ типа "ssl-ca=SSL/cacert.pem". Вопрос к мейнтейнеру -
>> нет ли возможности / стоит ли патчить или что-то менять в MySQL, чтобы
>> по умолчанию он имел в виду наш общий CA bundle?
> только если вынести сервер из chroot'а - поскольку в chroot все равно
> придется bundle вручную запихивать.

Логично. Тогда пока пропускаем, думаю. Это плавно цепляется за куда 
более сложный вопрос о том, что вообще будет в ближайшем будущем с 
chrooted сервисами.

> BTW, то же самое придется и делать с postfix.

Угу.

>> Дополнительный список:
>>
> ...
>> nginx
> тут все очень простенько и неинтересно. Даже патчить не надо, т.к.
> подобный функционал еще не предусмотрен.

Вычеркиваю.

-- 
WBR, GreyCat

Re: [devel] I: TLS/SSL policy - broken packages

[Vladimir V. Kamarzin]

>>>>> On 09 Feb 2007 at 03:22 "MY" == Mikhail Yakshin writes:

 MY> unreal - несет в себе некий серверный самоподписанный сертификат с
 MY> такими параметрами:

 MY> Issuer: C=RU, ST=Moskovskaya Oblast, L=Korolev, O=Fly Net, OU=Server
 MY> development team, CN=irc.fly
 MY> Subject: C=RU, ST=Moskovskaya Oblast, L=Korolev, O=Fly Net, OU=Server
 MY> development team, CN=irc.fly
 MY> Validity
 MY>     Not Before: Apr 19 17:46:40 2005 GMT
 MY>     Not After : Apr 19 17:46:40 2006 GMT

 MY> Самое главное - он уже давно просрочен. Прошу комментариев у
 MY> мейнтейнера, что это за сертификат и не имеет ли смысл заменить его либо
 MY> на автоматически генерящийся, либо на подписанный нашим CA, например?

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

 MY> freeradius - практически тот же вопрос, что и про MySQL. Пакет несет у
 MY> себя внутри примеры сертификатов и CA, но после прочтения
 MY> /etc/raddb/certs/README возникает вопрос - что будет, если положить ему
 MY> просто один сертификат, подписанный тем CA, что указан у нас в bundle?
 MY> Подхватится ли?

Да, скорее всего подхватится.

-- 
vvk

Re: [devel] I: TLS/SSL policy - broken packages

[Mikhail Yakshin]

Vladimir V. Kamarzin пишет:
>>>>>> On 09 Feb 2007 at 03:22 "MY" == Mikhail Yakshin writes:
> 
>  MY> unreal - несет в себе некий серверный самоподписанный сертификат с
>  MY> такими параметрами:
> 
>  MY> Issuer: C=RU, ST=Moskovskaya Oblast, L=Korolev, O=Fly Net, OU=Server
>  MY> development team, CN=irc.fly
>  MY> Subject: C=RU, ST=Moskovskaya Oblast, L=Korolev, O=Fly Net, OU=Server
>  MY> development team, CN=irc.fly
>  MY> Validity
>  MY>     Not Before: Apr 19 17:46:40 2005 GMT
>  MY>     Not After : Apr 19 17:46:40 2006 GMT
> 
>  MY> Самое главное - он уже давно просрочен. Прошу комментариев у
>  MY> мейнтейнера, что это за сертификат и не имеет ли смысл заменить его либо
>  MY> на автоматически генерящийся, либо на подписанный нашим CA, например?
> 
> Это сертификат, используемый для линковки серверов и для secure-соединений
> клиентов.

Он точно не специфичен для какой-нибудь сети там, нет? Я плохо 
представляю, может быть у IRC-серверов какая-то своя CA есть и, 
соответственно, там должны поставлять какие-то особые сертификаты? Если 
нет - тогда можно просто сгенерировать свежий.

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

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

>  MY> freeradius - практически тот же вопрос, что и про MySQL. Пакет несет у
>  MY> себя внутри примеры сертификатов и CA, но после прочтения
>  MY> /etc/raddb/certs/README возникает вопрос - что будет, если положить ему
>  MY> просто один сертификат, подписанный тем CA, что указан у нас в bundle?
>  MY> Подхватится ли?
> 
> Да, скорее всего подхватится.

=) На этот вопрос надо однозначно, т.е. либо посмотреть в код, либо 
проверить.

-- 
WBR, GreyCat

Re: [devel] I: TLS/SSL policy - broken packages

[Vladimir V. Kamarzin]

>>>>> On 09 Feb 2007 at 13:41 "MY" == Mikhail Yakshin writes:

>>  MY> unreal - несет в себе некий серверный самоподписанный сертификат с
>>  MY> такими параметрами:
>> Это сертификат, используемый для линковки серверов и для secure-соединений
>> клиентов.
 MY> Он точно не специфичен для какой-нибудь сети там, нет? Я плохо 
 MY> представляю, может быть у IRC-серверов какая-то своя CA есть и, 
 MY> соответственно, там должны поставлять какие-то особые сертификаты? Если 
 MY> нет - тогда можно просто сгенерировать свежий.

Ничего специфичного там нет. :)

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

Отлично.

>>  MY> freeradius - практически тот же вопрос, что и про MySQL. Пакет несет у
>>  MY> себя внутри примеры сертификатов и CA, но после прочтения
>>  MY> /etc/raddb/certs/README возникает вопрос - что будет, если положить ему
>>  MY> просто один сертификат, подписанный тем CA, что указан у нас в bundle?
>>  MY> Подхватится ли?
>> 
>> Да, скорее всего подхватится.

 MY> =) На этот вопрос надо однозначно, т.е. либо посмотреть в код, либо 
 MY> проверить.

Положить "просто один сертификат" недостаточно, для конфигурирования EAP-TLS
нужно подсовывать private_key_file (опционально указав в конфиге
private_key_password), собственно сертификат, CA_file и dh_file. Пути к этим
файлам настраиваются в конфиге, т.е. CA можно подсунуть какой нам надо.

См. raddb/eap.conf, src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c

-- 
vvk

Re: [devel] I: TLS/SSL policy - broken packages

[Anton Farygin]

Mikhail Yakshin wrote:
> Приветствую!
> 
> У нас формально введена в действие новая TLS/SSL policy. Ниже приведен
> некий анализ пакетов, которые ей пока (возможно, я ошибаюсь) не следуют.
> Текст получился довольно объемным, но я очень прошу всех мейнтейнров
> перечисленных пакетов найти время и прочитать его внимательно.
> 
> ==========================================================================
> Клиентские пакеты
> ==========================================================================
> 
> curl - несет в себе ca-bundle.crt в формате PEM, вытащенный аж из
> Netscape Communicator 4.72. Ввиду довольно нетривиальной обработки
> местоположения этого файла, предлагается просто убрать из пакета файл
> ca-bundle.crt и в вызове configure указать на наш файл.
> 

С удовольствием. Исправил!

Rgds,
Anton

Re: [devel] I: TLS/SSL policy - broken packages

[Mikhail Yakshin]

Приветствую!

Подправленная и сильно обновленная версия этого списка выложена на:

http://www.freesource.info/wiki/Altlinux/Policy/TLS/enforcement

Прошу всех участвовать и смотреть.

2ldv: я выкинул все пакеты, которые линковались с libcrypto, но не с libssl.

-- 
WBR, Mikhail Yakshin AKA GreyCat