Практика OpenSSL

ВСЕВОЛОД СТАХОВ

Практика OpenSSL

OpenSSL применяется во множестве сетевых серверов. В данной статье я бы хотел рассказать о работе с ssl Apache, постфикса и курьера. Соответственно происходит шифрация трафика http-, smtp- и imap(pop3)-протоколов. При использовании шифрации ssl обычно меняется порт, чтобы клиент мог корректно определить использование безопасного соединения. Для начала я расскажу об использовании ssl в апаче.

Apache может работать с ssl через модуль mod_ssl, который может быть скачан с www.apache-ssl.org. Для компиляции Apache с данным модулем выполняем следующее:

$ cd /usr/src/apache_1.3.x/src

$ SSL_BASE=/usr/src/mod_ssl/ ./configure -- ... --enable-module=ssl

После успешной компиляции необходимо получить сертификат организации. Тут есть два пути: первый – это создать self-signed сертификат, второй – получить сертификат от trusted root CA. Скорее всего, второй вариант будет не бесплатный, например, на www.thawte.com предлагают продать сертификат www-сервера за 160$ сроком действия на год. С другой стороны, такой способ обеспечивает полную безопасность клиента, т.к. он будет знать, что сертификат действителен. Обычно у браузеров есть набор trusted root CA, и когда браузер получает сертификат, подписанный одним из trusted ca, то он может корректно проверить подпись и решить на её основании о действительности сертификата www-сервера. Если же браузер получает self-signed сертификат, то он спрашивает у пользователя, можно ли доверять этому сертификату, т.к. в этом случае клиент не может точно определить, откуда к нему пришёл этот сертификат и не может проверить его подпись, т.к. она не входит в его trusted root CA. В качестве альтернативного варианта, если вы работаете с несколькими крупными клиентами, можно посоветовать принести каждому клиенту свой сертификат (например, на дискетке или компакте) и вручную добавить его в trusted root CA клиента. Для работы через ssl в локальной сети обычно используются self-signed сертификаты, что естественно. Сертификат сервера обычно подписывается сертификатом организации.

Итак, сгенерируем секретный ключ RSA и self-signed сертификат организации:

dd if=/dev/urandom of=/etc/openssl/.rnd -count 64

openssl genrsa -rand /etc/openssl/.rnd -des3 -out /etc/openssl/org.key

openssl req -new -key /etc/openssl/org.key -config /etc/openssl/org.cnf -out /etc/openssl/org.csr

openssl x509 -req -signkey /etc/openssl/org.key -in /etc/openssl/org.csr -extfile /etc/openssl/org.cnf \

    -out /etc/openssl/org.crt -days 365

Пример конфигурационного файла сертификата организации (CA-сертификат, поэтому определяем некоторые расширения, которые указываем программе x509):

[ req ]

default_bits                   = 1024

distinguished_name             = req_DN

RANDFILE                       = ca.rnd

extensions                     = v3_req

[ req_DN ]

countryName                    = "1. Country Name (2 letter code)"

countryName_default            = RU

countryName_min                = 2

countryName_max                = 2

stateOrProvinceName            = "2. State or Province Name (full name)"

stateOrProvinceName_default    = region

localityName                   = "3. Locality Name (eg, city)"

localityName_default           = city

0.organizationName             = "4. Organization Name (eg, company)"

0.organizationName_default     = organization

organizationalUnitName         = "5. Organizational Unit Name (eg, section)"

organizationalUnitName_default = Certificate Authority

commonName                     = "6. Common Name (eg, CA name)  "

commonName_max                 = 64

commonName_default             = ""

emailAddress                   = "7. Email Address (eg,cert@organization.ru)"

emailAddress_max               = 40

emailAddress_default           = ""

[ v3_req ]

subjectAltName                 = email:copy

basicConstraints               = CA:true

nsComment                      = "CA certificate of our organization"

nsCertType                     = sslCA

Теперь создаём сертификат сервера:

dd if=/dev/urandom of=/etc/openssl/.rnd count=64

openssl genrsa -rand /etc/openssl/.rnd -out /etc/openssl/httpd.key

