Apache настройка (Apache 2) с SSL/TLS.

Hастройка Apache. (apache 2) с SSL/TLS

Более десяти лет SSL протокол используется для шифрования соединений в Интернет. Можно только догадываться, сколько миллиардов долларов переводится каждый день в транзакциях с использованием SSL. К сожалению, сам факт использования SSL не говорит о том, что передаваемая через этот протокол информация действительно безопасна. Использование слабого алгоритма шифрования, невозможность удостоверения сертификатов серверов, бреши в безопасности веб-серверов или библиотек SSL, также как и другие атаки, позволяют злоумышленнику получить доступ к чувствительной информации.

Это первая статья в цикле статей, посвященных настройке Apache 2.0 с поддержкой SSL/TLS в целях достижения максимальной безопасности и оптимальной производительности SSL-соединений. В первой части этой статьи будут описаны ключевые аспекты SSL/TLS, а затем показано - как настроить Apache 2.0 с поддержкой этих протоколов. Во второй части будет описан процесс настройки mod_ssl, далее – вопросы адресов с аутентификацией веб-сервера. Кроме того, во второй части мы разберемся, как создать SSL-сертификат веб-сервера. Третья и последняя часть этой серии расскажет об аутентификации клиента, а также о некоторых типичных ошибках настройки, которые допускают системные администраторы, что резко снижает уровень безопасности любого SSL-соединения.

Введение в SSL

Secure Sockets Layer (SSL-протокол защищенных сокетов - прим. пер.) самое известное и достаточно надежное средство соединения по модели клиент-сервер с использованием Интернет. SSL сам по себе довольно простой в плане понимания: он устанавливает алгоритмы шифрования и ключи на обоих сторонах и прокидывает шифрованный туннель, по которому могут передаваться другие протоколы (например HTTP). Опционально в SSL имеется возможность аутентификации обоих сторон через использование сертификатов.

SSL - это многоуровневый протокол и состоит из четырех под-протоколов:

• SSL Handshake Protocol
• SSL Change Cipher Spec Protocol
• SSL Alert Protocol
• SSL Record Layer

Места вышеуказанных протоколов, в соответствии с моделью стека протоколов TCP/IP показаны на Рисунке 1.

Figure 1. Подпротоколы SSL в модели TCP/IP

Как видно на диаграмме, SSL находится на уровне приложений модели TCP/IP. Благодаря этому, SSL может быть развернут почти на любой ОС, поддерживающей TCP/IP, без какой либо правки ядра системы или TCP/IP стека. В результате SSL имеет преимущества перед другими протоколами, такими как IPSec (IP Security Protocol), который требует поддержки модифицированного TCP/IP стека ядром системы. Кроме того, SSL легко пропускают брандмауэры, прокси и NAT (Network Address Translation - Преобразование Сетевых Адресов – прим.пер.) без проблем.

Как работает SSL? На блок-схеме на Рисунке 2 показан упрощенный пошаговый процесс установки SSL соединения между клиентом (обычно веб-браузер) и сервером (чаще всего SSL веб-сервер).

Рисунок 2. Установка SSL соединений, шаг за шагом.

Итак, процесс установки соединения каждого нового SSL соединения начинается с обмена параметрами шифрования, а затем (опционально) происходит аутентификация серверов (через SSL Handshake Protocol). Если «рукопожатие» удалось, и обе стороны согласились на один и тот же алгоритм шифрования и ключи шифрования, данные приложения (обычно HTTP, но может быть и другой) могут быть переданы по зашифрованному каналу (используется SSL Record Layer).

Если рассматривать реальную ситуацию, то процесс, описанный выше, выглядит намного сложнее. Чтобы избежать ненужных «рукопожатий» некоторые параметры шифрования кэшируются. При этом могут быть посланы предупреждающие сообщения. Также могут быть изменены блоки шифра. Как бы то ни было, не зависимо от тонкостей спецификации SSL, в общем виде этот процесс работает примерно так, как показано на Рисунке 2.

SSL, PCT, TLS и WTLS (но не SSH)

Хотя SSL - самый известный и популярный, но не единственный протокол, используемый для защиты веб транзакций. Важно знать, что со времени изобретения SSL v1.0 (релиза которого, кстати говоря, не было) появилось, как минимум, пять протоколов, сыгравших более-менее важную роль в защите доступа к World Wide Web:

SSL v2.0

Релиз выпущен фирмой Netscape Communications в 1994. Основной целью этого протокола было повысить безопасность транзакций через World Wide Web. К несчастью, очень быстро нашлось несколько критических брешей в безопасности этой версии, что сделало его ненадежным для коммерческого использования:

• Слабая конструкция MAC
• Возможность принудительных партий для использования слабого алгоритма шифрования
• Отсутствие защиты «рукопожатий»
• Возможность злоумышленника осуществить атаки принудительного завершения

PCT v1.0

Разработан в 1995 году корпорацией Microsoft. В Privacy Communication Technology (PCT - Технология Конфиденциальной Связи – прим.пер.) v1.0 были усилены некоторые слабые места SSL v2.0, корпорация планировала заменить тем самым SSL. Однако, этот протокол так никогда и не получил популярности из-за появления SSL v3.0.

