Установка apache php ssl

Настройка Apache + SSL для работы сайта по HTTPS

Инструкция написана для операционных систем на базе UNIX.

Шаг 1. Создание сертификата

Для боевого сервера, сертификат должен быть получен от доверенного центра сертификации — либо локального для компании, либо коммерческого. Или получен бесплатно от Let's Ecnrypt.

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

а) на Red Hat / CentOS:

б) на Debian / Ubuntu:

Создаем папку для сертификатов и переходим в нее:

mkdir ssl ; cd ssl

И генерируем сертификат:

openssl req -new -x509 -days 1461 -nodes -out cert.pem -keyout cert.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=test.dmosk.local/CN=test"

* в данном примере созданы открытый и закрытый ключи на 4 года (1461 день); значения параметра subj могут быть любыми в рамках тестирования.

Шаг 2. Установка модуля SSL для Apache

Прежде, чем устанавливать модуль, выполняем команду:

apachectl -M | grep ssl

Если видим строчку, на подобие:

Спускаемся к шагу 3 данной инструкции.

Иначе, устанавливаем httpd ssl_module.

yum install mod_ssl

б) Для Ubuntu/Debian:

Открываем файл конфигурации apache:

* подразумевается, что используется apache 2.4.

Находим и снимаем комментарии со следующих строчек:

.
LoadModule ssl_module libexec/apache24/mod_ssl.so
.
Include etc/apache24/extra/httpd-ssl.conf
.

И ставим комментарии в следующих строках:

#<IfModule ssl_module>
#SSLRandomSeed startup builtin
#SSLRandomSeed connect builtin
#</IfModule>

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

systemctl restart httpd

systemctl restart apache2

service apache2 restart

* первая, как правило, используется в системах на базе RPM, вторая — DEB, третья — BSD.

Шаг 3. Настройка Apache

Выходим из папки ssl:

Открываем файл с настройкой виртуальный доменов.

* где site.conf — конфигурационный файл для конкретного сайта

В открытый файл добавляем следующее:

<VirtualHost *:443>
ServerName site.ru
DocumentRoot /var/www/apache/data
SSLEngine on
SSLCertificateFile ssl/cert.pem
SSLCertificateKeyFile ssl/cert.key
</VirtualHost>

* где ServerName — домен сайта; DocumentRoot — расположение файлов сайта в системе; SSLCertificateFile и SSLCertificateKeyFile — пути до файлов ключей, которые были сгенерированы на шаге 1.

Проверяем корректность настроек в Apache:

Перечитываем конфигурацию apache:

Шаг 4. Проверка работоспособности

Открываем браузер и переходим на наш сайт, добавив https://. При использовании самоподписного сертификата (как в нашем случае), обозреватель выдаст предупреждение, что передача данных не безопасна. Подтверждаем наше намерение открыть сайт. Если все работает, переходим к шагу 5.

Если сайт не заработал, пробуем найти причину по log-файлу. Как правило, он находится в каталоге /var/log/apache или /var/log/httpd.

Шаг 5. Настройка редиректа

Чтобы все запросы по http автоматически перенаправлялись на https, необходимо настроить перенаправление (redirect). Есть несколько способов это сделать.

В конфигурационном файле

Открываем файл с настройкой виртуальных доменов (как в шаге 3) и дописываем следующее:

<VirtualHost *:80>
ServerName site.ru
RewriteEngine On
RewriteCond % off
RewriteRule (.*) https://%% [R=301,L]
</VirtualHost>

* в конкретном примере, мы перенаправили все запросы для сайта site.ru.
** обратите особое внимание, что если у Вас уже есть VirtualHost *:80 для настраиваемого сайта, необходимо его закомментировать или отредактировать.

В файле .htaccess

Установка модуля rewrite

Чтобы перенаправление работало в Apache, необходимо установить модуль rewrite.

а) в CentOS открываем конфигурационный файл и проверяем наличие строки:

LoadModule rewrite_module modules/mod_rewrite.so

* если ее нет, добавляем; если она закомментирована, снимаем комментарий.

systemctl restart httpd

systemctl restart apache2

Apache + NGINX

При использовании веб-сервера на базе и Apache и NGINX, как правило, наружу смотрит последний. В таком случае, именно он будет отвечать на http-запросы, и в таком случае нужно настраивать SSL на NGINX.

Источник

Apache SSL: переход Apache на HTTPS