openssl req -new -key /etc/openssl/httpd.key -config /etc/openssl/httpd.cnf -out /etc/openssl/httpd.csr

И подписываем его сертификатом организации:

openssl x509 -req -signkey /etc/openssl/org.key -CA /etc/openssl/org.crt -extfile /etc/openssl/httpd.conf \

    -out /etc/openssl/httpd.crt -days 365

Опять же здесь нужны расширения для серверного сертификата, ещё учтите, что лучше задавать CN серверного сертификата как имя сервера:

extensions       = v3_req

[ v3_req ]

basicConstraints = CA:false

nsComment        = "Apache server certificate"

nsCertType       = server

И ещё одна тонкость: при создании секретного ключа сервера его лучше не шифровать. Хотя если это необходимо в соображениях безопасности, то можно и зашифровать, но при этом Apacheпри запуске будет спрашивать пароль секретного ключа сервера (на экране при этом ничего отображаться не будет, поэтому если вы долго ждёте запуска Apache при включенном ssl и зашифрованном ключе, попробуйте ввести пароль).

После генерации сертификата начинаем настройку Apache. Имеет смысл при использовании ssl создать отдельный файл конфигурации, который будет описывать параметры ssl. Также обычно создаётся виртуальный сервер ssl, который висит на 443 порту (https), в отличие от стандартных виртуальных серверов, ssl-сервер должен однозначно соответствовать паре IP-адрес : порт (т.е. на один IP-адрес и порт можно повесить только один ssl-виртуальный сервер). Для начала включим ssl-модуль в Apache. После этого все настройки ssl полезно окружить условием <IfModule mod_ssl.c></IfModule>:

httpd.conf

# Загружаем модуль ssl (он может находиться в modules или extramodules). Учтите, если вы используете модуль mod_php,

# то его необходимо добавить ПОСЛЕ модуля ssl, иначе последствия могут быть печальны (core dumpted).

LoadModule ssl_module modules/libssl.so

AddModule mod_ssl.c

# Добавляем некоторые MIME-типы.

AddType application/x-x509-ca-cert .crt

AddType application/x-pkcs7-crl    .crl

AddType application/x-pkcs12-cert  .p12

# Слушаем на порту 443(https).

Listen 443

# Определяем способ запроса пароля к секретному ключу сервера как built-in, или можно определить путь к внешнему скрипту,

# но в большинстве случаев достаточно built-in-метода.

SSLPassPhraseDialog builtin

# Определяем кеширование данных ssl в файле данных (none для отключения кеширования) и таймаут обновления данных в кеше.

# Можно использовать при указании файла кеша специальный формат shm (shm:/path/file [size]), который обеспечивает высокую

# производительность и работает через механизм shared memory.

SSLSessionCache         dbm:logs/ssl_scache

#SSLSessionCache        none

SSLSessionCacheTimeout  300

# Настраиваем генератор случайных чисел, указываем метод для рандомизации. Указывается два источника рандомизации: начальный (startup)

# и инициализирующийся при присоединении клиента (connect). Возможные значения для этого параметра:

# builtin – встроенный источник рандомизации,

# file:имя_файла – читаются данные из файла,

# file:имя_файла число_байт –  читается только определённое

# число байт из файла (полезно  для /dev/random и /dev/urandom)

SSLRandomSeed startup file:/dev/random  512

SSLRandomSeed connect file:/dev/random  512

#SSLRandomSeed startup builtin

#SSLRandomSeed connect builtin

#SSLRandomSeed startup file:/dev/urandom 512

#SSLRandomSeed connect file:/dev/urandom 512

# Настраиваем логи ssl. Указываем файл и уровень записи в лог, возможные значения уровня по возрастающему числу

# регистрируемых данных: none, error, warn, info, trace, debug.

SSLLog      logs/ssl_engine_log

SSLLogLevel info

После настройки самого Apache обычно приступают к настройке виртуального ssl-сервера. Обычно основной сервер оставляют висеть на 80 порту, а на главной странице размещают ссылку на переход в безопасный режим (или ставят редирект, но это уж дело вкуса или политики безопасности).

