GnuTLS использует параметры RSA и D-H, которые требуют для вычисления существенного времени. Неблагоразумно вычислять их заново для каждой сессии TLS. Поэтому, exim сохраняет эти данные в файле, в своей директории спула, называемой “ gnutls-params ”. Файл принадлежит пользователю exim`a и читаем лишь его владельцем. Каждый процесс exim`a, который запускает GnuTLS читает параметры RSA и D-H из этого файла. Если файл не существует, первый процесс exim`a, которому он нужен, вычисляет данные и записывает их во временный файл, переименовываемый по завершении. Не имеет значения, если несколько процессов exim`a делают это одновременно (кроме траты некоторых ресурсов). Как только файл помещён на место, новый процессы exim`a немедленно начинают его использовать.
   Для максимальной безопастности, параметры, которые сохраняются в этом файле, периодически, должны быть повторно вычислены, частота зависит от уровня вашей параноидальности. Упорядочивание этого - принципиально просто; просто удалите файл, когда вы хотите вычислить новое значение. Однако, могут быть проблемы. Для вычисления новых параметров необходимы случайные числа, и они берутся из “ /dev/random ”. Если система не очень активна, “ /dev/random ” может задержать возврат данных, пока не будет доступно достаточно хаоса. Это может вызывать зависание exim`a на довольно существенное время, вызывая таймауты для входящих соединений.
   Решение - генерировать параметры снаружи exim`a. Они сохраняются в “ gnutls-params ” в формате PEM, что означает, что они могут быть сгенерированы внешне, используя команду “ certtool ”, которая является частью GnuTLS.
   Для замены параметров новыми, вместо удаления файла и разрешения exim`y пересоздать его, вы можете генерировать новые параметры используя “ certtool ”, и, после завершения, заменить файл кэша exim`a путём переименования. Уместные команды - что то типа этого:


# rm -f new-params # touch new-params # chown exim:exim new-params # chmod 0400 new-params # certtool --generate-privkey --bits 512 >new-params # echo "" >>new-params # certtool --generate-dh-params --bits 1024 >> new-params # mv new-params gnutls-params

   Если exim никогда не генерирует параметры самостоятельно, возможность остановки - удалена (наверное, имеется ввиду задержка при генерации - прим. lissyara).



   В библиотеке OpenSSL есть функция, которая может передавать список наборов шифров до того, как имеет место переговор о шифре. Этим определяется, какие шифры доступны. Список - разделён двоеточиями, и может содержать имена типа DES-CBC3-SHA. Exim передаёт раскрытое значение “ tls_require_ciphers ” напрямую этому вызову функции. Следующее циторование документации OpenSSL определяет, какие формы элементов допустимы в строке шифра:


   Библиотека GnuTLS не имеет комбинированной функции, как OpenSSL. Вместо этого, она позволяет вызывающему задать отдельные списки методов обмена ключей, главных алгоритмов шифрования, и алгоритмов MAC. К сожалению, эти списки - числовые, и библиотека не имеет функции для превращения имён в номера. Следовательно, список распознаваемых имён должен быть встроен в приложение.
   В настоящее время, exim разрешает изменять лишь список главных алгоритмов шифрования. Опция  “ tls_require_ciphers ” - имет такой же формат, что и у OpenSSL. Exim ищет каждый элемент для имени доступного алгоритма. Например, если список содержит RSA_AES_SHA, тогда распознаётся AES.
   Список шифровальных алгоритмов отправляется с дефолтовой установкой алгоритмов. Если первый элемент в “ tls_require_ciphers ” не начинается с восклицательного знака, все дефолтовые элементы удаляются. Таким образом, могут использоваться лишь заданные значения. Если первый элемент в “ tls_require_ciphers ” действительно начинается с восклицательного знака, дефолтовые начения остаются в списке.
   Тогда, любой элемент, начинающийся с восклицательного знака, вызывает удаление релевантных алгоритмов из списка, и любой элемент, не начинающийся с восклицательного знака, вызывает добавление релевантных алгоритмов в список. Таким образом,


tls_require_ciphers = !RSA_ARCFOUR_SHA

разрешают все дефолтовые значения, кроме использующих ARCFOUR, тогда как


tls_require_ciphers = AES : 3DES

разрешает лишь шифрование использующее AES и 3DES. В настоящее время, распознаются алгоритмы: AES_256, AES_128, AES (оба из предшествовавших), 3DES, и ARCFOUR_128. Нераспознанные алгоритмы - игнорируются. В сервере, порядок списка не имеет значения; сервер будет извещать о доступность всех допустимых методов шифрования. Однако, в клиенте, порядок списка определяет порядок для алгоритма. Первым пробуется первый из клиентского списка, о котором, также, извещал сервер. Порядок значений по умолчанию - пеерчислен выше.



   Когда exim собран с поддержкой TLS, он извещает клиентские хосты, совпадающие с “ tls_advertise_hosts ” о доступности команды STARTTLS, но не какие-либо другие хосты. Дефолтовое значение этой опции - незадано, что означает, что о STARTTLS никто не извещается. Такое значение по умолчанию выбрано поскольку вы должны привести в порядок некоторые другие опции, чтобы сделать доступным TLS, и, также, это разумно для систем, которые хотят использовать TLS лишь в роли клиента.
   Если клиент выдаёт команду STARTTLS, и на сервере существует какая-то конфигурационная проблема, команда отклоняется с ошибкой 454. Если клиент упорствует в попытках подавать команды SMTP, все они, кроме QUIT, отклняются с ошибкой:


554 Security failure

   Если команда STARTTLS подаётся в пределах существующей TLS-сессии, она отклоняется с кодом ошибки 554.
   Для включения операций TLS на сервере, вы должны установить опцию “ tls_advertise_hosts ” в соответствие каким-то хостам. Вы можете, разумеется, установить её в “*” - для соответствия всем хостам. Однако, это не всё, что вы должны сделать. TLS-сессии на сервере не будут работать без некоторого дальнейшего конфигурирования в конце сервера.
   По слухам известно, что все существующие клиенты, которые поддерживают TLS/SSL, используют шифрование RSA. Чтобы это работало, вам необходимо установить в сервере:


tls_certificate =/some/file/name tls_privatekey =/some/file/name

   Фактически, эти опции - раскрываемые строки,таким образом, вы можете сделать их зависимыми от подключенного клиента, если захотите. Первый файл содержит серверный сертификат X509, и, второй, содержит частный ключ, который с ним идёт. Эти файлы должны быть читаемы пользователем exim`a, и, всегда должны быть даны с полным путём. Это может быть один и тот же файл, если в нём содержатся сертификат и ключ. Если опция “ tls_privatekey ” не задана, или если раскрытие принудительно неудачно, или результат - пустая строка, предполагается такой случай. Файл сертификата также может содержать промежутчный сертификаты, которые необходимы для отсылки клиенту, с целью аутентифицировать сертификаты сервера.
   Если вы непонимаете о ключах и сертификатах, пожалуйста, попробуйте найти источник этой вводной информации, которая не является специфической для exim`a. (Есть несколько комментариев ниже, в разделе 38.11.)
   Отметьте: Эти опции не применяются когда exim работает как клиент - они применяются лишь в случае сервера. Если вам необходимо использовать сертификат в exim`e в роли клиента, вы должны установить опции с теми же самыми названиями в транспорте “ smtp ”.
   Только с этими опциями, сервер exim`a способен использовать TLS. Этим не требуется, чтобы клиент обладал сертификатом (но, смотрите ниже, как настоять на этом). Существует одна иная опция, которая бывает необходима в других ситуациях. Если опция


tls_dhparam = /some/file/name

установлена, библиотека SSL инициализируется для использования шифрования Diffie-Hellman, с параметрами, содержащимися в файле. Это увеличивает набор методов шифрования, поддерживаемых сервером. Смотрите команду


openssl dhparam

для способа генерации этих данных. В настоящее время, “ tls_dhparam ” используется лишь когда exim слинкован с OpenSSL. При использовании GnuTLS, она игнорируется.
   Строки, предоставляемые для этих трёх опций, раскрываются при каждом подключении клиентского хоста. Поэтому возможно использовать различные сертификаты и ключи для разных хостов, если вы этого желаете, для управления раскрытием, путём использования клиентского IP-адреса в переменной “ $sender_host_address ”. Если строка раскрытия принудительно неудачна, exim ведёт себя так, будто эта опция неустановлена.
   В переменную “ $tls_cipher ” устанавливается метод шифрования, о котором договорились для входящего соединения TLS. Это включается в заголовок “ Received: ” входящего сообщения (по умолчанию - разумеется, вы можете это изменить), и, также, включается в в строку лога прибывающего сообщения, с ключом “X=”, если не выключен лог селектор “ tls_cipher ”. Кондишен “ encrypted ” может использоваться для тестирования специфического шифрования в ACL.
   ACL`ы, которые запускаются для последующих команд SMTP могут проверить имя метода шифрования и изменить свои действия соответствующим образом. Имена методов шифрования - используемые OpenSSL. Они могут отличаться от имён используемых в других местах. Например, OpenSSL использует имя DES-CBC3-SHA для шифрования, известного в других контекстах как TLS_RSA_WITH_3DES_EDE_CBC_SHA. Для дополнительных деталей проверьте документацию OpenSSL.



   Если вы хотите, чтобы сервер exim`a запросил сертификат при переговорах о TLS-сессии с клиентом, вы должны установить или “ tls_verify ” или “ tls_try_verify_hosts ”. Разумеется, вы можете установить любой из них в “*”, для применения ко всем соединениям TLS. Для любого хоста, который совпадает с этими опциями, exim запрашивет сертификат как часть установки сессии TLS. Содержимое сертификата проверяется путём его сравнения со списком ожидаемых сертификатов. Они должны быть доступны в файле, или, только для OpenSSL (не для GnuTLS), каталоге, идентифицируемом путём  “ tls_verify_certificates ”.
   Файл может содержать много сертфикатов, связанных конец к концу. Если используется директория (только для OpenSSL), каждый сертификат должен быть в отдельном файле, с именем (или символической ссылкой) формы “ <hash>.0”, где “ <hash> ” - значение хэша созданное из сертификата. Вы можете вычислить релевантный кэш путём запуска команды


openssl x509 -hash -noout -in /cert/file

где “ /cert/file ” - содержит один сертификат.
   Различие между “ tls_verify_hosts ” и “ tls_try_verify_hosts ” - в том, что происходит если клиент не предоставляет сертификат, или если сертификат не совпадает ни с одним из сертификатов в коллекции из “ tls_verify_certificates ”. Если клиент совпадает с “ tls_verify_hosts ”, попытка установить TLS-сессию прерывается, и входящее соединение обрыватся. Если клиент совпадает с “ tls_try_verify_hosts ”, продолжается (шифрованная) SMTP-сессия. ACL`ы, запускаемые для последующих команд SMTP, могут детектировать факт, что сертификат не был проверен, и соотвтественно изменить свои действия. Например, вы можете настаивать на сертификате до принятия сообщения для релея, но не когда сообщения предназначено для локальной доставки.
   Когда клиент предоставляет сертификат, (проверенный, или нет), значение DN сертификата становится доступным в переменной “ $tls_peerdn ” в процессе последующей обработки сообщения.
   Поскольку часто это - длинная текстовая строка, по умолчанию она не включается в строку лога или заголовок “ Received: ”. Вы можете принять меры для её логгирования, установив ключ “DN=”,в лог селекторе “ tls_peerdn ”, и вы можете использовать “ received_header_text ” - для изменения заголовка “ Received: ”. Когда сертификат не предоставлен, переменная “ $tls_peerdn ” пуста.



   Издатели сертификатов выпускают Списки Аннулированных Сертификатов (Certificate Revocation Lists - CRLs), когда сертификаты отменяются. Если у вас есть такой список, вы можете передать его серверу exim`a используя глобальную опцию “ tls_crl ”, и клиенту exim`a, используя опцию с идентичным названием для транспорта “ smtp ”. В каждом случае, значение опции раскрывается, и должно быть именем файла содержащего CRL в формате PEM.



   Лог селекторы “ tls_ciphe ” и “ tls_peerdn ” применяются к исходящим SMTP-доставкам также, как и ко входящим, последние вызывают логгирование серверных DN сертификатов. Оставшаяся клиентская конфигурация для TLS - вся в транспорте “ smtp ”.
   Нет необходимости устанавливать какие-либо опции для работы TLS в транспорте “ smtp ”. Если exim собран с поддержкой TLS, и сервер оповестил о поддержке TLS, транспорт “ smtp ”.всегда пробует запустить TLS-сессию. Однако, это может быть предотвращено установкой “ hosts_avoid_tls ” (транспортная опция) в список серверных хостов, с которыми не используется TLS.
   Если вы не хотите чтобы exim пытался отправить сообщения незашифрованными, когда попытка установки шифрованного соединения была неудачной, вы можете установить опцию “ hosts_require_tls ” в список хостов, для которых шифрования является обязательным. Для этих хостов, доставка всегда задерживается, если не может быть установлено шифрованное соединение. Если для адреса есть другие хосты, они пробуются обычным способом.
   Когда хост сервера не находится в “ hosts_require_tls ”, exim может попробовать доставить сообщение незашифрованным. Он всегда так делает, если ответ на STARTTLS - код 5xx. Для временного кода ошибки, или для ошибки переговоров о сессии TLS после успешного кода ответа, происходящее контролируется путём опции “ tls_tempfail_tryclear ” транспорта “ smtp ”. Если она ложна, доставка к хосту задерживается, и пробуются другие хосты (если доступны). Если она истинна, exim пытается доставить нешифрованное сообщение после 4xx ответа на STARTTLS, и, если STARTTLS принимается, но последующие переговоры о TLS неудачны, exim закрывает текущее соединение (поскольку оно в неизвестном состоянии), открывает новое к тому же самому хосту, и, затем, пытается доставить сообщение нешифрованным.
   Опции “ tls_certificate ” и “ tls_privatekey ” транспорта “ smtp ” предоставляют клиенту сертификат, который он передаёт на сервер, если тот его запрашивает. Если сервер - exim, то он будет просить сертификат лишь если клиент совпадает с опцией “ tls_verify_hosts ” или “ tls_try_verify_hosts ”. Отметтьте: Эти опции должны быть заданы в транспорте “ smtp ” exim`a для использования TLS, когда он работает как клиент. Exim не предполагает, что серверный сертификат (установленный путём глобальной опции с тем же самым именем) также должен использоваться при работе в роли клиента.
   Если установлена опция “ tls_verify_certificates ”, она должна быть именем файла, или, только для OpenSSL (не для GnuTLS), директорией, которая, как ожидается, содержит коллекцию серверных сертификатов. Клиент проверяет сертификат сервера со своей коллекцией, принимая во внимание любые отозванные сертификаты, которые находятся в списке, заданном опцией “ tls_crl ”.
   Если для транспорта “ smtp ” установлена опция “ tls_require_ciphers ”, она должна содержать список разрешённых методов шифрования. Если любая из этих проверок неудачна, доставка к текущему хосту прекращается, и транспорт “ smtp ” пробует доставить на альтернативный хост, если он есть.
   Все опции TLS, в транспорте “ smtp ”, раскрываются до использования, с “ $host ” и “ $host_address ” содержащими имя и адрес сервера, на который подконнектился клиент. Принудительная ошибка раскрытия заставляет exim вести себя так, как будто соответствующая опция незадана.



   Exim посылает много сообщений по одному TCP/IP соединению путём запуска нового процесса для каждого сообщения, передавая сокет от одного процесса следующему. Эта реализация не очень хорошо для работы с TLS, поскольку есть много информации о состоянии, ассоциированной с соединением TLS, а не только идентификатор сокета. Передача всей информации о состоянии другому процессу - невыполнима. Следовательно, exim завершает существующую сессию TLS до передачи сокета новому процессу. Новый процесс может попробовать запустить сеанс TLS, и, в случае успеха, может попробовать заново аутентифицироваться, если используется AUTH, до посылки следующего сообщения.
   Из RFC неясно, действительно или нет, SMTP сессия продолжается в чистом виде после закрытия TLS, или же TLS может быть перезапущен позже, как было описано. Однако, если сервер - exim, эта остановка и реинициализация - работает. Неизвестно, каким (или обоими) образом себя ведут другие сервера, если клиент закрывает сеанс TLS, и продолжает с нешифрованным SMTP, но, разумеется, есть те, которые не работают. Для таких серверов, exim не должен передавать сокет другому процессу, поскольку неудача последующей попытки его использования заставила бы exim записать в логи временную ошибку хоста, и задержать иные доставки на этот хост.
   Для тестирования этого случая, exim посылает команду EHLO на сервер после закрытия TLS сессии. Если она удачна, то соединение закрывается вместо пеердачи новому новому процессу доставки, но информация о повторе не записывается.
   Также есть ручная отмена; вы можете установить опцию “ hosts_nopass_tls ” транспорта “ smtp ” в совпадение с этими хостами, для которых exim не должен передавать соединение новому процессу, если используется TLS.



   Для полного понимания работы TLS, вам необходимо знать о сертификатах, подписании сертификатов, и авторизаторах сертификатов. Это - не место для обучения (имеется ввиду - этот документ - прим. lissyara), тем более, что я не очень много знаю об этом. Некоторое полезное введение может быть найдено в FAQ дополнения SSL к Apache, в настоящее время:
http://www.modssl.org/docs/2.7/ssl_faq.html#ToC24
   Другие части документации по “ modssl ” - также полезны, и имеют ссылки на дальнейшие файлы. Книга Eric`a Rescorla`a - “ SSL and TLS ”, опубликованная Addison-Wesley (ISBN 0-201-61598-3), содержит введение и дополнительные всесторонние описания. Некотрые типовые программы, взятые из книги, доступны  по адресу:
http: // www.rtfm.com/openssl-examples/



   Файл указанный в “ tls_certificate ” может содержать более одного сертификата. Это полезно в случае, когда посылаемый сертификат проверяется промежуточным сертификатом, которого не имеет другая сторона. Несколько сертификатов должны быть в правильном порядке в файле. Вначале, хост сертифицирует сам себя, затем, следующий сертификат для проверки выданного хостом, затем следующее - для проверки предыдущего, и так далее, до (опционально) - корневого сертификата. Корневой сертификат уже должен быть доверенным у получателя, для успешной проверки, разумеется, если он заранее не установлен, посылка корневого сертификата вместе с остальными делает его доступным пользователю для установки, если конечный получатель - пользовательский MUA, коотрый может взаимодействовать с пользователем.



   Вы можете создать самоподписанный сертификат, используя команду “ req ”, предоставляемую OpenSSL, например так:


openssl req -x509 -newkey rsa: 1024 -keyout file1 -out file2 \ -days 9999 -nodes

   “ file1 ” и “ file2 ” могут быть одним и тем же файлом; ключ и сертификат разграничены, и могут быть идентифицированы независимо. Опция “ -days ” период, в течение которого сертификат действителен. Опция “ -nodes ” - важна: если вы её не зададите, ключ шифруется с запрашиваемой у вас парольной фразой, и любое использование ключа вызывает запрос парольной фразы. Это бесполезно, если вы собираетесь использовать ключ в MTA, где запрос невозможен.
   Самоподписанный сертификат, сделанный таким образом, вполне достаточен для тестирования, и может быть адекватен для всех ваших требований, если вы, главным образом, интересуетесь шифрованием передачи, а не секурной идентификацией.
   Однако, многие клиенты требуют чтобы предоставленный сервером сертификат был пользовательским (также назваемый “leaf” or “site”) сертификатом, и не самоподписанным сертификатом. В этой ситуации, самоподписанный сертификат, должен быть установлен на клиентском хосте как доверенный корневой “ авторитативный сертификат ” (CA), и сертификат используемымй exim`ом, должен быть пользовательским сертификатом, подписанным с этим самоподписанным сертификатом.
   Для информации о создании самоподписанных сертификатов и использовании их для подписания пользовательских сертификатов, смотрите часть “ General implementation overview ” книги “Open-source PKI”, доступной в онлайне http://ospkibook.sourceforge.net/.




=============
Автор перевода: lissyara, оригинал: http://www.lissyara.su/?id=1200




Партнёры:

Хостинг: