HTTP

HTTP (англ. HyperText Transfer Protocol - "протокол передачи гипертекста") - протокол прикладного уровня передачи данных (изначально - в виде гипертекстовых документов). Основой HTTP является технология "клиент-сервер", то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов.

Большинство протоколов предусматривают установление TCP-сессии, в ходе которой один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой авторизации. HTTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (неанонимного) доступа в HTTP используются cookies; причём такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера. При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. HTTP перед тем, как передать сами данные, передаёт в заголовке строчку "Content-Type: тип/подтип", позволяющую клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов - в простейшем случае картинки в разных форматах). Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.

Перечисленные особенности HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это превратило Internet из "академической игрушки" в "коммерческий сервис": появились компании, основным полем деятельности которых стало предоставление доступа в Internet (компании-провайдеры) и создание сайтов.

HTTP используется также в качестве "транспорта" для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV. Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

HTTP - протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме "запрос-ответ". Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами "запрос-ответ". Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

HTTP/0.9 был предложен в марте 1991 года Тимом Бернерсом-Ли, работавшим тогда в CERN, как механизм для доступа к документам в Интернете и облегчения навигации посредством использования гипертекста. Самая ранняя версия протокола HTTP/0.9 была впервые опубликована в январе 1992 г. (хотя реализация датируется 1990 годом). Спецификация протокола привела к упорядочению правил взаимодействия между клиентами и серверами HTTP, а также чёткому разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения.

HTTP/1.0 В мае 1996 года для практической реализации HTTP был выпущен информационный документ RFC 1945 , что послужило основой для реализации большинства компонентов HTTP/1.0.

HTTP/1.1 Текущая версия протокола, принята в июне 1999 года[3]. Новым в этой версии был режим "постоянного соединения": TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он обращается, что сделало возможным более простую организацию виртуального хостинга.

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

1. Стартовая строка (англ. Starting line) - определяет тип сообщения;
2. Заголовки (англ. Headers) - характеризуют тело сообщения, параметры передачи и прочие сведения;
3. Тело сообщения (англ. Message Body) - непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Уязвимость HTTP

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

Перехват трафика может осуществляться:

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

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

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

Атака "человек посередине" (англ. Man in the middle, MitM-атака) - ситуация, когда атакующий способен читать и видоизменять по своей воле сообщения, которыми обмениваются корреспонденты, причём ни один из последних не может догадаться о его присутствии в канале. Метод компрометации канала связи, при котором взломщик, подключившись к каналу между контрагентами, осуществляет активное вмешательство в протокол передачи, удаляя, искажая информацию или навязывая ложную. Предположим, объект A планирует передать объекту B некую информацию. Объект C обладает знаниями о структуре и свойствах используемого метода передачи данных, а также о факте планируемой передачи собственно информации, которую С планирует перехватить. Для совершения атаки С "представляется" объекту А как В, а объекту В - как А. Объект А, ошибочно полагая, что он направляет информацию В, посылает её объекту С. Объект С, получив информацию, и совершив с ней некоторые действия (например, скопировав или модифицировав в своих целях) пересылает данные собственно получателю - В; объект В, в свою очередь, считает, что информация была получена им напрямую от А.

Шифрование

SSL (англ. Secure Sockets Layer - уровень защищённых сокетов) - криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

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

SSL состоит из двух уровней. На нижнем уровне многоуровневого транспортного протокола (например, TCP) он является протоколом записи и используется для инкапсуляции (то есть формирования пакета) различных протоколов (SSL работает совместно с таким протоколами как POP3, IMAP, XMPP, SMTP и HTTP). Для каждого инкапсулированного протокола он обеспечивает условия, при которых сервер и клиент могут подтверждать друг другу свою подлинность, выполнять алгоритмы шифрования и производить обмен криптографическими ключами, прежде чем протокол прикладной программы начнёт передавать и получать данные.

Для доступа к веб-страницам, защищённым протоколом SSL, в URL вместо обычного префикса (schema) http, как правило, применяется префикс https, указывающий на то, что будет использоваться SSL-соединение. Стандартный TCP-порт для соединения по протоколу https - 443.

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

TLS (англ. Transport Layer Security) - криптографический протокол, обеспечивающий защищённую передачу данных между узлами в сети Интернет.

TLS-протокол основан на Netscape SSL-протоколе версии 3.0 и состоит из двух частей - TLS Record Protocol и TLS Handshake Protocol. Различие между SSL 3.0 и TLS 1.0 незначительные. TLS Working Group, основанная в 1996 году, продолжает работать над протоколом. TLS предоставляет возможности аутентификации и безопасной передачи данных через Интернет с использованием криптографических средств. Часто происходит лишь аутентификация сервера, в то время как клиент остается неаутентифицированным. Для взаимной аутентификации каждая из сторон должна поддерживать инфраструктуру открытого ключа (PKI), которая позволяет защитить клиент-серверные приложения от перехвата сообщений, редактирования существующих сообщений и создания поддельных.

SSL включает в себя три основных фазы:

• Диалог между сторонами, целью которого является выбор алгоритма шифрования
• Обмен ключами на основе криптосистем с открытым ключом или аутентификация на основе сертификатов.
• Передача данных, шифруемых при помощи симметричных алгоритмов шифрования

Последовательность действий при установлении TLS соединения:

• клиент подключается к серверу, поддерживающему TLS, и запрашивает защищенное соединение;
• клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций;
• сервер выбирает из списка, предоставленного клиентом, наиболее устойчивые алгоритмы, которые также поддерживаются сервером, и сообщает о своем выборе клиенту;
• сервер отправляет клиенту цифровой сертификат для собственной идентификации. Обычно цифровой сертификат содержит имя сервера, имя доверенного центра сертификации и открытый ключ сервера;
• клиент может связаться с сервером доверенного центра сертификации и подтвердить аутентичность переданного сертификата до начала передачи данных;
• для того чтобы сгенерировать сеансовый ключ для защищенного соединения, клиент шифрует случайно сгенерированную цифровую последовательность открытым ключом сервера и посылает результат на сервер. Учитывая специфику алгоритма асимметричного шифрования, используемого для установления соединения, только сервер может расшифровать полученную последовательность, используя свой закрытый ключ;

HTTPS

HTTPS (Hypertext Transfer Protocol Secure) - расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, "упаковываются" в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.

Система была разработана компанией Netscape Communications Corporation, чтобы обеспечить аутентификацию и защищённое соединение. HTTPS широко используется в мире Веб для приложений, в которых важна безопасность соединения, например, в платежных системах. В настоящее время HTTPS поддерживается наиболее популярными браузерами.

HTTPS, использует шифрованные транспортные механизмы SSL и TLS. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения - от снифферских атак и атак типа man-in-the-middle.

По умолчанию HTTPS URL использует 443 TCP-порт (для незащищённого HTTP - 80). Чтобы подготовить веб-сервер для обработки https-соединений, администратор должен получить и установить в систему сертификат для этого веб-сервера. Сертификат состоит из двух частей (двух ключей) - public и private. Public-часть сертификата используется для зашифровывания трафика от клиента к серверу в защищённом соединении, private-часть - для расшифровывания полученного от клиента зашифрованного трафика на сервере. Метод также может использоваться для аутентификации клиента, чтобы обеспечить доступ к серверу только авторизированным пользователям. Для этого администратор обычно создаёт сертификаты для каждого пользователя и загружает их в браузер каждого пользователя. Также будут приниматься все сертификаты, подписанные организациями, которым доверяет сервер. Такой сертификат обычно содержит имя и адрес электронной почты авторизованного пользователя, которые проверяются при каждом соединении, чтобы проверить личность пользователя без ввода пароля.

Сертификат должен быть подписан уполномоченной стороной (компанией-сертификатором - Certificate authority), которая будет гарантировать клиентам, что держатель сертификата является тем, за кого себя выдаёт.

В HTTPS для шифрования используется длина ключа 40, 56, 128 256 бит. Старые версии браузеров использует длину ключа 40 бит (пример тому - IE), что связано с экспортными ограничениями в США. Длина ключа 40 бит не является сколько-нибудь надёжной. Многие современные сайты требуют использования новых версий браузеров, поддерживающих шифрование с длиной ключа 128 или 256 бит, с целью обеспечить достаточный уровень безопасности. Такое шифрование значительно затрудняет раскодирование.

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

httpd
Пакет httpd содержит демона httpd и сопутствующие утилиты, файлы конфигурации, значки, модули HTTP-сервера Apache, страницы руководства man, а также другие файлы, используемые HTTP-сервером Apache.

mod_ssl
Пакет mod_ssl включает в себя модуль mod_ssl, обеспечивающий сильное шифрование для HTTP-сервера посредством протоколов «безопасность на уровне сокетов» (Secure Sockets Layer, SSL) и «безопасность на транспортном уровне» (Transport Layer Security, TLS).

openssl
Пакет openssl содержит набор инструментов OpenSSL. В пакете OpenSSL реализованы протоколы SSL и TLS, а также включена криптографическая библиотека общего назначения.

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

httpd-devel
Пакет httpd-devel содержит включаемые файлы HTTP-сервера Apache (include), файлы заголовков и утилиту APXS. Все они вам понадобятся, если помимо модулей, поставляемых с продуктом, вы намерены загружать дополнительные модули. Обратитесь к Справочному руководству по Red Hat Enterprise Linux за дополнительной информацией о загрузке модулей на безопасном сервере, используя функциональность динамических разделяемых объектов (Dynamic Shared Object, DSO) сервера Apache. Если вы не намерены загружать на своём HTTP-сервере Apache другие модули, устанавливать этот пакет не требуется.

Пакеты OpenSSH
Пакет OpenSSH содержат набор сетевых инструментов OpenSSH для регистрации на удалённом компьютере и выполнения команд. Инструменты OpenSSH шифруют все передаваемые данные (включая пароли), что предотвращает перехват информации, похищение соединений и другие атаки на соединения между вашим компьютером и удалённым.
Пакет openssh содержит ключевые файлы, необходимые и клиентским, и серверным программам OpenSSH. Пакет openssh также содержит утилиту scp, безопасную замену rcp (для безопасного копирования файлов между компьютерами).
Пакет openssh-askpass обеспечивает отображение диалогового окна, в котором пользователь вводит пароль во время использования агента OpenSSH.
Пакет openssh-askpass-gnome может использоваться в среде рабочего стола GNOME для отображения графического диалогового окна, когда программы OpenSSH запрашивают пароль. Если вы используете GNOME и утилиты OpenSSH, вы должны установить этот пакет.
Пакет openssh-server содержит демона безопасной оболочки sshd и связанные с ним файлы. Демон безопасной оболочки находится на серверной стороне набора OpenSSH и должен быть установлен на вашем компьютере, чтобы клиенты SSH смогли к нему подключаться.
Пакет openssh-clients содержит клиентские программы, необходимые для установления защищённого подключения к серверам SSH, включая следующие: ssh — безопасная замена rsh; sftp — безопасная замена ftp (утилите передачи файлов между компьютерами); slogin — безопасная замена rlogin (утилите удалённой регистрации в системе) и telnet (утилите связи с удалённым узлом по протоколу Telnet).

openssl-devel
Пакет openssl-devel содержит статические библиотеки и включаемые файлы (include), необходимые для компиляции приложений, использующих различные криптографические алгоритмы и протоколы. Вы должны устанавливать этот пакет, только если вы разрабатываете приложения с поддержкой SSL — вам не нужно устанавливать его, если вы только используете SSL.

stunnel
В пакете stunnel реализовано туннелирование Stunnel SSL. Stunnel поддерживает SSL-шифрование TCP-соединений. Он обеспечивает шифрование для демонов и протоколов, не рассчитанных на SSL (например, POP, IMAP и LDAP), без внесения изменений в код демона.

* Более новые реализации различных демонов могут предлагать встроенную поддержку SSL, как, например, dovecot или сервер OpenLDAP slapd, и может быть предпочтительнее использовать её, а не stunnel. Например, использование stunnel обеспечивает только туннелирование протоколов, тогда как в демоне slapd службы OpenLDAP встроенная поддержка позволяет также обрабатывать запросы на использование шифрования в ответ на запрос клиента StartTLS.

Ваш безопасный сервер обеспечивает безопасность, используя сочетание протокола SSL и (в большинстве случаев) цифровой сертификат, выданный Центром Сертификации (Certificate Authority, CA). SSL выполняет шифрование соединений, а также взаимную проверку подлинности между браузерами и вашим безопасным сервером. Цифровой сертификат, выданный центром сертификации (CA), обеспечивает проверку подлинности вашего безопасного сервера (CA потверждает подлинность вашей организации, пользуясь своей репутацией). Когда ваш браузер использует шифрование SSL, адрес ресурса (URL), в строке адреса, будет начинаться с префикса https://.

При шифровании используются ключи (представьте себе открывающий и закрывающий ключ). При обычном или симметричном шифровании, на обоих концах соединения используется один ключ, кодирующий и декодирующий передаваемые данные. При шифровании с открытым ключом или асимметричном шифровании, существуют два ключа: открытый ключ и закрытый ключ. Человек или организация сохраняет свой закрытый ключ в секрете и публикует свой открытый ключ. Данные, зашифрованные открытым ключом, могут быть расшифрованы закрытым ключом; данные, закодированные закрытым ключом, могут быть декодированы только открытым ключом.

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

Безопасный сервер будет использовать сертификат, чтобы доказать браузерам свою подлинность. Вы можете сформировать свой собственный сертификат (называемый «выданным себе» (self-signed) сертификатом) или получить сертификат от центра сертификации. Сертификат от доверенного центра сертификации гарантирует, что сайт связан с конкретной компанией или организацией.

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

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

• Если вы изменили IP-адрес или имя домена — Сертификаты выдаются для определённого сочетания IP-адреса и доменного имени. Если вы меняете IP-адрес или доменное имя, вы должны получить новый сертификат.
• Если вы получили сертификат VeriSign и заменили программное обеспечение сервера — VeriSign — это широко известный центр сертификации. Если у вас есть сертификат VeriSign, имеющий другое предназначение, вы можете попытаться использовать его на вашем новом безопасном сервере. Однако это не допускается, так как VeriSign выдаёт сертификаты для конкретного программного обеспечения сервера и совокупности IP-адреса и имени домена.
  Если вы меняете один из этих параметров (например, если вы ранее использовали другой безопасный сервер), сертификат VeriSign, полученный вами для предыдущей конфигурации, с новой конфигурацией работать не будет. Вы должны получить новый сертификат.

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

Переместите существующий ключ в: /etc/httpd/conf/ssl.key/server.key
Переместите существующий сертификат в: /etc/httpd/conf/ssl.crt/server.crt

* Если вы производили обновление с Red Hat Secure Web Server, ваш старый ключ (httpsd.key) и сертификат (httpsd.crt) располагаются в каталоге /etc/httpd/conf/.

Переместите свой ключ и сертификат, чтобы их мог использовать безопасный сервер. Выполните следующие команды для перемещения и переименования ваших файлов ключа и сертификата:
mv /etc/httpd/conf/httpsd.key /etc/httpd/conf/ssl.key/server.key
mv /etc/httpd/conf/httpsd.crt /etc/httpd/conf/ssl.crt/server.crt

Затем запустите свой безопасный сервер, выполнив команду: /sbin/service httpd start
Вам предлагается ввести свою секретную фразу. После того как вы введёте её и нажмёте [Enter], сервер запустится.

Если вы устанавливали безопасный веб-сервер из RPM-пакета, предоставленного Red Hat, случайный ключ и сертификат для проверки автоматически генерируются и помещаются в соответствующие каталоги. Однако до начала эксплуатации вашего безопасного сервера, вы должны сгенерировать свои собственные ключи и получить сертификат, подтверждающий подлинность вашего сервера.

Для работы вашего безопасного сервера вам потребуется ключ и сертификат — это означает, что вы можете либо выдать себе сертификат самостоятельно, либо приобрести сертификат, подписанный центром сертификации. Чем же они будут отличаться?

Сертификат, подписанный центром сертификации, даёт вашему серверу два важных преимущества:

• Браузеры автоматически принимают сертификат (обычно) и устанавливают безопасное соединение, не спрашивая пользователя.
• Когда центр сертификации выдаёт подписанный сертификат, он гарантирует подлинность организации, публикующей в Интернете веб-страницы.

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

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

Процесс получения сертификата в центре сертификации достаточно прост. Ниже приведено его краткое описание:

• 1. Создать пару ключей (открытый и закрытый) для шифрования.
• 2. Сформировать запрос на получение сертификата для открытого ключа. Сертификат будет содержать информацию о вашем сервере и компании, владеющей им.
• 3. Послать запрос на получение сертификата вместе с документами, подтверждающими вашу подлинность, в центр сертификации. Red Hat не даёт никаких рекомендаций относительно того, какой центр сертификации выбирать. Ваше решение может основываться на предыдущем опыте или мнении ваших друзей и коллег, а может только на стоимости этой услуги. Выбрав для себя центр сертификации, вы должны следовать указаниям этого центра, чтобы получить от него сертификат.
• 4. Когда центр сертификации проверит вашу подлинность, он предоставит вам цифровой сертификат.
• 5. Установите этот сертификат на вашем безопасном сервере, после этого он сможет осуществлять безопасные транзакции.

Как бы вы не получали сертификат — из центра сертификации, или сгенерировали самостоятельно, начинать следует с создания ключей. Чтобы сгенерировать ключ, вы должны быть пользователем root. Сначала, с помощью команды cd перейдите в каталог /etc/httpd/conf/. Удалите фиктивный ключ и сертификат, созданные во время установки, выполнив следующие команды:
rm ssl.key/server.key
m ssl.crt/server.crt

Затем создайте свой собственный случайный ключ. Перейдите в каталог /usr/share/ssl/certs/ и введите следующую команду:
make genkey

На экране компьютера появляется примерно следующее:

umask 77 ; \
/usr/bin/openssl genrsa -des3 1024 > /etc/httpd/conf/ssl.key/server.key
Generating RSA private key, 1024 bit long modulus
.......++++++
................................................................++++++
e is 65537 (0x10001)
Enter pass phrase:

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

Введите секретную фразу ещё раз, чтобы подтвердить её правильность. Если вы не допустите ошибок, будет создан файл /etc/httpd/conf/ssl.key/server.key, содержащий ваш ключ.

Обратите внимание, если вы не хотите вводить секретную фразу при каждом запуске вашего безопасного сервера, вместо команды make genkey можно пеосупить так.

Создать свой ключ с помощью следующей команды: /usr/bin/openssl genrsa 1024 > /etc/httpd/conf/ssl.key/server.key
Затем назначить правильные права доступа к этому файлу, выполнив следующую команду: chmod go-rwx /etc/httpd/conf/ssl.key/server.key

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

* Отключение запроса секретной фразы для сервера представляет собой угрозу безопасности. Отключать запрос секретной фразы для безопасного сервера не рекомендуется.

В зависимости от защищённости вашего компьютера, у вас могут возникнуть проблемы, связанные с отключением секретной фразы. Например, если злоумышленник взломает систему безопасности UNIX на этом компьютере, он сможет получить ваш закрытый ключ (содержимое файла server.key). Затем этот ключ может использоваться для фальсификации веб-страниц и компрометации вашего безопасного сервера.

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

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

Как только вы создали ключ, вы можете сформировать запрос на получение сертификата, который затем нужно отправить в выбранный вами центр сертификации. Убедитесь в том, что вы находитесь в каталоге /usr/share/ssl/certs/, и введите следующую команду: make certreq

На экране появится следующее сообщение и предложение ввести вашу секретную фразу (если только вы не отказались от её использования):

umask 77 ; \
/usr/bin/openssl req -new -key /etc/httpd/conf/ssl.key/server.key 
-out /etc/httpd/conf/ssl.csr/server.csr
Using configuration from /usr/share/ssl/openssl.cnf
Enter pass phrase:

Введите секретную фразу, выбранную при создании ключа, если она требуется. Затем на экране появятся дополнительные указания и вы должны будете ответить на несколько вопросов. Введённые вами данные включаются в запрос на получение сертификата. Эти вопросы и примеры ответов на них приведены ниже:

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a
DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:North Carolina
Locality Name (eg, city) [Newbury]:Raleigh
Organization Name (eg, company) [My Company Ltd]:Test Company
Organizational Unit Name (eg, section) []:Testing
Common Name (your name or server's hostname) []:test.example.com
Email Address []:admin@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Ответы по умолчанию приводятся в квадратных скобках ([]) сразу после вопроса. Например, в первой строке задаётся код страны, в которой будет использоваться сертификат, например: Country Name (2 letter code) [GB]:

Вы должны определить остальные значения. Все они достаточно понятны, но вы должны принять учитывать следующее:

• Не следует сокращать название местности или штата. Вводите их полностью (например, St. Louis должно быть введено как Saint Louis).
• Если вы отправляете этот запрос (CSR) в центр сертификации (CA), будьте очень внимательны, заполняя все эти поля, но особенно важны Organization Name (Название организации) и Common Name (Имя сервера). Центр сертификации проверяет информацию, представленную в запросе (CSR), чтобы убедиться в том, что сервер с именем Common Name, закреплён именно за вашей организацией. Центр сертификации не принимает запросы CSR, в которых содержится неверная информация.
• Убедитесь в том, что в качестве значения Common Name введено реальное имя вашего безопасного сервера (правильное имя DNS), а не какой-либо из его псевдонимов.
• Избегайте использования специальных символов, например @, #, &, ! и т.д. Некоторые центры сертификации не примут запрос сертификата, содержащий специальные символы. Поэтому, если название компании включает амперсанд (&), запишите его в виде «and» вместо «&».
• Не заполняйте дополнительные атрибуты (A challenge password(Пароль вызова) и An optional company name (Необязательное имя компании)). Если вы решили не заполнять эти поля, просто нажмите [Enter], чтобы согласиться с предложенным ответом, в каждом из этих запросов.

Когда вы заканаиваете ввод этих сведений, создаётся файл /etc/httpd/conf/ssl.csr/server.csr. Этот файл и есть ваш запрос сертификата, готовый к отправке в центр сертификации.

После того как вы определились с выбором CA, следуйте инструкциям, приведённым на сайте этого центра. Из них вы узнаете, как отправить запрос сертификата, произвести оплату и какие дополнительные документы требуются.

После того, как вы выполните все требования центра сертификации, они вышлют вам сертификат (обычно по электронной почте). Сохраните или скопируйте через буфер обмена полученный сертификат в файл /etc/httpd/conf/ssl.crt/server.crt. Обязательно сохраните копию этого файла.

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

Чтобы создать сертификат, подписанный самостоятельно, сначала вы должны создать случайный ключ как описано выше

Получив ключ, перейдите в каталог /usr/share/ssl/certs/ и введите следующую команду: make testcert

На экране появляются примерно следующие сообщения и вам предлагается ввести секретную фразу (если только вы не сгенерировали ключ без секретной фразы):

umask 77 ; \
/usr/bin/openssl req -new -key /etc/httpd/conf/ssl.key/server.key 
-x509 -days 365 -out /etc/httpd/conf/ssl.crt/server.crt
Using configuration from /usr/share/ssl/openssl.cnf
Enter pass phrase:

Затем у вас запрашиваются дополнительные сведения. Примерные сообщения компьютера и ответы пользователя приведены ниже (вы должны ввести верные данные организации и узла):

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a
DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US      
State or Province Name (full name) [Berkshire]:North Carolina
Locality Name (eg, city) [Newbury]:Raleigh
Organization Name (eg, company) [My Company Ltd]:My Company, Inc.
Organizational Unit Name (eg, section) []:Documentation
Common Name (your name or server's hostname) []:myhost.example.com
Email Address []:myemail@example.com

После того, как вы введёте правильную информацию, самостоятельно подписанный сертификат создаётся в файле /etc/httpd/conf/ssl.crt/server.crt. Сгенерировав сертификат, перезапустите безопасный сервер, выполнив следующую команду: /sbin/service httpd restart

Чтобы проверить тестовый сертификат, установленный по умолчанию, сертификат, выданный центром сертификации, или подписанный самостоятельно, обратитесь в своём браузере к следующей странице https://vashserver.com

* Обратите внимание на s после http. Префикс https: используется для безопасных HTTP-транзакций.

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

Стандартным портом для безопасных веб-соединений принят порт 443. Стандартным портом для не безопасных веб-соединений принят порт 80. Безопасный сервер, настроенный по умолчанию, принимает подключения к этим стандартным портам. Поэтому указывать номер порта в адресе ресурса не обязательно (при этом подразумевается стандартный порт).

Однако, если вы настроили сервер на использование нестандартного порта (т.е. отличного от 80 и 443), при подключении к этому серверу вы должны указывать номер порта в каждом адресе.

Например, вы можете настроить сервер так, что виртуальный узел будет использовать не безопасный порт 12331. При обращении к этому виртуальному узлу вы должны будете указать в адресе номер этого порта, например http://vashserver.com:12331