TLS/enforcement

TLS/SSL policy enforcement status

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

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

• 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 полиси.

Все остальные пакеты, линкующиеся с libssl

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

Дополнительный список (уже подправлен — выкинуты те библиотеки, которые линкуются только с libcrypto, но не с libssl):

Клиенты

Их нужно проверять в первую очередь.

• kdenetwork-kopete
• micq
• nmap — использует SSL для залезания на сканируемые порты, проверку сертификатов, видимо, вообще не проводит. greycat@
• qca-tls
• sim
• sim-qt
• X-Downloader
• w3m ldv@

HTTP

Рекомендованная проверка:

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

• aria2 — видимо, поддержки CA и проверок сертификатов нет вообще; если кому-нибудь нужно — то нужно сделать. greycat@
• lftp ldv@
• links1
• links2
• lynx
• pavuk — видимо, поддержки CA и проверок сертификатов нет вообще; если кому-нибудь нужно — то нужно сделать. greycat@
• wget ldv@

E-mail (imaps, pop3s, s/mime)

• claws-mail
• claws-mail-plugin-spamassassin
• pine
• balsa
• fetchmail
• gnubiff
• gnubiff-gnome
• imapfilter
• libesmtp
• libesmtp-devel
• mail-notification
• sylpheed

FTP

• gftp-gtk
• gftp-text
• kasablanca
• kftpgrabber

IRC

• irssi
• kvirc
• xchat

XMPP

Пока проверять их не получится, так как на jabber.altlinux.org все еще старый сертификат, не подписанный новой CA.

• centericq
• mcabber

Серверы

Как правило, по своей природе серверы реже проверяют клиентские сертификаты, чем клиенты — серверные, и, как правило, внутри пакета-сервера лежит просто пример серверного сертификата. Эти пакеты имеет смысл смотреть во вторую очередь.

• cyrus-imapd
• cyrus-imapd-murder
• cyrus-imapd-utils
• jabber
• jabberd2-c2s
• jabberd2-resolver
• jabberd2-router
• jabberd2-s2s
• jabberd2-sm
• lighttpd
• nginx тут все очень простенько и неинтересно. Даже патчить не надо, так как подобный функционал еще не предусмотрен. — lakostsis@
• postfix-tls
• postgresql8.0
• postgresql8.0-server
• postgresql8.1
• postgresql8.1-server
• proftpd-mod_tls

Unsorted

• appliance-fake-utm
• asterisk1.4
• asterisk1.4-res_crypto
• astmanproxy
• AutoScan
• bloom
• captive
• cups
• dsniff
• fuse-encfs
• gkrellm
• gnugk
• hostapd
• httperf
• httping
• hydra-common
• inn
• kdebase-kcontrol
• kdebase-konqueror
• libchipcard
• libchipcard-tools
• libclip-common
• libcups
• libecore
• libfwbuilder
• libldap2.3
• libmnetutil
• libmutil
• libneon
• libneon0.25
• libneon0.26
• libomniORB
• libpq4.0
• libpq4.1
• libpw
• libsmbclient-devel
• libssl-devel
• libyaz
• licq-common
• mailfilter
• msmtp
• msmtp-ssl
• nagios-nrpe
• nagios-plugins-network
• nagios-plugins-nrpe
• nut
• nut-cgi
• pam_mount
• perl-Crypt-SSLeay
• perl-Cyrus
• php5-imap
• php5-openssl
• php-imap
• php-openssl
• postal
• python-module-OpenSSL
• python-modules
• qpamat
• ruby-module-openssl
• seirospbx1.4
• seirospbx1.4-res_crypto
• sendmail-submit
• siege
• sipp
• snort-snmp
• snort-snmp+flexresp
• socat
• spamassassin-spamc
• squid-server
• ssmtp-ssl
• tcl-tls
• tcpdump
• tor
• w3c-libwww
• wine
• wpa_supplicant
• x11vnc
• xrdp
• yaz