Протокол HTTPS позволяет передавать данные между сайтом и пользователем в зашифрованном виде, то есть посторонние лица не могут увидеть содержимое передаваемых данных и изменить их.

Веб-сервер Apache поддерживает работу HTTPS. Для настройки HTTPS на Apache нужен SSL сертификат. Точнее говоря, «SSL сертификат» включает в себя приватный ключ и публичный ключ (сертификат). Также вместе с SSL ключами дополнительно могут присылаться сертификаты центра сертификации, корневой сертификат.

Сертификаты SSL

SSL сертификаты можно разделить на два вида: валидные и самоподписанные.

Сертификат SSL можно сгенерировать у себя на компьютере. Причём можно сгенерировать для любого доменного имени. Но к таким сертификатам у веб-браузеров нет доверия. Поэтому если открыть сайт, защищённый таким сертификатом, то веб-браузер напишет ошибку, что сертификат получен из ненадёжного источника и либо запретит открывать этот сайт, либо предложит перейти на сайт на ваш страх и риск. Это так называемые «самоподписанные сертификаты». Чтобы браузер не выдавал ошибку о ненадёжного сертификате, его нужно добавить в список доверенных. Такие сертификаты подойдут для тестирования веб-сервера и обучению настройки веб-сервера для работы с SSL и HTTPS. Ещё такой сертификат можно использовать на сайте, к которому имеет доступ ограниченный круг лиц (несколько человек) — например, для сайтов в локальной сети. В этом случае они все могут добавить сертификат в доверенные.

Для реального сайта такой сертификат не подойдёт.

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

1) получить тестовый сертификат на 3 месяца (затем его можно продлить)

2) купить сертификат — в этом случае он действует от года и более

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

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

Как сгенерировать SSL сертификат в Windows

У меня веб-сервер установлен в папку C:\Server\bin\Apache24, поэтому если у вас он в другой директории, то подправьте команды под свои условия.

Откройте командную строку Windows (Win+x, далее выберите «Windows PowerShell (администратор)»). В командной строке введите команды:

При вводе последней команды появятся запросы на английском языке. Ниже следует их перевод.

Вас попросят ввести информацию, которая будет включена в запрос вашего сертификата. То, что вы будете вводить, называется Distinguished Name или DN. Там всего несколько полей, которые можно оставить пустыми. В некоторых полях будут значения по умолчанию. Если вы введёте '.', то поле будет оставлено пустым.

Двухбуквенное имя страны (двухбуквенный код)

Название штата или провинции/области (полное имя)

Название населённого пункта (например, города)

Подразделение организации (т.е. отдел)

Общее имя (например, FQDN сервера или ВАШЕ имя). Это самая важная часть — здесь нужно ввести доменное имя. Можете ввести localhost.

Теперь выполните команду:

В результате в каталоге C:\Server\bin\Apache24\bin\ должны появиться три новых файла:

localhost.key
localhost.csr
localhost.crt

Из них нам понадобятся только два:

localhost.key
localhost.crt

Как в Windows для Apache подключить SSL сертификаты

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

Для настройки использования SSL на локальном веб-сервере Apache в Windows следуйте инструкции ниже (в моём случае веб-сервер установлен по этой инструкции, если у вас не так, то отредактируйте пути до файлов).

В каталоге C:\Server\ создайте новую папку certs и переместите туда файлы localhost.key и localhost.crt.

В директории C:\Server\bin\Apache24\conf\ откройте текстовым редактором файл httpd.conf. В самый низ добавьте туда строки:

Обратите внимание, что вам может понадобиться отредактировать следующие директивы

DocumentRoot — укажите путь до сайтов на сервере
ServerName — укажите имя вашего хоста, если это не локалхост

Обратите внимание, что мы не просто поместили эти строки в конфигурационный файл, а заключили их в контейнер VirtualHost. Дело в том, что если этого не сделать, то директива SSLEngine on включит SSL для всего веб-сервера, и даже при попытке открыть сайты на 80 порту, эти подключения будут обрабатываться как HTTPS, что вызовет ошибку «Bad Request. Your browser sent a request that this server could not understand». По этой причине эти настройки помещены в контейнер виртуального хоста. Обратите внимание, что используется ключевое слово _default_ — то есть сюда будут собираться все запросы на 443 порт если они не предназначены для другого хоста, который также настроен. То есть при желании вы можете создать больше виртуальных хостов для работы с HTTPS, при этом вместо _default_ указывайте IP хоста или символ * (звёздочка).

После этого сохраните изменения, закройте файл и перезапустите веб-сервер.

Для проверки сделанных изменений, перейдите по адресу https://localhost/ (протокол HTTPS). Поскольку сертификат является самоподписанным, то появится такое сообщение:

К самоподписанным сертификатам нет доверия и эту ошибку нельзя убрать без добавления таких сертификатов в доверенные. Для перехода нажмите «Всё равно продолжить».

Как уже было сказано, валидные сертификаты нужно покупать, либо использовать тестовые. В чём подвох использования тестовых сертификатов? Формально, в какой-то момент их могут перестать выдавать, но, на самом деле, уже сейчас многие сайты годами живут с такими тестовыми сертификатами. На современных хостингах настроено автоматическое подключение и продление таких сертификатов — это просто супер удобно. Обычно на хостингах предусмотрено некоторое количество абсолютно бесплатных SSL сертификатов с автоматическим продлением, но за небольшую плату (10 рублей в месяц), можно подключить тестовые сертификаты для любого количества сайтов. Пример такого хостинга здесь.

Решение проблем

При некоторых условиях может возникнуть следующая ошибка:

Главная подсказка в первой строке: Can't open C:\Program Files\Common Files\SSL/openssl.cnf for reading, No such file or directory — она означает, что возникла ошибка чтения файла C:\Program Files\Common Files\SSL/openssl.cnf из-за того, что он отсутствует.

Файл openssl.cnf поставляется с самим веб-сервером Apache и находится в папке conf. Поэтому есть несколько вариантов, как исправить эту ошибку. Например, можно создать нужные папки и скопировать туда этот файл. Но можно пойти более простым путём — на время создания сертификатов установить переменную окружения OPENSSL_CONF указав в ней правильный путь до файла.

Также нужно переключиться из PowerShell в обычную командную строку Windows, поскольку иначе переменная окружения почему-то не устанавливается. Допустим, сервер размещён в папке C:\Server\bin\Apache24\bin\, тогда файл openssl.cnf расположен по пути C:\Server\bin\Apache24\conf\openssl.cnf, в этом случае, чтобы исправить ошибку Can't open C:\Program Files\Common Files\SSL/openssl.cnf for reading, No such file or directory нужно выполнить:

Отредактируйте пути в этих командах в соответствии с вашей структурой папок.

Источник

Записки IT специалиста

Настраиваем Apache для работы по HTTPS (SSL) с сертификатами Let’s Encrypt

Автор: Уваров А.С.
24.10.2019

Сегодня защищенное соединение перестало быть уделом сайтов, работающих с пользовательскими данными, а стало насущной необходимостью для всех, даже если у вас простой блог о личном увлечении. Большинство современных браузеров при заходе на простой HTTP-сайт уже указывают в адресной строке, что подключение не защищено, но в скором будущем начнут помечать такие сайты как небезопасные. Тем более что с приходом Let’s Encrypt шифрование стало доступно каждому и настроить его несложно, о чем мы и расскажем в данной статье.

Начнем мы с наиболее популярного веб-сервера Apache, первоначальная настройка которого выполнена по нашей статье: Настраиваем веб-сервер на базе Apache в Debian / Ubuntu Server. В данной статье будет использоваться Apache 2.4 установленный в среде Debian 10, но все сказанное ниже будет справедливо для любого основанного на Debian или Ubuntu дистрибутива, а с некоторыми поправками — для любой Linux системы.

Будем считать, что у нас уже настроен как минимум один виртуальный хост, на котором работает сайт, допустим, example.com, минимальная конфигурация виртуального хоста должна выглядеть примерно так:

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

Прежде всего нам потребуется настроить веб-сервер для работы с Let’s Encrypt, сделав так, чтобы сертификаты можно было легко получать для любого обслуживаемого сервером сайта без дополнительных настроек. Создадим для этого специальную директорию:

И сделаем ее владельцем веб сервер:

Затем создадим файл конфигурации для Аpache:

и внесем в него следующий текст:

Эта настройка будет перенаправлять все запросы к /.well-known/acme-challenge любого сайта в созданную нами директорию /var/www/letsencrypt.

Подключим конфигурационный файл:

и проверим конфигурацию на ошибки:

Затем перезапустим веб-сервер