vhosts.conf

<IfModule mod_ssl.c>

# Определяем виртуальный сервер, висящий на том же IP-адресе, что и основной, но слушающий на 443 порту.

<VirtualHost _default_:443>

# Основные настройки виртуального сервера.

DocumentRoot /var/www/html

ServerName www.test.ru

ServerAdmin admin@test.ru

ErrorLog logs/ssl-error_log

TransferLog logs/ssl-access_log

# Следующая директива включает ssl для данного виртуального сервера.

SSLEngine on

# Список доступных алгоритмов шифрования. Формат списка такой же, как и у команды openssl ciphers (MEDIUM, HIGH,

# NULL, элементы разделяются :, исключение элемента осуществляется знаком !).

SSLCipherSuite HIGH:MEDIUM

# Сертификат сервера. Данный сертификат должен быть в формате pem.

SSLCertificateFile /etc/openssl/httpd.crt

# Секретный ключ сервера, которым он будет расшифровывать данные клиента. Если ключ зашифрован, то при запуске Apache

# будет спрашиваться пароль, как определено в опции SSLPassPhraseDialog.

SSLCertificateKeyFile /etc/openssl/httpd.key

# Следующие директивы описывают CA-сертификаты. Если указан параметр SSLCACertificatePath, то CA-сертификаты загружаются

# из указанного каталога (в этом каталоге должны также размещаться символические ссылки с именем hash-value.N, при добавлении

# нового файла сертификата в данный каталог необходимо воспользоваться специальным makefile, идущим вместе с модулем).

# Если указан параметр SSLCACertificateFile, то все СА-сертификаты хранятся в одном pem-файле (сертификаты просто записываются

# один за другим в данный файл без всяких разделитетлей, т.к. любой сертификат имеет маркер начала и конца)

#SSLCACertificatePath @@ServerRoot@@/conf/ssl/ssl.crt

SSLCACertificateFile /etc/openssl/org.crt

# Список сертификатов, которые считаются недействительными (certificate revocation list - CRL) по неким причинам: по происшествии

# срока действия, по потере секретного ключа и т. д. Это понятие требует некоторого объяснения, поэтому после данного примера

# я расскажу (несколько запоздало) о создании такого списка. Синтаксис этих парметров аналогичен предыдущим

#SSLCARevocationPath @@ServerRoot@@/conf/ssl/ssl.crl

SSLCARevocationFile /etc/openssl/ssl.crl

# Аутентификация клиента на основании его сертификата, выданного CA (см. опцию SSLCACertificate). В глобальной конфигурации

# я установил эту опцию в none, но эта опция может быть переопределена в конкретной <Directory> или <Location>, как и сделано

# в данном примере SSLVerifyClient none. Теперь определим некий раздел, доступ в который предоставим только сотрудникам

# определённых отделов. Клиент должен будет послать свой сертификат, который подписан одним из CA-сертификатов.

<Location /secure>

# Требуем от клиента посылки своего сертификата для выполнения аутентификации.

SSLVerifyClient require

# Число шагов от сертификата клиента до CA-сертификата в иерархии сертификатов.

SSLVerifyDepth  5

# Проверка сертификата клиента. Для начала необходимо, чтобы сертификат клиента был подписан одним из CA-сертификатов,

# тогда сервер может быть уверен, что сертификат клиента является действительным, кроме этого, полученный сертификат

# не должен находиться в списке недействительных (crl) сертификатов. Синтаксис данной команды с первого взгляда может показаться

# несколько сложным, но он использует регулярные выражения, подобные перловским, и логические операторы (and, or, !).

# В качестве переменных могут использоваться как стандартные переменные, вроде REMOTE_ADDR, TIME, так и переменные

# ssl. Среди последних наиболее полезны следующие: SSL_CIPHER, SSL_CLIENT_S_DN_(параметры DN клиента, вроде O, OU, С и.т.д.),

# SSL_CLIENT_I_DN_(параметры DN поставщика сертификата).

SSLRequire  %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ and %{SSL_CLIENT_S_DN_O} eq "organization" and %{SSL_CLIENT_S_DN_OU} in {"Sysopka", "CA", "BigBosses"}

