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 – несет в себе некий серверный самоподписанный сертификат с такими параметрами:
Самое главное – он уже давно просрочен. Прошу комментариев у мейнтейнера, что это за сертификат и не имеет ли смысл заменить его либо на автоматически генерящийся, либо на подписанный нашим CA, например?
- ntop – несет в себе самоподписанный /etc/ntop-cert.pem, который точно так же выдан на некоего не очень понятного субъекта и очень давно просрочен:
Прошу комментариев мейнтейнера – зачем такой сертификат лежит в пакете?
- My SQL?-server – несет в себе в документации пример сертификата CA, который используется как сервером, так и клиентом. Несмотря на то, что сертификат в документации и отключен по умолчанию, при реальном использовании его или аналогов требуется указание положения некоего CA bundle через ключ типа «ssl-ca=SSL/cacert.pem». Вопрос к мейнтейнеру – нет ли возможности / стоит ли патчить или что-то менять в My SQL?, чтобы по умолчанию он имел в виду наш общий CA bundle?
- freeradius – практически тот же вопрос, что и про My SQL?. Пакет несет у себя внутри примеры сертификатов и 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 – это все языки программирования, имеющие биндинги на Open SSL? внутри самого пакета с языком или в отдельном пакете. Здесь сложная ситуация: по логике вещей во всех приведенных пакетах тоже просто примеры (правда, лежащих в довольно нетрадиционных местах вроде /usr/lib/erlang/lib/ssl-3.0.11/examples/certs/etc/erlangCA), но
возникает резонный вопрос: если в этих языках программирования использовать их встроенные биндинги на Open SSL? – будет ли автоматически подхватываться наш 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):
Клиенты
Их нужно проверять в первую очередь.
- centericq
- kdenetwork-kopete
- kftpgrabber
- kvirc
-
lftp ldv@
- links1
- links2
- lynx
- mcabber
- micq
- pine
- qca-tls
- sim
- sim-qt
- xchat
- X-Downloader
-
wget ldv@
Серверы
Как правило, по своей природе серверы реже проверяют клиентские сертификаты, чем клиенты – серверные, и, как правило, внутри пакета-сервера лежит просто пример серверного сертификата. Эти пакеты имеет смысл смотреть во вторую очередь.
- 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
- aria2
- asterisk1.4
- asterisk1.4-res_crypto
- astmanproxy
- Auto Scan?
- balsa
- bloom
- captive
- claws-mail
- claws-mail-plugin-spamassassin
- cups
- dsniff
- fetchmail
- fuse-encfs
- gftp-gtk
- gftp-text
- gkrellm
- gnubiff
- gnubiff-gnome
- gnugk
- hostapd
- httperf
- httping
- hydra-common
- imapfilter
- inn
- irssi
- kasablanca
- kdebase-kcontrol
- kdebase-konqueror
- libchipcard
- libchipcard-tools
- libclip-common
- libcups
- libecore
- libesmtp
- libesmtp-devel
- libfwbuilder
- libldap2.3
- libmnetutil
- libmutil
- libneon
- libneon0.25
- libneon0.26
- libomniORB
- libpq4.0
- libpq4.1
- libpw
- libsmbclient-devel
- libssl-devel
- libyaz
- licq-common
- mailfilter
- mail-notification
- msmtp
- msmtp-ssl
- nagios-nrpe
- nagios-plugins-network
- nagios-plugins-nrpe
- nmap
- nut
- nut-cgi
- pam_mount
- pavuk
- perl-Crypt-SSLeay
- perl-Cyrus
- php5-imap
- php5-openssl
- php-imap
- php-openssl
- postal
- python-module-Open SSL?
- 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
- sylpheed
- tcl-tls
- tcpdump
- tor
- w3c-libwww
- w3m
- wine
- wpa_supplicant
- x11vnc
- xrdp
- yaz