SSL v3.0

Релиз выпущен в 1996 году компанией Netscape Communications. В SSL v3.0 были решены большинство проблем SSL v2.0 и заимствовано множество возможностей нового для того времени протокола PCT, вследствие чего он быстро стал самым популярным протоколом для защиты соединений через WWW.

TLS v1.0 (также известный как SSL v3.1)

Опубликован IETF (Internet Engineering Task Force - Проблемная Группа Проектирования Интернет – прим.пер.) в 1999 году. Протокол базируется на SSL v3.0 и PCT и согласован как с методами Netscape, так и с корпорацией Microsoft. Стоит заметить, что если TLS базируется на SSL, он не 100% совместим со своим предшественником. IETF сделала некоторые поправки в безопасности, например использование HMAC вместо MAC, использование другого пересчета основного шифра и ключевого материала, добавлены коды предупреждения, отсутствует поддержка алгоритмов шифрования Fortezza и т.д. В конце концов множество противоречивых изменений привели к тому, что эти протоколы толком не могли взаимодействовать. К счастью, появился мод TLS с откатом до SSL v3.0.

WTLS

«Мобильная и беспроводная» версия протокола TLS, которая использует в качестве носителя UDP протокол. Он разработан и оптимизирован под нижнюю полосу частот и меньшую пропускную способность мобильных устройств с поддержкой WAP (Wireless Application Protocol – Протокол Беспроводных Приложений – прим.пер.). WTLS был представлен с протоколом WAP 1.1 и был опубликован на форуме WAР. Однако, после релиза WAP 2.0, WTLS заменили профилированной версией TLS, которая оказалась намного безопаснее – в основном из-за того, что в этой версии нет необходимости расшифровки и перешифровки трафика на WAP шлюзе.

Почему протокол SSH (Secure Shell) не используется для обеспечения безопасного доступа к World Wide Web? Вот несколько причин: во-первых, с самого начала TLS и SSL были разработаны для защиты веб (HTTP) сессий, тогда как SSH задумывался как альтернатива Telnet и FTP. SSL не выполняет ничего, кроме «рукопожатия» и установки зашифрованного туннеля, а в SSH имеется возможность консольной авторизации, защищенной передачи файлов и поддержка сложной схемы аутентификации (включая пароли, публичные ключи, Kerberos и др.). С другой стороны, SSL/TLS базирован на сертификатах X.509v3 и PKI, что делает распространение и управление аутентификационными мандатами намного проще. Следовательно, эти и другие причины делают SSL/TLS более удобным для защиты WWW доступа и подобных форм соединений, включая SMTP, LDAP и другие – тогда как SSH больше удобен для удаленного управления системой.

В итоге, несмотря на существование нескольких «безопасных» протоколов, только два следует использовать для защиты веб-транзакций (по крайней мере сейчас): TLS v1.0 и SSL v3.0. Оба протокола будут дальше рассмотрены в этих статьях как SSL/TLS. Из-за известных слабостей SSL v2.0, и знаменитой «WAP дыры» в случае с WTLS, использования таких протоколов следует избегать или максимально уменьшать.

Установка Apache с поддержкой SSL/TLS

Первым шагом в установке Apache с поддержкой SSL/TLS будет настройка и установка Apache 2 веб-сервера и создание пользователя и группы с именем "apache". Безопасный способ установки Apache 2.0 уже был рассмотрен на Securing Apache 2.0: Step-by-Step. Единственное отличие в том, что нужно включить mod_ssl и mod_setenvif, которые требуются для совместимости с некоторыми версиями MS Internet Explorer, как описано ниже (изменения выделены жирным):

./configure \ --prefix=/usr/local/apache2 \ --with-mpm=prefork \ --enable-ssl \ --disable-charset-lite \ --disable-include \ --disable-env \ --enable-setenvif \ --disable-status \ --disable-autoindex \ --disable-asis \ --disable-cgi \ --disable-negotiation \ --disable-imap \ --disable-actions \ --disable-userdir \ --disable-alias \ --disable-so

После настройки мы можем установить Apache в конечную директорию:

make su umask 022 make install chown -R root:sys /usr/local/apache2

Настройка SSL/TLS

Перед запуском Apache в первый раз, нам нужно подготовить некоторую начальную конфигурацию и образец веб-контента. Как минимум, мы должны сделать следующее (под root):

1. Создание некоторого веб-контента, который будет обслуживаться через TLS/SSL:

umask 022 mkdir /www echo "<html><head><title>Test</title></head><body> \ Test works.</body></html>" > /www/index.html chown -R root:sys /www

1. Удаление конфигурационного файла Apache, созданного по умолчанию (обычно находится в /usr/local/apache2/conf/httpd.conf) и замена его новым, с использованием следующего контента (оптимизировано для обеспечения безопасности и производительности).

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

# Basic settings

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

User apache

Group apache

ServerAdmin webmaster@www.seccure.lab

ServerName www.seccure.lab

UseCanonicalName Off

ServerSignature Off

HostnameLookups Off

ServerTokens Prod

ServerRoot "/usr/local/apache2"

DocumentRoot "/www"

PidFile /usr/local/apache2/logs/httpd.pid

