Эта страница была перенесена на
altlinux.org. Текст на freesource.info заморожен.
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):
Клиенты
Их нужно проверять в первую очередь.
- kdenetwork-kopete
- micq
- nmap – использует SSL для залезания на сканируемые порты, проверку сертификатов, видимо, вообще не проводит. greycat@
- qca-tls
- sim
- sim-qt
- X-Downloader
-
w3m ldv@
HTTP
Рекомендованная проверка:
- должно работать: https://heap.altlinux.org/
- должно не работать: 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
XMPP
Пока проверять их не получится, т.к. на jabber.altlinux.org все еще старый сертификат, не подписанный новой CA.
Серверы
Как правило, по своей природе серверы реже проверяют клиентские сертификаты, чем клиенты – серверные, и, как правило, внутри пакета-сервера лежит просто пример серверного сертификата. Эти пакеты имеет смысл смотреть во вторую очередь.
- 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
- Auto Scan?
- 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-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
- tcl-tls
- tcpdump
- tor
- w3c-libwww
- wine
- wpa_supplicant
- x11vnc
- xrdp
- yaz