</Location>

# Определяем опции ssl (они могут быть переопределены в 

# <Directory>):

#   FakeBasicAuth:

#   Данная опция говорит апачу, что можно использовать аутентификацию на основе сертификата, но настройки

#   фильтрации сертификата лежат в файле .htpasswd, который выглядит примерно следующим образом:

#/C=RU/L=city/O=organization/OU=sysopka

    CN=admin:xxj31ZMTZzkVA

#/C=RU/L=city/O=organization/OU=bosses/

    CN=my_boss:xxj31ZMTZzkVA

#/C=US/L=New York/O=Microsoft/OU=head/

    CN=Billy:xxj31ZMTZzkVA

#   Где символы "xxj31ZMTZzkVA" – это des-вариант слова password (необходимое условие), на некоторых системах

#   нужно здесь поставить md5-хеш этого слова

#$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/.

#   ExportCertData:

#   Данный параметр устанавливает, что CGI-скриптам будут передаваться переменные SSL_SERVER_CERT (всегда),

#   SSL_CLIENT_CERT (если клиент послал свой сертификат), которые содержат сертификаты сервера и клиента

#   соответственно в формате pem.

#   StrictRequire:

#   Эта опция применяется совместно с опцией satisfy и обеспечивает запрет доступа клиента, если его

#   сертификат не соответствует RequireSSL

#   OptRenegotiate:

#   Данная опция применяется только в параметрах <Directory> и заставляет ssl заново инициализировать соединение

#   с клиентом

#SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars

#+StrictRequire

# Переменные, устанавливаемые для некоторых браузеров. Вообще-то все браузеры должны получить перед завершением

# ssl-сеанса сообщение от сервера, что соответствует стандарту, но некоторые (особенно здесь красуется ослик) очень некорректно

# (мягко говоря) завершают работу с ssl, поэтому приходится устанавливать переменную ssl-unclean-shutdown, которая говорит о том,

# что при завершении соединения сервер не должен ни посылать сообщение, ни принимать подтверждение от браузера (что тоже может

# делаться некоторыми браузерами). Кроме этого, ослик ещё в случае ssl-соединения плохо работает с keepalive-сообщениями (вызывая разрыв

# ssl-соединения), поэтому приходится устанавливать ещё переменную nokeepalive. У осла также есть ещё пара недостатков: он не работает

# с адресом вроде https://192.168.1.1 и некоторые его версии не поддерживают работу с sslv3. А вообще при выборе алгоритмов шифрования –

# SSLCipherSuite – просмотрите список алгоритмов, поддерживаемых клиентским браузером и, исходя из этого, выбирайте нужное (+)

# и отсекайте ненужное (-).

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

# Устанавливаем специальный лог, включаем определение протокола и алгоритма шифрования.

CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

# Перезапускаем апач, если ssl оказался невключенным.

RewriteEngine on

RewriteCond %{HTTPS} !=on

RewriteOptions inherit

</VirtualHost>

</IfModule>

Для проверки работы сервера ssl обычно применяется утилита openssl s_client, которая эмулирует поведение ssl-клиента (фактически, ssl telnet):

openssl s_client -connect ww.test.ru:443 [-cert file] [-debug] [-ciphers list]

Клиент может передать серверу сертификат (аутнентификация по сертификату), указав опцию -cert, опция -debug включает в вывод дополнительную отладочную информацию, включая hex-дампы каждого пакета. Для проверки Apache можно также применить свой любимый браузер (мой любимый – lynx):

lynx https://www.test.ru

При этом в лог записывается примерно следующее (если сервер настроен правильно):

[10/Nov/2002 17:41:34 04803] [info]  Connection to child 0 established (server localhost.localdomain:443, client 127.0.0.1) [10/Nov/2002 17:41:34 04803] [info]  Seeding PRNG with 23177 bytes of entropy [10/Nov/2002 17:41:35 04803] [info]  Connection: Client IP: 127.0.0.1, Protocol: TLSv1, Cipher: EDH-RSA-DES-CBC3-SHA (168/168 bits) [10/Nov/2002 17:41:35 04803] [info]  Initial (No.1) HTTPS request received for child 0 (server localhost.localdomain:443) [10/Nov/2002 17:41:35 04803] [info]  Connection to child 0 closed with standard shutdown (server localhost.localdomain:443, client 127.0.0.1)