Следующим шагом установим certbot, в современных дистрибутивах он включен в репозитории, поэтому достаточно выполнить:

Если вы используете более старые дистрибутивы, то обратитесь к нашей статье: Получаем сертификаты Let’s Encrypt при помощи Certbot

Пакет не требует начальной настройки и готов к работе сразу после установки. Перед тем, как получать сертификат, убедитесь, что к вашему серверу есть доступ из интернета. В любом случае советуем сначала выполнить пробное получение:

За тестовый режим отвечает ключ —dry-run, ключ —webroot указывает используемый плагин, в нашем случае отвечающий за работу с уже имеющемся веб-сервером. Опция -w указывает корневую директорию для Let’s Encrypt, которую мы создали и настроили ранее, а через ключи -d перечисляются домены и поддомены, для которых требуется получить сертификат. Если все прошло успешно вы получите лаконичное сообщение:

После того, как тест прошел успешно можно выполнить настоящее получение сертификатов, для этого просто уберите ключ —dry-run из команды.

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

Все полученные сертификаты, точнее символические ссылки на них, хранятся в /etc/letsencrypt/live в директориях с именами доменов. Настройки продления можно найти в /etc/letsencrypt/renewal, откроем настройку нашего домена /etc/letsencrypt/renewal/example.com.conf и внесем в секцию [renewalparams] следующую опцию:

Порядок расположения опций значения не имеет. Параметр renew_hook позволяет указать действие, которое следует выполнить при успешном продлении сертификата, в нашем случае это перезапуск веб-сервера Apache.

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

Затем откроем его и сразу изменим порт с 80 на 443:

Также советуем изменить имена файлов логов:

Эти опции включают SSL и указывают пути к сертификатам. В теории этого достаточно, но в современных условиях такие настройки не будут надежными, так как разрешают использование устаревших протоколов и нестойких шифров. Для получения современной и актуальной конфигурации SSL мы советуем воспользоваться сервисом moz://a SSL Configuration Generator, который предлагает несколько вариантов настроек, оптимальным является использование опции Intermediate.

Но не следует добавлять сразу все опции, ряд из них могут иметь достаточно «неожиданное» действие на неподготовленного пользователя. Поэтому сначала разберемся с шифрами и протоколами:

Первая опция отключает устаревшие и небезопасные протоколы SSLv3, TLS 1.0 и TLS 1.1, вторая задает доступные к использованию шифры. Создание набора шифров — это наиболее сложная задача, поэтому лучше довериться специалистам Mozilla, нежели изобретать велосипед самостоятельно.

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

Также разрешим использование протокола HTTP/2, если это возможно:

Сохраним файл конфигурации и подключим его:

Также нам потребуется модуль SSL:

Проверим конфигурацию и перезапустим веб-сервер:

После чего откройте сайт, явно указав протокол https://example.com

На этом этапе вы можете столкнуться с проблемой смешанного содержимого, когда определенные ресурсы сайта, например, изображения или скрипты загружаются по незащищенному протоколу HTTP. Если к первым браузеры относятся относительно лояльно, просто убирая «замочек» в адресной строке, то вторые по умолчанию блокируются. Поэтому внимательно изучите код вашего сайта и замените везде, где это возможно, получение ресурсов на защищенный протокол HTTPS. Если это невозможно, то от таких ресурсов следует отказаться.

Добившись идеальной работы сайта по HTTPS, двинемся дальше, сначала включим технологию HSTS, которая принудительно активирует защищенное соединение, если сайт хоть один раз был успешно через него загружен. При использовании данного механизма браузер будет принудительно переключаться на HTTPS даже если в строке подключения пользователь явно укажет протокол HTTP, это позволяет успешно бороться с атаками на понижение степени защиты.

Для этого добавим в конфигурацию виртуального хоста строку:

Также включим механизм OCSP Stapling, который позволяет ускорить проверку сертификата клиентом, что особенно важно для мобильных пользователей. Добавим строку:

Однако этого недостаточно, сохраним настройки виртуального хоста и снова откроем файл /etc/apache2/conf-available/le.conf, куда добавим:

Для работы вышеперечисленных опций нам потребуется модуль Headers:

Снова проверяем конфигурацию и перезапускаем сервер:

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

И в завершение настроим перенаправление клиентов с HTTP версии сайта на HTTPS, для этого откроем настройки виртуального хоста HTTP версии /etc/apache2/sites-available/example.com.conf и удалим из него все строки кроме:

А затем добавим:

Сохраним файл конфигурации и подключим модуль Rewrite:

И еще раз перезапустим сервер, не забыв проверить конфигурацию:

Теперь наш сервер настроен с учетом всех современных методик, проверить это можно на сайте SSL Labs, с текущими настройками была получена высшая оценка A+:

Как видим, настроить веб-сервер Apache для работы по HTTPS совсем несложно. А Let’s Encrypt обеспечит бесплатное получение и обновление сертификатов в автоматическом режиме. Если вы заметили, то мы ничего не писали про настройку автообновления, Certbot все уже сделал за нас.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

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

Недавно на OpenNET были опубликованы две статьи на тему установки
Apache с поддержкой SSL под FreeBSD.
Ключевой момент — генерация сертификатов.

И если в статье у Stricty представлена хоть и не совсем удачная
(малопонятна система именования файлов, лишние действия), но по
крайней мере самостоятельная попытка разобраться в этом вопросе,
то у alexch — чистой воды плагиат.
Не согласен с комментарием Максима Чиркова — нового в этой статье
ничего нет. Такого сорта статьи только запутывают читателей.

На самом деле не нужно заново изобретать велосипед, в стандартной
поставке Apache + mod_ssl и в openssl есть все необходимое.

Установка Apache 1.3 с поддержкой SSL делается очень просто:

при генерации сертификатов создается нешифрованный ключ корневого
сертификата (ca.key), сертификационный запрос (ca.csr) и
самоподписанный корневой сертификат (ca.crt), нешифрованный ключ
сервера (server.key) сервера, сертификационный запрос (server.csr)
и подписанный корневым сертификатом собственно сертификат сервера
(server.crt). Будет предложено зашифровать ключи.

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

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

И самое главное — файл корневого сертификата ca.crt необходимо
передать на клиентский компьютер и ввести в хранилище сертификатов
браузера. Только в этом случае при обращении к нашему серверу по
защищенному протоколу браузер НЕ БУДЕТ выдавать предупреждение, что
сертификат выдан организацией, не входящей в состав доверенных.

Авторы вышеупомянутых статей предлагают прописывать ссылку на файл
корневого сертификата в строке

конфигурационного файла httpd.conf, но это неверно.
Данная опция предназначена для организации проверки сертификатов
КЛИЕНТОВ на стороне сервера.

Сгенерировать сертификаты можно и по другому.
В состав дистрибутива openssl входят скрипты CA.sh и CA.pl

создаем корневой сертификат

генерируем личный ключ и сертификационный запрос сервера

и подписываем его своим корневым сертификатом.

переписываем ключ и сертификат сервера в служебный каталог Apache

Файл корневого сертификата ./demoCA/cacert.pem необходимо
распространить по клиентским компьютерам.

Если кто желает узнать о генерации ключей и сертификатов в большей
мере, рекомендую обратиться к документации на ssl

Источник

Apache 2 с SSL/TLS: Шаг за Шагом, Часть 1

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

Автор Artur Maj

Более десяти лет 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:

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

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

Разработан в 1995 году корпорацией Microsoft. В Privacy Communication Technology (PCT — Технология Конфиденциальной Связи – прим.пер.) v1.0 были усилены некоторые слабые места SSL v2.0, корпорация планировала заменить тем самым SSL. Однако, этот протокол так никогда и не получил популярности из-за появления 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 году (RFC 2246). Протокол базируется на SSL v3.0 и PCT и согласован как с методами Netscape, так и с корпорацией Microsoft. Стоит заметить, что если TLS базируется на SSL, он не 100% совместим со своим предшественником. IETF сделала некоторые поправки в безопасности, например использование HMAC вместо MAC, использование другого пересчета основного шифра и ключевого материала, добавлены коды предупреждения, отсутствует поддержка алгоритмов шифрования Fortezza и т.д. В конце концов множество противоречивых изменений привели к тому, что эти протоколы толком не могли взаимодействовать. К счастью, появился мод TLS с откатом до SSL v3.0.

«Мобильная и беспроводная» версия протокола 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, как описано ниже (изменения выделены жирным ):

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

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

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

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

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

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

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

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

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

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

После запуска сервера мы можем попробовать соединиться к нему, направив веб-браузер на 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 и процессом создания нормального сертификата.

Источник