ScoreBoardFile /usr/local/apache2/logs/httpd.scoreboard

<IfModule mod_dir.c>

DirectoryIndex index.html

</IfModule>

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

# HTTP and performance settings

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

Timeout 300

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 30

<IfModule prefork.c>

MinSpareServers 5

MaxSpareServers 10

StartServers 5

MaxClients 150

MaxRequestsPerChild 0

</IfModule>

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

# Access control

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

<Directory />

Options None

AllowOverride None

Order deny,allow

Deny from all

</Directory>

<Directory "/www">

Order allow,deny

Allow from all

</Directory>

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

# MIME encoding

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

<IfModule mod_mime.c>

TypesConfig /usr/local/apache2/conf/mime.types

</IfModule>

DefaultType text/plain

<IfModule mod_mime.c>

AddEncoding x-compress .Z

AddEncoding x-gzip .gz .tgz

AddType application/x-compress .Z

AddType application/x-gzip .gz .tgz

AddType application/x-tar .tgz

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

AddType application/x-pkcs7-crl .crl

</IfModule>

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

# Logs

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

LogLevel warn

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

LogFormat "%h %l %u %t \"%r\" %>s %b" common

LogFormat "%{Referer}i -> %U" referer

LogFormat "%{User-agent}i" agent

ErrorLog /usr/local/apache2/logs/error_log

CustomLog /usr/local/apache2/logs/access_log combined

CustomLog logs/ssl_request_log \

"%t %h %{HTTPS}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x \

%{SSL_CIPHER_USEKEYSIZE}x %{SSL_CLIENT_VERIFY}x \"%r\" %b"

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

# SSL/TLS settings

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

Listen 0.0.0.0:443

SSLEngine on

SSLOptions +StrictRequire

<Directory />

SSLRequireSSL

</Directory>

SSLProtocol -all +TLSv1 +SSLv3

SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

SSLMutex file:/usr/local/apache2/logs/ssl_mutex

SSLRandomSeed startup file:/dev/urandom 1024

SSLRandomSeed connect file:/dev/urandom 1024

SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm

SSLSessionCacheTimeout 600

SSLPassPhraseDialog builtin

SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt

SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key

SSLVerifyClient none

SSLProxyEngine off

<IfModule mime.c>

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

AddType application/x-pkcs7-crl .crl

</IfModule>

SetEnvIf User-Agent ".*MSIE.*" \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

Заметьте: читатели должны изменить некоторые значения этого конфигурационного файла, таких как имя веб-сервера, e-mail администратора и т.д.

1. Подготовим структуры директории для приватных ключей веб-сервера, сертификатов и списков аннулированных сертификаций (CRLs - certification revocation lists)

umask 022 mkdir /usr/local/apache2/conf/ssl.key mkdir /usr/local/apache2/conf/ssl.crt mkdir /usr/local/apache2/conf/ssl.crl

1. Создаем самоподписанный серверный сертификат (следует использовать только для тестов – ваш настоящий сертификат должен быть от достоверного СА – такого как Verisign):

openssl req \ -new \ -x509 \ -days 30 \ -keyout /usr/local/apache2/conf/ssl.key/server.key \ -out /usr/local/apache2/conf/ssl.crt/server.crt \ -subj '/CN=Test-Only Certificate'

Проверяем установку

Теперь можно запустить Apache с поддержкой SSL/TLS:

/usr/local/apache2/bin/apachectl startssl Apache/2.0.52 mod_ssl/2.0.52 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order to read them you have to provide us with the pass phrases. Server 127.0.0.1:443 (RSA) Enter pass phrase:************* Ok: Pass Phrase Dialog successful.

После запуска сервера мы можем попробовать соединиться к нему, направив веб-браузер на URL: https://имя сервера (в нашем случае, https://www.seccure.lab)

Через некоторое время мы должны увидеть предупреждающее сообщение о том, что в ходе проверки аутентифифкации веб-сервера возникла проблема. На Рисунке 3 показан пример такого сообщения в MS Internet Explorer 6.0.

Рисунок 3. Примерное сообщение о сертификате в IE 6.

Все работает правильно. Следует принять это сообщение из-за двух причин:

• Веб-браузер не знает Certificate Authority, использовавшийся при создании данного сертификата (и не может знать, ведь мы используем самоподписанный сертификат)
• Атрибут CN (Common Name – Общее Имя) сертификата не совпадает с именем веб-сайта – на данный момент «Test-Only Certificate» (Только для Тестирования), а должен быть полностью определенное доменное имя веб сервера (например www.seccure.lab)

После нажатия кнопки «Yes», мы увидим следующее веб содержимое:

Рисунок 4. Пример работы SSL веб страницы.

Внизу окна браузера появился желтый замок, означающий что SSL соединение было успешно установлено. Значение "128-bit" говорит о том, что симметричный ключ, используемый для шифрования равен 128 бит, что довольно таки неплохо (по крайней мере сейчас) для защиты трафика от неавторизованного доступа.

Выполнив двойной щелчок по значку замка, мы увидим свойства сертификата:

Рисунок 5. Подробнее о нашем самоподписанном сертификате.

Диагностика неисправностей