Итак, могу привести парочку примеров применения ssl-соединений:

• это любые процедуры конфиденциальной регистрации;
• возможность организации защищённого веб-интерфейса для почты;
• работа с клиентами данной фирмы;
• для защиты некоторых мест от посторонних взглядов (это несоизмеримо безопаснее, чем парольная аутентификация!) и подмены IP-адреса;
• для организации собственного CA.

Вообще агентства по выдаче персональных сертификатов работают по следующей схеме: пользователь заходит на сайт и просит сертификат, после чего устанавливается безопасное соединение, и клиент заполняет форму регистрации (включая пароль секретного ключа), после этого создаётся запрос на сертификацию (на сервере), и на основе сертификата организации создаётся сертификат клиента. После этого обычно сертификат клиента перегоняется в pkcs#12 формат и записывается на диск. Пользователю же по мылу отправляется ссылка на полученный сертификат. Этот несчастный клиент проходит по ссылке, вводит своё имя и пароль (в безопасном режиме – https) и перенаправляется к своему сертификату. Браузер, получив сертификат, проверяет его подпись и после запроса помещает в хранилище личных сертификатов. Я здесь не буду приводить готового решения, т.к. это дело очень творческое и создать вышеописанное не представляет труда, только надо немного поработать (написать скриптик, оформить всё это безобразие, организовать мыльную связь и т. д.).

А теперь расскажу об одном непременном атрибуте каждого СА: создания списка недействительных сертификатов (чтобы не переполнять текст, буду далее применять обозначение CRL). По истечении определённого срока сертификат становится недействительным. Если это сертфикат сотрудника, то после его увольнения сертификат также необходимо считать недействительным (а если уволили вас?). Если секретный ключ сертификата стал достоянием общественности, то и его вносят в CRL. Для управления CRL можно использовать утилиту openssl ca. Для начала создаём crl:

openssl ca -gencrl -out crl.pem

Затем просто отменяем нужные ( точнее говоря, ненужные) сертификаты командой:

openssl ca -revoke bad_cert.pem

После каждого применения revoke необходимо обновлять CRL командой openssl -gencrl. Для применения внутри СА необходимо дать клиентам возможность отменять их сертификаты, для этого необходимо предоставить им доступ к CRL. Если же вы используете аутентификацию через сертификаты, то пользователям необходимо понять, как опасно потерять секретный ключ.

Ещё способ давать пароль для секретного ключа с помощью /dev/random, закодированного base64, и сообщать пароль клиенту только лично (можно также поиграться со временем действия сертификата клиента, но зачастую это может сильно увеличить сложность работы, если вам необходимо раздавать сертификаты лично).

Теперь настало время обратиться к защите почтовых серверов. Одним из наиболее удобных вариантов является использование courier в качестве pop3- и imap-серверов, а в качестве MTA использовать postfix. Итак, начнём с курьера.

Курьер поставляется с грамотным конфигом, поэтому у меня всё заработало сразу же безо всяких проблем с настройкой. Единственное, что необходимо учесть, так это то, что сертфикат почтового сервера должен быть подписан CA-сертификатом (по умолчанию при сборке курьера генерится self-signed сертификат, но я бы рекомендовал создать сертификат, как это было сделано в Apache или воспользовавшись моим скриптиком CA, только необходимо изменить настройки extensions). Кроме этого, сертификат организации, которым был подписан ключ сервера, должен находиться среди доверенных сертификатов почтового клиента. Я всё же расскажу о некоторых полезных опциях конфигурации couriera (imapd и pop3d):

imapd-ssl

# Запускаем работу механизма ssl для imap-сервера. В файлах esmtpd-ssl, pop3d-ssl можно также устанавливать эту опцию

