39.3 Вычисление параметра GnuTLS

   GnuTLS использует параметры D-H, которые требуют для вычисления существенного времени. Неблагоразумно вычислять их заново для каждой сессии TLS. Поэтому, exim сохраняет эти данные в файле, в своей директории спула, называемой “gnutls-params”. Файл принадлежит пользователю exim'a и читаем лишь его владельцем. Каждый процесс exim'a, который запускает GnuTLS читает параметры 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).



39.4 Требование специфических шифров в OpenSSL

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


39.5 Специфические шифры или другие параметры требующиеся в GnuTLS

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


tls_require_ciphers = !ARCFOUR

разрешают все дефолтовые значения, исключая ARCFOUR, тогда как


tls_require_ciphers = AES : 3DES

разрешает лишь шифрование использующее AES и 3DES.
   Для “tls_require_ciphers” распознаваемые имена - AES_256, AES_128, AES (оба из предшествовавших), 3DES, ARCFOUR_128, ARCFOUR_40 и ARCFOUR (оба из предшествовавших). Список по умолчанию не содержит их всех; в нём находятся AES_256, AES_128, 3DES, и ARCFOUR_128.
   Для “gnutls_require_kx” распознаваемые имена DHE_RSA, RSA (который включает DHE_RSA), DHE_DSS, и DHE (который включает оба DHE_RSA и DHE_DSS). Список по умолчанию содержит RSA, DHE_DSS, DHE_RSA.
   Для “gnutls_require_mac” распознаваемые имена SHA (синоним SHA1), и MD5. Список по умолчанию содержит SHA, MD5.
   Для “gnutls_require_protocols” распознаваемые имена TLS1 и SSL3. Список по умолчанию содержит TLS1 и SSL3.
   В сервере, порядок списка не имеет значения. Сервер будет извещать о доступности всех допустимых методов шифрования. Однако, в клиенте, порядок в списке “tls_require_ciphers” определяет предпочтительный порядок алгоритмов шифрования. Первым пробуется первый из клиентского списка, о котором, также, извещал сервер. Порядок значений по умолчанию - перечислен выше.



39.6 Конфигурирование сервера exim для использования TLS

   Когда 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. (Есть несколько комментариев ниже, в разделе 39.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. (Для исходящих доставок SMTP переменная “$tls_cipher” сброшена - смотрите раздел 39.9)
   Как только соединение TLS установлено, ACL которые запускаются для последующих команд SMTP могут проверить имя метода шифрования и изменить свои действия соответствующим образом. Имена методов шифрования изменяемые, зависят от используемой библиотеки TLS. Например, OpenSSL использует имя DES-CBC3-SHA для шифрования, известного в других контекстах как TLS_RSA_WITH_3DES_EDE_CBC_SHA. Для дополнительных деталей проверьте документацию OpenSSL.



39.7 Запрос и проверка клиентских сертификатов

   Если вы хотите, чтобы сервер 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” пуста.



39.8 Отменённые сертификаты

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



39.9 Конфигурирование клиента exim'a для использования TLS

   Лог селекторы “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” установлена опция “tls_require_ciphers”, она должна быть именем файла, или, только для OpenSSL (не для GnuTLS), директорией, которая содержаит коллекцию ожидаемых серверных сертификатов. Клиент проверяет сертификат сервера со своей коллекцией, принимая во внимание любые отозванные сертификаты, которые находятся в списке, заданном опцией “tls_crl”.
   Если для транспорта “smtp” установлена опция “tls_require_ciphers”, она должна содержать список разрешённых методов шифрования. Если любая из этих проверок неудачна, доставка к текущему хосту прекращается, и транспорт “smtp” пробует доставить на альтернативный хост, если он есть.
   Отметьте: Эти опции должны быть заданы в транспорте “smtp” exim'a для использования TLS, когда он работает как клиент. Exim не предполагает, что серверный сертификат (установленный путём глобальной опции с тем же самым именем) также должен использоваться при работе в роли клиента.
   Все опции TLS, в транспорте “smtp”, раскрываются до использования, с “$host” и “$host_address” содержащими имя и адрес сервера, на который подключился клиент. Принудительная ошибка раскрытия заставляет exim вести себя так, как будто соответствующая опция незадана.
   До установления SMTP соединения, переменные “$tls_cipher” и “$tls_peerdn” - пусты. (В процессе первого соединения, оно содержат значения которые которые установлены при приёме сообщения) Если, в последствии, STARTTLS проходит успешно, эти переменные устанавливаются в соответствующие значения для исходящего соединения.



39.10 Несколько сообщений через одно шифрованное TCP/IP соединение

   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.



39.11 Сертификаты и всё такое

   Для полного понимания работы 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/



39.12 Цепочки сертификатов

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



39.13 Самоподписанные сертификаты

   Вы можете создать самоподписанный сертификат, используя команду “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/.


=============
translated by lissyara
verifying by Gerk