Если по каким-то причинам мы не можем получить доступ к веб-сайту, можно воспользоваться очень полезной утилитой "s_client" от библиотеки OpenSSL. Пример использования этой утилиты:

/usr/bin/openssl s_client -connect localhost:443
CONNECTED(00000003)
depth=0 /CN=Test-Only Certificate
verify error:num=18:self signed certificate
verify return:1
depth=0 /CN=Test-Only Certificate
verify return:1
---
Certificate chain
0 s:/CN=Test-Only Certificate
i:/CN=Test-Only Certificate
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICLzCCAZigAwIBAgIBADANBgkqhkiG9w0BAQQFADAgMR4wHAYDVQQDExVUZXN0
LU9ubHkgQ2VydGlmaWNhdGUwHhcNMDQxMTIyMTg0ODUxWhcNMDQxMjIyMTg0ODUx
WjAgMR4wHAYDVQQDExVUZXN0LU9ubHkgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAMEttnihJ7JpksdToPi5ZVGcssUbHn/G+4G43OiLhP0i
KvYuqNxBkSqqM1AanR0BFVEtVCSuq8KS9LLRdQLJ/B1UTMOGz1Pb14WGsVJS+38D
LdLEFaCyfkjNKnUgeKMyzsdhZ52pF9febB+d8cLmvXFve28sTIxLCUK7l4rjT3Xl
AgMBAAGjeTB3MB0GA1UdDgQWBBQ50isUEV6uFPZ0L4RbRm41+i1CpTBIBgNVHSME
QTA/gBQ50isUEV6uFPZ0L4RbRm41+i1CpaEkpCIwIDEeMBwGA1UEAxMVVGVzdC1P
bmx5IENlcnRpZmljYXRlggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQAD
gYEAThyofbK3hg8AJXbAUD6w6+mz6dwsBmcTWLvYtLQUh86B0zWnVxzSLDmwgdUB
NxfJ7yfo0PkqNnjHfvnb5W07GcfGgLx5/U3iUROObYlwKlr6tQzMoysNQ/YtN3pp
52sGsqaOOWpYlAGOaM8j57Nv/eXogQnDRT0txXqoVEbunmM=
-----END CERTIFICATE-----
subject=/CN=Test-Only Certificate
issuer=/CN=Test-Only Certificate
---
No client certificate CA names sent
---
SSL handshake has read 1143 bytes and written 362 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : SSLv3
Cipher : DHE-RSA-AES256-SHA
Session-ID: 56EA68A5750511917CC42A1B134A8F218C27C9C0241C35C53977A2A8BBB9986A
Session-ID-ctx:
Master-Key: 303B60D625B020280F5F346AB00F8A61A7C4BEA707DFA0ED8D2F52371F8C4F087FB6EFFC02CE3B48F912D2C8929DB5BE
Key-Arg : None
Start Time: 1101164382
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 22 Nov 2004 22:59:56 GMT
Server: Apache
Last-Modified: Mon, 22 Nov 2004 17:24:56 GMT
ETag: "5c911-46-229c0a00"
Accept-Ranges: bytes
Content-Length: 70
Connection: close
Content-Type: text/html
<html><head><title>Test</title></head><body>Test works.</body></html>
closed

Утилита s_client имеет много полезных опций, например включение/выключение отдельного протокола (-ssl2, -ssl3, -tls1), выбор отдельного алгоритма шифрования (-cipher), запуск режима отладки (-debug), просмотр статистик и сообщений SSL/TLS (-state, -msg), и некоторые другие, которые смогут помочь найти причину неполадки.

Если s_client ничем не помог, следует сменить значение LogLevel (в httpd.conf) на "debug" и перезапустить Apache и проверить его логи (/usr/local/apache2/logs/) для дополнительной информации.

Еще можно попробовать Ethereal или ssldump. Благодаря этим утилитам, мы можем пассивно наблюдать SSL сообщения «рукопожатий» и пытаться найти причину неисправности. Вот скриншот использования Ethereal:

Figure 6. Просмотр SSL «рукопожатия» в Ethereal.

Заключение к первой части

Итак, мы имеем безопасный Apache 2 сервер в состоянии онлайн и пример SSL-сертификата, на чем и заканчивается первая часть. В следующей части вы познакомитесь с рекомендуемыми настройками безопасности и функций для mod_ssl и процессом создания нормального сертификата.

Автор Artur Maj

В первой статье этого цикла мы рассказали как правильно устанавливать настраивать и устранять неисправности Apache 2.0 с поддержкой SSL/TLS. Во второй части мы обсудим рекомендуемые настройки mod_ssl, нацеленные на получение максимальной безопасности и оптимальной производительности. Кроме того, читатель узнает, как создать локальный Certification Authority и SSL-сертификат, используя OpenSSL библиотеку с открытым кодом.

Рекомендуемые настройки mod_ssl

В Apache 2.0.52 существует более 30 директив, используемых для настройки mod_ssl. Подробное описание их всех можно найти в Apache's mod_ssl documentation. В этом разделе рассмотрим только рекомендуемые настройки, которые влияют на безопасность или производительность SSL/TLS соединений.

Листинг этих настроек показан в Таблице 1.

Table 1. Рекомендуемые настройки mod_ssl.