# для конкретного сервера (например, ESMTPDSSLSTART...).

IMAPDSSLSTART=YES

# Порт для безопасного соединения (по умолчанию порт не определён, но обычно используются следующие значения:

# IMAPS - 993, POPS - 995 и SMTPS - 465). Адрес задается как IP-адрес.

SSLPORT=993

SSLADDRESS=0

# PID-файл для ssl сервера.

SSLPIDFILE=/var/run/courier/imapd[pop3d, esmtpd]-ssl.pid

# Использование улучшенного протокола tls, по умолчанию выключено, но у меня всё работало нормально с включением

# расширений tls. TLS используется, если необходимо использовать особый ssl порт, т.е. позволяет использовать

# особый порт для работы ssl.

IMAPDSTARTTLS=YES

# Заставляет работать механизм tls в любых случаях (по умолчанию).

IMAP_TLS_REQUIRED=0

Далее идут дополнительные настройки работы ssl. Обычно они используются при включенной опции STARTTLS.

# Вспомогательная программа, использующаяся при работе с ssl. На этапе компиляции она создаёт простой сертификат

# (который, впрочем, у меня не работал, поэтому я сразу же создал нужный мне правильный сертификат), а затем,

# по идее, должна использоваться для аутентификации клиентов, но, как я понял, работать подобным образом это ещё

# не  работает (не забывайте, что курьер - это довольно молодой продукт), но всё же укажем эту опцию на всякий случай...

COURIERTLS=/usr/bin/couriertls

# Определение версии используемого протокола ssl:

# SSL2 - SSLv2

# SSL3 - SSLv3

# TLS1 - TLS1

TLS_PROTOCOL=SSL3

# Данная опция рассматривается как механизм работы ssl, если определён параметр STARTTLS=YES.

TLS_STARTTLS_PROTOCOL=TLS1

# Список алгоритмов шифрации. Можно не трогать данный параметр и оставить его по умолчанию – и так сработает

# TLS_CIPHER_LIST="ALL:!ADH:RC4+RSA:+SSLv2:@STRENGTH"

# Сертификат сервера (pem-формат). Внутри данного файла должны содержаться сертификат и незашифрованный секретный

# ключ, поэтому доступ к данному файлу на чтение должен быть предоставлен только пользователю courier.

TLS_CERTFILE=/etc/openssl/imapd.pem

# Следующий параметр определяет путь к каталогу (или файлу), содержащему "доверенные" сертификаты (если я правильно

# понял, то это СА-сетрификаты, но здесь я могу ошибаться). Сервер использует данные сертификаты, если опция  TLS_VERIFYPEER

# установлена в PEER или REQUIREPEER. Честно говоря, с этим я разобрался не до конца, да и сами разработчики курьера не очень-то

# советуют использовать данную опцию по причине TLS_TRUSTCERTS=/etc/openssl/ca.pem.

# А вот это та самая опция аутентификации через сертификаты, она может принимать следующие значения:

# NONE - не проверяем сертификат клиента вовсе.

# PEER - проверяем сертификат клиента, если последний передал его серверу.

# REQUIREPEER - проверяем сертификат клиента и запрещаем вход, если клиент не предоставил сертификата

# (или сертификат неверный).

TLS_VERIFYPEER=NONE

Думаю, что дальнейшая настройка курьера не должна вызвать проблем (courier – один из самых простых в настройке почтовых служб, т.к. все переменные внутри его конфигов фактически имеют тот же синтаксис, что и переменные в shell).

Другой популярный мыльный сервер – postfix – также легко поддаётся бронированию с помощью ssl. Сразу же приведу пример настройки smtpd postfixa, который использует при передаче почты механизм ssl:

main.cf:

# Создаём стандартный серверный сертификат (как было уже несколько раз описано) и незашифрованный секретный ключ.

# Указываем далее к ним путь.

smtpd_tls_cert_file = /etc/openssl/smtpd.pem

smtpd_tls_key_file = /etc/openssl/smtpd.key

# Указываем также путь к trusted root CA файлу (pem-формат). Можно также указать путь к каталогу с CA-сертификатами,

