Материал из Tkabber Wiki
Содержание
Теория
Вы можете перейти прямо к разделу "Практика", однако лучше сначала осилить теорию. А ещё лучше сначала прочитать вводную информацию по поводу соединения "клиент-сервер", чтобы понять, какую роль в установлении соединения играют сертификаты.
Для чего?
Проверка сертификата сервера клиентом, о которой идёт речь, производится на стадии установления TLS-соединения, именуемой рукопожатием (handshake). Рукопожатие означает не только обмен некоторой чисто технической информацией, но и нечто большее: как известно, традиция рукопожатия у европейцев произошла от вполне утилитарного обряда древних людей — показывать при встрече, что у тебя в руке нет камня. Аналогично, клиент и сервер в ходе TLS-рукопожатия "показывают друг другу руки" — предъявляют свой сертификат и исследуют чужой.
Проверка может быть полезна вот по какой причине: существует несколько различных атак на протокол TCP/IP, которые позволяют атакующему "встроиться" в соединение и контролировать его. Кроме того, возможны куда более банальные атаки на аппаратном уровне: например, получив контроль над роутером, через который проходят пакеты между вашим клиентом и сервером, с которым вы хотите соединиться, можно перенаправить трафик такого соединения на другую специально подготовленную машину вместо "настоящего" сервера. Сертификат, предъявляемый сервером, позволяет клиенту удостовериться в том, что сервер "настоящий", и наоборот.
Следует также заметить, что в отличие, например, от VPN, XMPP-сервер в большинстве случаев не интересуется клиентским сертификатом, и в случае соединения с публичными серверами (такими, как jabber.ru), именно это и происходит. Однако в Ткаббере есть возможность указать собственный сертификат и ключ к нему, если требуется.
Как это работает?
Ключевой концепцией в схеме сертификатов является доверие — вы можете доверять или не доверять конкретному сертификату, причём эта операция производится автоматически программным обеспечением, реализующим TLS.
Реализация доверия, однако, является значительно более "хитрым" предметом, чем хотелось бы некоторым пользователям: вы не можете доверять конкретному сертификату сервера напрямую — вместо этого вы должны доверять (возможно, опосредованно — через цепочку других сертификатов) центру сертификации, который выдал соответствующий сертификат.
Причиной подобного устройства является необходимость обеспечения возможности в любой момент менять сертификат любого участника системы: например, можно перегенерировать сертификат сервера, и это не нарушит доверие клиентов к этому серверу. Перегенерация требуется по разным причинам, главная из которых — истечение срока действия сертификата. Также сертификат и его ключ могут быть скомпрометированы (могут попасть в руки злоумышленника), и установление конечного времени жизни сертификата как раз является упреждающей мерой противодействия компрометации.
Когда центр сертификации (ЦС) (в оригинале: "Certification Authority (CA)") выдаёт сертификат, он подписывает сертификат своим секретным ключом, добиваясь двух целей:
- Подписанный с помощью ЭЦП сертификат нельзя изменить физически, сохранив его связность с подписью.
- ЦС "заверяет" сертификат своей подписью, как если бы сертификат был бумажным заявлением, на которым ЦС написал "можно верить".
После этого любой клиент, доверяющий данному ЦС, получив в ходе рукопожатия сертификат, выданный этим ЦС, может автоматически доверять и сертификату.
Чтобы доверять конкретному ЦС, нужно доверять его сертификату. Обычно это достигается импортом такого сертификата в хранилище сертификатов доверенных ЦС. Этот момент ставит главный барьер для многих пользователей Ткаббера, поэтому рассмотрен в деталях ниже, в секции "Практика".
Если "выше" ЦС нет никакой структуры, то доверие к сертификату осуществляется "в один шаг", однако доверие может быть и "многоступенчатым" в силу возможности существования промежуточных центров сертификации. В этом случае промежуточный ЦС имеет свой сертификат, и чтобы доверять сертификатам, выданным этим ЦС, клиент должен доверять не только этому ЦС, но и всем его вышестоящим ЦС, вплоть до главного, который назвается корневым (в оригинале: "Root CA").
Что значит "самоподписанный сертификат в цепочке сертификатов"?
Сделать: дописать про self-signed + unable to
get local issuer...
Практика
Здесь мы рассмотрим, как сделать сертифкат конкретного центра сертификации доверенным с точки зрения Ткаббера.
Существует несколько проблем, связанных с добавлением сертификата ЦС в число доверенных:
- Разные системы имеют разные реализации TLS: например, Windows реализует его поддержку "нативно" при помощи собственных библиотек, API которых ни с чем не совместим, а большинство "остальных" систем полагаются на библиотеку OpenSSL и "обёртки" вокруг неё; существуют и другие свободные реализации, например, GnuTLS и NSS. Ткаббер, как и большинство кросс-платформенных продуктов, использует OpenSSL, и делает он это при помощи расширения Tcl — tls, которое экспортирует функциональность OpenSSL на уровень скриптов Tcl.
- Понятие "системное хранилище сертификатов" вообще представляется почти мифическим, если окинуть взором доступные системы. В частности, в Windows существует единое хранилище сертификатов; предполагается, что там хранятся вообще все сертификаты, включая клиентские и доверенные сертификаты ЦС. Системы, широко использующие OpenSSL (например, популярные дистрибутивы Linux), обычно реализуют собственные системные хранилища доверенных сертификатов ЦС, а клиентскими сертификатами каждая программа управляет, как сочтёт нужным.
Ткаббер в этом смысле равноудалён от всех решений: пакет tls, который он использует, позволяет указать путь до каталога с доверенными сертификатами ЦС или путь до файла с ними. Ткаббер "прячет" обе эти возможности за единственной опцией конфигурации (так как в состоянии сам разобраться — файл или каталог ему указали), а настройка этой опции зависит от личных способностей и пожеланий пользователя.
Сразу следует указать, что по причине, изложенной выше, Ткаббер, увы, не имеет никакого отношения к системному хранилищу сертификатов Windows, и когда он работает на этой системе, вы должны сами позаботиться о том, чтобы сложить нужные вам сертификаты в удобное вам место файловой системы: импортировать их в систему средствами Windows бессмысленно.
Получение сертификата доверенного ЦС
Прежде чем добавить сертификат доверенного ЦС в хранилище и указать на него Ткабберу, этот сертификат нужно заполучить. В идеале соответствующая информация должна быть вам доступна до того, как вы совершите первое подключение к серверу (например, на его веб-сайте). Однако зачастую это не так, и вам придётся проявить некоторую смекалку для выяснения местонахождения сертификата.
Смекалка состоит в том, чтобы по информации о сертификате, которую показывает Ткаббер при неудавшейся проверке, определить URL веб-сайта соответствующего ЦС. Вот пара практических примеров.
Подключение к jabber.ru — сертификат серверу выдан некоммерческой организацией
CAcert.org. Как видно при внимательном рассмотрении,
веб-сайт "виден" в сообщении об ошибке аж дважды: в имени организации ("OU" —
"Organisational Unit") и в поле e-mail поддержки:
В данном случае OpenSSL проверяет сертификат, выданный непосредственно корневым
ЦС, однако этот ЦС не числится в числе доверенных.
Подключение к одному из серверов, входящих в федерацию
xmpp.net, — сертификат выдан организацией
Startcom (а точнее — промежуточным ЦС, занимающимся
выдачей сертификатов серверам xmpp.net):
В данном случае OpenSSL проверяет сертификат, выданный промежуточным ЦС,
проверка целостности сертификата удаётся (поскольку он был прислан сервером
вместе со своим сертификатом — это обычная практика для сертификатов, выданных
промежуточными ЦС, которой, впрочем, администраторы серверов придерживаться не
обязаны), но сертификат вышестоящего ЦС в цепочке недоступен.
Упомянутая смекалка позволит вам заключить, что в первом случае вам следует посетить сайт CAcert.org, а во втором — Startcom. Искать там нужно корневой (root) или "class 1" сертификат. Если сертификат доступен в нескольких форматах, выбирайте PEM как самый удобный.
В данных конкретных случаях этими сертификатами являются:
- Для CAcert: http://www.cacert.org/certs/root.crt
- Для Startcom: http://cert.startcom.org/ca.crt
Примечание: CAcert.org также предлагает сертификат в "формате TEXT". На самом
деле такого формата не существует, а внутри там обычный PEM, предварённый
результатом вызова openssl x509 -text -in class1.crt -noout на исходном
сертификате. Сия схема работает благодаря тому, что OpenSSL при чтении
сертификата в формате PEM игнорирует любой мусор до строки начала сертификата
"-----BEGIN ..." и после строки его окончания (ниже подробно рассмотрено: в
каких случаях и почему это может пригодиться). Поэтому можете скачать
сертификат и в таком виде.
Настройка Ткаббера
Итак, интересующая нас опция настроек Ткаббера называется ::loginconf(sslcacertstore) (от SSL CA Certificate Store), задаёт она путь до каталога или файла с сертификатами доверенных ЦС и удобнее всего настраивается через Tkabber → Настройки → Login.
Если вы используете мультилогин на разные серверы, вам следует изменять переменную sslcacertstore в соответствующих массивах ::loginconf1, ::loginconf2 и так далее, как описано в руководстве.
Добавление доверенных сертификатов ЦС в хранилище
Как уже было замечено выше, OpenSSL может искать подходящий сертификат либо в файле с набором сертификатов, либо в каталоге с файлами сертификатов.
Остановимся подробнее на форматах этих разновидностей хранилищ сертификатов. О них хорошо рассказано в описании функции SSL_CTX_load_verify_locations API OpenSSL, однако здесь мы приведём вольную интерпретацию.
Файл сертификатов — это текстовый (ASCII) файл, который состоит из любого числа сертификатов в формате PEM, расположенных друг за другом; между соседними сертификатами может быть расположен произвольный текст. Это удобно для размещения информации о сертификатах, чтобы проще было ими управлять. Пример такого файла:
Сертификат CAcert.org:
-----BEGIN CERTIFICATE-----
MIIHPTCCBSWgAwIBAgIBADANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290
IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNB
...
-----END CERTIFICATE-----
Конец сертификата CAcert.org
Сертификат Startcom:
-----BEGIN CERTIFICATE-----
MIIFFjCCBH+gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBsDELMAkGA1UEBhMCSUwx
DzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0
...
-----END CERTIFICATE-----
Конец сертификата Startcom.
Каталог сертификатов должен содержать файлы сертификатов в формате PEM, которые должны иметь специально сгенерированные имена. Имя каждого файла является хэшем, подсчитанным на основании содержимого файла по специальному алгоритму, а расширение — номер файла с данным значением хэша, начиная с 0, например: 9d66eef0.0.
С OpenSSL поставляется специальная утилита c_rehash, которая умеет создавать "правильно названные" симлинки на исходные файлы сертификатов (с человекопонятными названиями и, возможно, организованные в систему вложенных каталогов где-то в другом месте файловой системы). Поэтому в Windows, в которой у пользователей очень редко имеется в наличии установленные утилиты из комплекта OpenSSL (да и сам tls обычно слинкован с библиотекой OpenSSL статически), данный метод выглядит слишком сложным для реализации, и рекомендуется использовать файл с сертификатами.
Кое-какие подсказки про c_rehash в Windows: [1] (TODO: окучить).
Собственно, искомый хэш получается выполнением
openssl x509 -hash -noout -in c:/tmp/root.crt
OpenSSL для виндов берётся тут. Впрочем, это не работающее решение, возможно, стоит сделать плагин.
Приватное хранилище
Добавление сертификата в собственное (приватное) хранилище зависит от выбранного формата хранилища.
Если вы используете каталог, просто скопируйте файл с новым сертификатом в него, проследив, чтобы он не перезаписал уже существующий файл. Например, логично переименовать CAcert'овский сертификат в cacert-root.pem при копировании. После этого создайте требуемые симлинки:
$ cd ~/path/to/mycacerts
$ c_rehash .
Если вы поддерживаете хранилище сертификатов в виде файла, просто добавьте содержимое файла в конец файла-хранилища, например, так:
C:\> echo Корневой сертификат CAcert >>c:\mycacerts.pem
C:\> type root.crt >>c:\mycacerts.pem
Переменная конфигурации ::loginconf(sslcacertstore) должна быть установлена в значение, соответствующее полному пути до каталога или файла с вашим хранилищем.
Системное хранилище
Процедура помещения сертификата в хранилище зависит от системы. Обычно специальное средство следит за поддержанием правильной структуры каталога с сертификатами и/или файла с ними.
В Debian и Ubuntu процедура такова:
- Установите настройку ::loginconf(sslcacertstore) в значение /etc/ssl/certs (это каталог) или /etc/ssl/cert/ca-certificates.crt (это файл).
- Убедитесь, что установлен пакет ca-certificates. Дальнейшие действия нужно выполнять с правами суперпользователя.
- Скопируйте нужные файлы сертификатов в каталог /usr/share/ca-certificates; этот каталог может содержать подкаталоги, поэтому можете разместить скачанные сертификаты по подкаталогам по своему усмотрению.
- Запустите update-ca-certificates.
Теперь Ткаббер будет доверять всем сертификатам ЦС из пакета ca-certificates, а также тем, которые вы добавили.
Внимание! В пакете ca-certificates, идущем с Debian Lenny, уже есть сертификаты как CACert, так и StartCom, — в итоге всё, что нужно сделать для работы с jabber.ru и серверами, получившими сертификат от xmpp.net, это пометить указанные два сертификата как доверенные при конфигурировании пакета.