Вот наш пример настоек в httpd.conf, следую рекомендациям выше:

SSLEngine on

SSLOptions +StrictRequire

<Directory />

SSLRequireSSL

</Directory>

SSLProtocol -all +TLSv1 +SSLv3

# Support only for strong cryptography

SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

# Support for strong and export cryptography

# SSLCipherSuite HIGH:MEDIUM:EXP:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM:+EXP

SSLRandomSeed startup file:/dev/urandom 1024

SSLRandomSeed connect file:/dev/urandom 1024

SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm

SSLSessionCacheTimeout 600

SSLVerify none

SSLProxyEngine off

Как дополнение к вышеупомянутым директивам mod_ssl, существуют еще две очень важные директивы от других модулей Apache (mod_log_config и mod_set_envif), которые нужно настроить, как показано в Таблице 2.

Table 2. Рекомендуемы настройки mod_log и mod_set_envif.

Пример конфигурационного файла (httpd.conf), представленного в предыдущей статье уже включает настройки, приведенные выше.

Аутентификация веб сервера

Итак, нам удалось настроить и протестировать SSL/TLS, но веб-браузер не смог проверить подлинность веб-сервера. В первой статье мы использовали сертификат веб-сервера, созданного только в целях тестирования и не содержащего информацию, требуемую для настоящей аутентификации и коммерческих транзакций.

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

• Открытый ключ веб-сервера
• Даты подлинности (начала и истечения)
• Поддерживаемые алгоритмы шифрования
• Отличительное имя (the distinguish name DN), которое должно содержать полностью определенное доменное имя веб-сервера, называемое общим именем (Common Name CN). Опционально DN может содержать и некоторые другие атрибуты, например, страну (Country C), штат (State S), Расположение (Location L), название организации (the Organization's name O), название службы организации (the Organization Unit's name OU), и др.
• Серийный номер сертификата
• Атрибуты X.509v3, которые будут сообщать веб-браузерам о типе и применении
• URI CRL (если есть)
• URI политики сертификата X.509v3 (если есть)
• Имя и подпись доверенного источника сертификатов (Certification Authority CA)

Стоит отметить, что атрибут общее имя (Common Name CN) должен иметь значение, равное доменному имени сервера (Fully Qualified Domain Name FQDN). Иначе браузерам не удастся определить принадлежность сертификата веб-серверу, на котором присутствует наш сертификат.

Пример сертификата веб-сервера (текстовая репродукция):

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 1 (0x1)

Signature Algorithm: sha1WithRSAEncryption

Issuer: O=Seccure, OU=Seccure Root CA

Validity

Not Before: Nov 28 01:00:20 2004 GMT

Not After : Nov 28 01:00:20 2005 GMT

Subject: O=Seccure, OU=Seccure Labs, CN=www.seccure.lab

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (1024 bit)

Modulus (1024 bit):

00:c1:19:c7:38:f4:89:91:27:a2:1b:1d:b6:8d:91:

48:63:0e:3d:0d:2e:f8:65:45:56:db:98:4d:11:21:

01:ac:81:8e:3f:64:4a:8a:3f:21:15:ca:49:6e:64:

5c:5d:a2:ab:5a:48:cb:2a:9f:0c:02:b9:ff:52:f6:

d9:39:6d:a3:4a:94:41:f9:e9:ab:f0:42:fb:68:9a:

4b:53:41:e7:4f:b0:2b:02:d7:92:a2:2b:02:a2:f9:

f1:2d:68:fa:50:01:2f:49:c1:28:2f:a8:c6:6d:6d:

ab:1d:b9:bd:c9:80:63:f1:d6:22:19:de:2d:4a:43:

50:76:79:7e:a5:5a:75:af:19

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

Netscape Cert Type:

SSL Server

X509v3 Key Usage:

Digital Signature, Key Encipherment

X509v3 Extended Key Usage:

TLS Web Server Authentication, Netscape Server Gated Crypto,

Microsoft Server Gated Crypto

Netscape Comment:

OpenSSL Certificate for SSL Web Server

Signature Algorithm: sha1WithRSAEncryption

45:30:9d:04:0e:b7:86:9e:61:a1:b0:68:2b:44:93:1c:57:2a:

99:42:bb:16:b1:ab:f5:c0:d2:33:12:c8:d3:1d:2b:bb:6b:9a:

4c:c7:53:bc:e4:88:ef:1e:c3:37:ed:53:2c:15:cf:b8:90:df:

df:4b:34:b8:db:cc:23:77:46:06:72:9d:43:60:a8:a2:ed:0a:

bb:1a:a4:e8:4e:ba:66:93:63:74:87:fd:43:48:b6:93:a2:e3:

3d:da:1b:64:46:35:88:b4:4b:22:e6:3c:84:70:5d:88:dd:64:

c2:51:c2:d6:59:80:87:bc:bd:7f:e3:c1:45:7e:c0:5f:9c:ca:

e1:a1

Примеры, представленные в последующих разделах статьи основаны на значениях, показанных в Таблице 3. Для создания соответствующих сертификатов читателю потребуется изменить эти значения на название их собственной компании или организации.

Table 3. Примеры значений сертификата.

Парольная фраза dilemma