# но тут возникают проблемы с хеш-файлами (я их уже описывал при разговоре об Apache).

smtpd_tls_CAfile = /etc/openssl/ca.pem

# Уровень записи в лог. Меняется от 0 до 4:

# 0 – забиваем на логи;

# 1 – выводим информацию о сертификатах при установке соединения;

# 2,3,4 – различная дополнительная инфа (вроде hex-дампов пакетов и.т.д.).

# Рекомендуется использовать значение 1 или 2.

smtpd_tls_loglevel = 1

# По умолчанию механизм ssl не включён – включаем его.

smtpd_use_tls = yes

# Установкой следующей опции в yes (по умолчанию - no) можно добиться того, что все команды smtp-сервера будут

# выполняться в ssl-режиме (это не подходит для серверов, которые предоставляют обе услуги: защищённое мыло

# и стандартное).

# smtpd_enforce_tls = no

# Запрос на сертификат клиента. Я здесь не буду останавливаться, т.к. вряд ли кто будет применять этот  ужас (тем более,

# я не видел ни одного клиента, способного  выполнить аутентификацию по сертификату). Поэтому лучше оставить эту опцию

# по умолчанию в no (это также касается и опции smtpd_tls_req_ccert).

# smtpd_tls_ask_ccert = no

# Для совместимости со старыми версиями postfix принимается команда AUTH без шифрования, что создаёт угрозу

# безопасности, установка следующей опции в yes говорит, что шифрование будет производиться только для команды

# AUTH. Для полного шифрования всего трафика используйте опцию smtpd_enforce_tls.

# smtpd_tls_auth_only = no

# Файл кеша ssl для сервера. Поддерживается только формат sdbm, т.к. необходима поддержка одновременной записи

# нескольких процессов в данный файл.

smtpd_tls_session_cache_database = sdbm:/etc/postfix/smtpd_scache

# Тайм-аут для кеша.

smtpd_tls_session_cache_timeout = 3600s

# Традиционный список используемых алгоритмов.

# smtpd_tls_cipherlist = DEFAULT

# Тайм-аут длительности соединения ss.

smtpd_starttls_timeout = 270s

# Установки генератора случайных чисел. Используются стандартные устройства рандомизации или egd-генератор.

# Устанавливаться может также число считываемых байт и время обновления установки генератора случайных чисел.

tls_random_source = dev:/dev/urandom

Также необходимо создать запись в master.cf, чтобы указать postfix слушать smtps-порт (кроме этого, заставляем на порту smtps использовать полную шифрацию передаваемого трафика):

# tls_random_source = egd:/var/run/egd-pool

# tls_random_bytes = 32

# tls_random_reseed_period = 3600s

# ==========================================================================

# service type  private unpriv  chroot  wakeup  maxproc command + args

#               (yes)   (yes)   (yes)   (never) (50)

# ==========================================================================

smtps     inet  n       -       y       -       -       smtpd -o smtpd_enforce_tls=yes

Вместо имени сервиса можно указать номер порта (обычно 465).

Sendmail также обладает возможностью использования ssl, но я не являюсь специалистом по sendmail (наверное, виной тому паталогическая лень и наличие более простых в освоении инструментов).

SSL, похоже, будет всё больше и больше использоваться в сети, защищая стандартные протоколы. Поэтому каждый администратор должен знать принципы работы с ssl. И если я помог кому-то в освоении данной темы, то могу считать свою задачу выполненной!

Приведу некоторые ссылки:

1. http://www.openssl.org – основной сайт с документацией и исходниками openssl;
2. http://www.apache-ssl.org – домашняя страница mod_ssl Apache;
3. http://www.postfix.org – страница производителей postfix;
4. http://www.lothar.com/tech/crypto – страница генератора случайностей EGD;
5. http://www.thawte.com – одна из коммерческих фирм, торгующих сертификатами, предоставляет бесплатные сертификаты для мыла и платные для всего остального.

И ещё информация для тех, кто решил работать с ssl: не так давно в механизме openssl были обнаружены уязвимости, поэтому не поленитесь сходить на www.openssl.org за последними патчами.