Перед созданием сертификатов важно понять причастность парольной фразы. Следует ли шифровать закрытый ключ или нет? Существует много мнений, но рекомендуется не защищать закрытый ключ веб-сервера с использованием парольной фразы. Это не только неудобно, но и представляет собой лишь мираж безопасности. Почему? Рассмотрим эти точки зрения:

1. Необходимо будет вводить парольную фразу после каждой перезагрузки сервера, что может раздражать, если систему нужно часто перезагружать (например, при обновлении ядра, перебоях с питанием, смене конфигурации и т.п.)
2. Если злоумышленнику удастся получить закрытый ключ на веб-сервере, это будет означать, что веб-сервер уже компрометирован и взломщик получит привилегии root’a. В этом случае хакер сможет узнать и парольную фразу, установив кей-логгер и перезагрузив систему, тем самым он всё равно заставит системного администратора ввести парольную фразу. Также злоумышленник может просмотреть память Apache и найти закрыйтый ключ веб-сервера, хранимого в дампе в открытом тексте. Хотя осуществить это сложно, но для тех, кто имеет опыт во взломе систем семейства Unix, большой проблемы это не вызовет (самый простой способ - использовать утилиту pcat из The Coroner's Toolkit).

Таким образом, в шифровании закрытого ключа сервера существует только одно преимущество – парольная фраза поможет сохранить закрытый ключ от бездарных скрипт-киддисов, но не от профессионалов, способных получить root доступ к серверу.

Создаем сертификат веб-сервера

Теперь мы можем создать сертификат нашего веб-сервера. Вообще, существует три типа сертификатов, которые мы можем использовать:

1. Самоподписанный сертификат.
2. Сертификат, подписанный доверенным CA (наиболее рекомендуемый).
3. Сертификат, подписанный локальным CA.

Следующие разделы подробно описывают способы создания этих сертификатов. Конечный результат любого способа будет всего в двух файлах:

• server.key – закрытый ключ веб-сервера
• server.crt – зашифрованный PEM сертификат, содержащий открыйтый ключ сервера

Способ 1: Самоподписанный сертификат (только для тестирования)

Этот способ стоит использовать только для продолжения нашего тестирования, или для использования в малых, закрытых условиях (малые корпоративные сети). Чтобы веб-браузеры могли аутентифицировать веб-сервер, самоподписанные сертификаты должны быть инсталлированы в каждый веб-браузер. Это может быть довольно таки неудобно.

Закрытый/открытый ключ и самоподписанный РЕМ-зашифрованный сертификат создаются следующим образом:

openssl req \ -new \ -x509 \ -days 365 \ -sha1 \ -newkey rsa:1024 \ -nodes \ -keyout server.key \ -out server.crt \ -subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab'

При помощи этих команд выполняются следующие действия: создание нового (-new) сертификата (-x509), который будет действителен в течение года (-days 365) и будет подписан с использованием алгоритма SHA1 (-sha1). Закрытый ключ RSA будет иметь длину 1024 бит (-newkey rsa:1024), и не будет защищен парольной фразой (-nodes). Сертификат и закрытый/открытый ключи будут созданы в файлах "server.crt" и "server.key" (-out server.crt -keyout server.key). Параметр "-subj" говорит о том, что название компании "Seccure" (O=Seccure), название службы "Seccure Labs", и полностью определенное доменное имя "www.seccure.lab".

После создания этого сертификата мы должны установить его в каждый веб-браузер, который будет являться потенциальным клиентом нашего сервера. Иначе, веб-браузеры, отправляющие запрос на соединение нашему серверу, не смогут проверить его подлинность. Для Windows среды это будет выглядеть следующим образом:

Рисунок 1. Установка самоподписанного сертификата на машину клиента.

Способ 2: Сертификат, подписанный доверенным CA (рекомендуется)

Создание запроса на сертификат и подписка его доверенным CA (таким как Thawte, RSA и др.) наиболее рекомендуемое дальнейшее действие, если вы хотите открыть публичный доступ к вашему сайту из Интернет. При использовании этого метода отпадает необходимость в установке сертификатов в каждый веб-браузер, ведь большинство из них уже имеют в установке несколько сертификатов от доверенных CA.

Не забывайте, что каждый СА имеет разные ограничение на атрибут DN, поэтому читателю стоит заранее ознакомиться с ними. Рекомендуется также выбирать такие сертификаты, которые установлены в большинстве веб браузеров (Thawte, Verisign и некоторые другие). Иначе, у веб-браузера пользователя возникнут проблемы с аутентификацией веб-сервера.

Процесс получения подписанного сертификата от доверенного СА состоит из следующих шагов:

1. Первым делом, следует создать пару закрытого/открытого ключа (server.key) и запрос сертификата (request.pem), как показано ниже:

openssl req \ -new \ -sha1 \ -newkey rsa:1024 \ -nodes \ -keyout server.key \ -out request.pem \ -subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab'

2.  Теперь мы должны послать запрос на получение сертификата (request.pem) в СА и дождаться, пока он будет подписан и отослан обратно в виде сертификата.

3.  После получения сертификата от доверенного СА мы должны удостовериться в том, что он закодирован в формате PEM, а не TXT или DER. Если же полученный сертификат не соответствует формату РЕМ, то мы должны конвертировать его, в каком бы формате он не пришел.

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

1. • PEM, Base64 кодировка формата X.509 (*.crt, *.pem, *.cer)

-----BEGIN CERTIFICATE----- MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN ... ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9 f+PBRX7AX5zK4aE= -----END CERTIFICATE-----

1. • TXT + PEM format (*.crt, *.cer, *.pem, *.txt)

Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: O=Seccure, OU=Seccure Root CA ... RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c1:19:c7:38:f4:89:91:27:a2:1b:1d:b6:8d:91: ... X509v3 extensions: X509v3 Basic Constraints: CA:FALSE ... -----BEGIN CERTIFICATE----- MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN ... ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9 f+PBRX7AX5zK4aE= -----END CERTIFICATE-----

Команда для конвертирования формата TXT + PEM в РЕМ:

openssl x509 -in signed_cert.pem -out server.crt

1. • DER, двоичная кодировка X.509 (*.der, *.crt, *.cer)

[Нетекстовое, двоичное представление]

Команда для преобразования формата DER в РЕМ:

openssl x509 -in signed_cert.der -inform DER -out server.crt

1. Верификация и тестирование сертификата

Перед установкой сертификата мы должны проверить, действительно ли он законный и может быть использован в целях аутентификации веб-ервера:

openssl verify -CAfile /path/to/trusted_ca.crt -purpose sslserver server.crt

Кроме того, было бы неплохо убедиться в том, что наш сертификат соответствует ранее созданному закрытому ключу (результаты выполнения обеих команд должны быть одинаковыми):

openssl x509 -noout -modulus -in server.crt | openssl sha1 openssl rsa -noout -modulus -in server.key | openssl sha1

Способ 3: Сертификат, подписанный локальным CA

Этот метод может быть использован в интрасетях или в организациях, которые используют или планируют использовать собственный СА. В этом случае местный сертификат СА должен быть установлен на все веб-браузеры, которые будут соединяться с защищенным веб-сервером.

Для использования этого способа нам нужно создать локальный закрытый/открытый ключ СА, также как и сертификат и репозиторий СА для новых ключей.

Примечание: Локальный СА должен быть создан на отдельном сервере, который не имеет соединения с сетью. Операционная система должна давать доступ только авторизованному персоналу, а сама машина должна быть под охраной. Закрытый СА ключ – самый важный элемент всей системы PKI – если он будет компрометирован, то все другие сертификаты, подписанные этим СА также будут компрометированы!

Для установки среды мы будет использовать библиотеку OpenSSL. Понятно, что если у нас уже есть локальный СА, мы можем пропустить этот раздел и продолжить создание запроса на сертификат для веб-сервера.

1. Подготовим структуру каталога для нового СА (среда переменной $SSLDIR должна быть добавлена в соответствующие скрипты автозагрузки, такие как /etc/profile или /etc/rc.local:

export SSLDIR=$HOME/ca mkdir $SSLDIR mkdir $SSLDIR/certs mkdir $SSLDIR/crl mkdir $SSLDIR/newcerts mkdir $SSLDIR/private mkdir $SSLDIR/requests touch $SSLDIR/index.txt echo "01" > $SSLDIR/serial chmod 700 $SSLDIR

1. Создаем основной файл настроек OpenSSL - $SSLDIR/openssl.cnf, со следующим содержанием (оптимизировано для использования с SSL веб-серверами):

# ================================================= # OpenSSL configuration file # ================================================= RANDFILE = $ENV::SSLDIR/.rnd [ ca ] default_ca = CA_default [ CA_default ] dir = $ENV::SSLDIR certs = $dir/certs new_certs_dir = $dir/newcerts crl_dir = $dir/crl database = $dir/index.txt private_key = $dir/private/ca.key certificate = $dir/ca.crt serial = $dir/serial crl = $dir/crl.pem RANDFILE = $dir/private/.rand default_days = 365 default_crl_days = 30 default_md = sha1 preserve = no policy = policy_anything name_opt = ca_default cert_opt = ca_default [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] default_bits = 1024 default_md = sha1 default_keyfile = privkey.pem distinguished_name = req_distinguished_name x509_extensions = v3_ca string_mask = nombstr [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) localityName = Locality Name (eg, city) 0.organizationName = Organization Name (eg, company) organizationalUnitName = Organizational Unit Name (eg, section) commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 [ usr_cert ] basicConstraints = CA:FALSE # nsCaRevocationUrl = https://url-to-exposed-clr-list/crl.pem [ ssl_server ] basicConstraints = CA:FALSE nsCertType = server keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, nsSGC, msSGC nsComment = "OpenSSL Certificate for SSL Web Server" [ ssl_client ] basicConstraints = CA:FALSE nsCertType = client keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth nsComment = "OpenSSL Certificate for SSL Client" [ v3_req ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca ] basicConstraints = critical, CA:true, pathlen:0 nsCertType = sslCA keyUsage = cRLSign, keyCertSign extendedKeyUsage = serverAuth, clientAuth nsComment = "OpenSSL CA Certificate" [ crl_ext ] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment nsComment = "OpenSSL generated CRL"

• Теперь создаем пару СА закрытого/открытого ключа и самоподписанного сертификата СА:

  openssl req \ -config $SSLDIR/openssl.cnf \ -new \ -x509 \ -days 3652 \ -sha1 \ -newkey rsa:1024 \ -keyout $SSLDIR/private/ca.key \ -out $SSLDIR/ca.crt \ -subj '/O=Seccure/OU=Seccure Root CA'

   

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

  Сертификат СА "ca.crt" следует выложить в открытый доступ на веб-страницах интрасети и установить в каждый веб-браузер, которому он может понадобиться. Ниже показан пример установленного в Internet Explorer сертификата.

  

  Рисунок 2. Пример корневого CA сертификата, установленного в Internet Explorer.

  Теперь мы можем использовать наш локальный СА для подписания/аннулирования сертификатов. Для создания сертификата веб-сервера нужно следовать следующим шагам:

  1. Создаем пару закрытый/открытый ключ веб-сервера (server.key), и запрос на сертификат (request.pem). На веб-сервере нужно выполнить следующие команды:

  openssl req \ -new \ -sha1 \ -newkey rsa:1024 \ -nodes \ -keyout server.key \ -out request.pem \ -subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab'

   

  1. Копируем этот запрос (request.pem) в директорию $SSLDIR/requests на хост CA  (с использованием переносимого носителя, например USB драйва).
  2. Подпишем запрос на сертификат (команды выполнять только на хосте СА):

  openssl ca \ -config $SSLDIR/openssl.cnf \ -policy policy_anything \ -extensions ssl_server \ -out $SSLDIR/requests/signed.pem \ -infiles $SSLDIR/requests/request.pem

   

  4.      Результатом этих команд будет подписанный сертификат (signed.pem) , который будет находится в директории $SSLDIR/newcerts, и в файле $SSLDIR/signed.pem. Он состоит сразу из TXT и PEM представлении сертификата. Так как Apache ожидает усеченный вариант в формате PEM , мы конвертируем его:

  openssl x509 \ -in $SSLDIR/requests/signed.pem \ -out $SSLDIR/requests/server.crt

   

  1. Скопируйте подписанный, в формате PEM сертификат (server.crt) обратно на машину, которая является веб-сервером.

  Теперь сертификат готов к использованию.

  Для местных СА в случае компрометации сертификата строго рекомендуется аннулировать сертификат и информировать пользователей о том, что сертификат больше не действителен. Для аннулирования  сертификата мы должны отыскать его серийный номер в файле $SSLDIR/index.txt. Далее выполняем следующие команды:

  openssl ca \ -config $SSLDIR/openssl.cnf \ -revoke $SSLDIR/newcerts/.pem

   

  Для создания CRL (Certificate Revocation List – Список Аннулированных Сертификатов) файла, делаем следующее:

  openssl ca -config $SSLDIR/openssl.cnf -gencrl -crlexts crl_ext -md sha1 -out $SSLDIR/crl.pem

   

  Этот файл должен быть опубликован на сайте СА и/или предоставлен пользователям иным способом. В процессе распространения CRL’ов также рекомендуется использовать Online Certificate Status Protocol (OCSP). Более подробную информацию можно найти в RFC 2560.

  Заметьте, что некоторые браузеры (включая Firefox) принимают CRL’ы только в формате DER, поэтому для установки сертификатов в эти браузеры потребуется конвертировать файл crl.pem:

  openssl crl \ -in $SSLDIR/crl.pem \ -out $SSLDIR/revoke_certs.crl \ -outform DER

   

  Кроме того, чтобы браузер проверял - не аннулирован ли сертификат веб-сервера, нужно установить опцию "Check for server certificate revocation" (Проверять аннулирование сертификатов серверов). Пример для MS Internet Explorer:

  

   

  Рисунок 3. Настройка Internet Explorer на проверку аннулирования сертификатов.

   

  

   

  Рисунок 4. Реакция Internet Explorer на аннулированный сертификат.

   

  Установка сертификата

  Теперь можно продолжить установку закрытого ключа веб-сервера (server.key) и самого сертификата (server.crt) в среду Apache:

  install -m 600 -o root -g sys server.key /usr/local/apache2/conf/ssl.key/ install -m 644 -o root -g sys server.crt /usr/local/apache2/conf/ssl.crt/

   

  Следует проверить, что директивы в конфигурации Apache ссылаются именно на файлы, указанные выше (в httpd.conf):

  SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key

   

  Наконец, перезапускаем Apache и изменения вступают в силу:

   

  SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key

   

  Проверим, работает ли SSL веб-сайт и могут ли браузеры аутентифицировать веб-сервер. Теперь не должно появиться никаких сообщений:

  >

  

  Рисунок 5. Безопасное соединение с действующим законным сертификатом.

   

  Заключение второй части

  Во второй части мы рассказали, как настроить mod_ssl и как создать и использовать X.509v3 сертификаты веб сервера. В следующей, третьей и последней части этого цикла статей мы обсудим процесс аутентификации клиентов через сертификаты, а также часты ошибки системных администраторов и известные атаки, которые могут представлять реальную угрозу SSL-соединениям.