1.0 Что такое HTTP
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально - в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году в Северной Америке доля HTTP-трафика превысила долю P2P-сетей и составила 46 %, из которых почти половина — это передача потокового видео и звука[1].
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.
1.1 Общая Структура
HTTP основывается на парадигме запросов/ответов. Запрашивающая программа (обычно она называется клиент) устанавливает связь с обслуживающей программой-получателем (обычно называется сервер) и посылает запрос серверу в следующей форме: метод запроса, URI, версия протокола, за которой следует MIME-подобное сообщение, содержащее управляющую информацию запроса, информацию о клиенте и, может быть, тело сообщения. Сервер отвечает сообщением, содержащим строку статуса (включая версию протокола и код статуса - успех или ошибка), за которой следует MIME-подобное сообщение, включающее в себя информацию о сервере, метаинформацию о содержании ответа, и, вероятно, само тело ответа. Следует отметить, что одна программа может быть одновременно и клиентом и сервером. Использование этих терминов в данном тексте относится только к роли, выполняемой программой в течение данного конкретного сеанса связи, а не к общим функциям программы.
В Internet коммуникации обычно основываются на TCP/IP протоколах. Для WWW номер порта по умолчанию - TCP 80, но также могут быть использованы и другие номера портов - это не исключает возможности использовать HTTP в качестве протокола верхнего уровня.
Для большинства приложений сеанс связи открывается клиентом для каждого запроса и закрывается сервером после окончания ответа на запрос. Тем не менее, это не является особенностью протокола. И клиент, и сервер должны иметь возможность закрывать сеанс связи, например, в результате какого-нибудь действия пользователя. В любом случае, разрыв связи, инициированный любой стороной, прерывает текущий запрос, независимо от его статуса.
1.2 Достоинства и недостатки.
Достоинства:
Простота
Протокол настолько прост в реализации, что позволяет с лёгкостью создавать клиентские приложения.
Расширяемость
Вы можете легко расширять возможности протокола благодаря внедрению своих собственных заголовков, сохраняя совместимость с другими клиентами и серверами. Они будут игнорировать неизвестные им заголовки, но при этом вы можете получить необходимый вам функционал при решении специфической задачи.
Распространённость
При выборе протокола HTTP для решения конкретных задач немаловажным фактором является его распространённость. Как следствие, это обилие различной документации по протоколу на многих языках мира, включение удобных в использовании средств разработки в популярные IDE, поддержка протокола в качестве клиента многими программами и обширный выбор среди хостинговых компаний с серверами HTTP.
Недостатки:
Большой размер сообщений
("1") Использование текстового формата в протоколе порождает соответствующий недостаток: большой размер сообщений по сравнению с передачей двоичных данных. Из-за этого возрастает нагрузка на оборудование при формировании, обработке и передаче сообщений. Для решения данной проблемы в протокол встроены средства для обеспечения кэширования на стороне клиента, а также средства компрессии передаваемого контента. Нормативными документами по протоколу предусмотрено наличие прокси-серверов, которые позволяют получить клиенту документ с наиболее близкого к нему сервера. Также в протокол было внедрено дельта-кодирование, чтобы клиенту передавался не весь документ, а только его изменённая часть.
Отсутствие «навигации»
Хотя протокол разрабатывался как средство работы с ресурсами сервера, у него отсутствуют в явном виде средства навигации среди этих ресурсов. Например, клиент не может явным образом запросить список доступных файлов, как в протоколе FTP. Предполагалось, что конечный пользователь уже знает URI необходимого ему документа, закачав который, он будет производить навигацию благодаря гиперссылкам. Это вполне нормально и удобно для человека, но затруднительно, когда стоят задачи автоматической обработки и анализа всех ресурсов сервера без участия человека. Решение этой проблемы лежит полностью на плечах разработчиков приложений, использующих данный протокол.
Нет поддержки распределённости
Протокол HTTP разрабатывался для решения типичных бытовых задач, где само по себе время обработки запроса должно занимать незначительное время или вообще не приниматься в расчёт. Но в промышленном использовании с применением распределённых вычислений при высоких нагрузках на сервер протокол HTTP оказывается беспомощен. В 1998 году W3C предложил альтернативный протокол HTTP-NG (англ. HTTP Next Generation) для полной замены устаревшего с акцентированием внимания именно на этой области[2]. Идею его необходимости поддержали крупные специалисты по распределённым вычислениям, но данный протокол до сих пор находится на стадии разработки.
1.3 Программное обеспечение.
Всё программное обеспечение для работы с протоколом HTTP разделяется на три больших категории:
Серверы как основные поставщики услуг хранения и обработки информации (обработка запросов). (Apache, Internet Information Services (IIS), lighttpd, nginx.)
Клиенты — конечные потребители услуг сервера (отправка запроса). (Internet Explorer, Safari, Opera, Mozilla…)
Прокси для выполнения транспортных служб.( Squid, UserGate, Multiproxy, Naviscope, Nginx.)
Для отличия конечных серверов от прокси в официальной документации используется термин сервер происхождения (англ. Origin server). Разумеется, один и тот же программный продукт может одновременно выполнять функции клиента, сервера или посредника в зависимости от поставленных задач. В спецификациях протокола HTTP подробно описывается поведение для каждой из этих ролей.
2.0 HTTP запрос.
Обшие сведения
Запрос - это сообщение, посылаемое клиентом серверу.
Первая строка этого сообщения включает в себя метод, который должен быть применен к запрашиваемому ресурсу, идентификатор ресурса и используемую версию протокола. Для совместимости с протоколом HTTP/0.9, существует два формата HTTP запроса:
Запрос = Простой-Запрос | Полный-Запрос
Простой-Запрос = "GET" SP Запрашиваемый-URI CRLF
Полный-Запрос = Строка-Статус
*(Общий-Заголовок | Заголовок-Запроса | Заголовок-Содержания ) CRLF
[ Содержание-Запроса ]
("2") Строка Статус
Строка Статус начинается со строки с названием метода, за которым следует URI-Запроса и использующаяся версия протокола. Элементы строки разделяются пробелами (SP). В Строке Статус не допускаются символы LF и CR, за исключением заключающей последовательности CRLF.
Строка-Статус = Метод SP URI-Запроса SP Версия-HTTP CRLF
Следует отметить, что отличие Строки Статус Полного-Запроса от Строки Статус Простого - Запроса заключается в присутствии поля Версия-HTTP.
Метод
В поле Метод указывается метод, который должен быть применен к ресурсу, идентифицируемому URI-Запроса. Названия методов чувствительны к регистру. Существующий список методов может быть расширен.
Метод = "GET" | "HEAD" | "PUT" | "POST" | "DELETE" | "LINK" | "UNLINK" | дополнительный - метод
Список методов, допускаемых отдельным ресурсом, может быть указан в поле Заголовок-Содержание "Баллов". Тем не менее, клиент всегда оповещается сервером через код статуса ответа, допускается ли применение данного метода для указанного ресурса, так как допустимость применения различных методов может динамически изменяться. Если данный метод известен серверу, но не допускается для указанного ресурса, сервер должен вернуть код статуса "405 Method Not Allowed", и код статуса "501 Not Implemented", если метод не известен или не поддерживается данным сервером. Общие методы HTTP/1.0 описываются ниже.
2.1 Примеры запросов
В данном разделе рассмотрим некоторые http-запросы при помощи программы HTTPDebuggerPro.Ссылка на программу:
(http://www. *****/apps/2115-http-debugger-pro-v3.1.html)
Основные особенности программы:
• Контролирует и отлаживает все исходящие запросы HTTP от браузера (или любой другой отобранная программы) и получает ответы от сервера.
• Прослеживает полную магистраль и содержание данных HTTP запросов и ответов.
• Ловит автоматическую переадресацию браузеров.
• Отслеживает запросы от всех установленных дополнений (Flash, ActiveX и т. п.).
• Анализирует одни и те же страницы во всех современных браузерах одновременно.
• Измеряет размер и время загрузки ваших веб-страниц, чтобы оптимизировать работу вашего веб-узла.
• Рассматривайте gzip-ed содержимое.
• Посматривает информацию, предоставляемую каждым веб-навигатором или любой программой, когда вы посещаете сайт.
("3") • Анализирует, как работают другие сайты, какие у них особенности.
• Покажет то, как работает HTTP (полезна в случае программирования и сетевого проекта).
рис. 1 показан интерфейс программы
Описывать программу и её функции в данной курсовой мы не будем. Воспользуемся только её основными окнами, в которых описываются наши http-запросы.
Get.
Метод GET служит для получения любой информации, идентифицированной URI-Запроса. Если URI - Запроса ссылается на процесс, выдающий данные, в качестве ответа будут выступать данные, сгенерированные данным процессом, а не код самого процесса (если только это не является выходными данными процесса).
Итак рассмотрим простейший пример HTTP запроса. Если в адресном окошке браузера мы наберем адрес http://*****, то браузер определит IP адрес сервера ***** и пошлет ему на 80-й порт такой HTTP запрос:
Рис. 2 запрос от клиента GET
Запрос передается в незашифрованном текстовом виде. Самая главная часть запроса расположена в первой строке: Это тип запроса (GET), URL адрес запрашиваемого документа и версия HTTP протокола (HTTP/1.1). Далее перечисляются параметры запроса. Каждая строка соответствует одному параметру. В начале строки идет имя параметра, затем двоеточие и значение параметра. Смысл параметров интуитивно ясен, однако опишем основные из них: Accept - тип данных, которые может принять браузер (в кодировке MIME). Accept-Language - предпочтительный язык, на котором браузер хочет принять данные. User-Agent - тип программы, которая отослала запрос. Host - DNS(или IP) имя хоста к которому адресован запрос. Cookie - кукисы (данные, которые были сохранены сервером на локальном диске клиента, при посещении данного хоста прошлый раз). Referer - хост, со странички которого мы отсылаем запрос. Так например если мы находимся на странице http://*****, и нажимаем там ссылку http://*****, то запрос будут отправлен хосту *****, а поле запроса referer будет содержать имя хоста *****.
Post.
Метод POST используется для запроса сервера, чтобы тот принял информацию, включенную в запрос, как субординантную для ресурса, указанного в Строке Статус в поле URI-Запроса. Метод POST был разработан, чтобы была возможность использовать один общий метод для следующих функций:
-Аннотация существующих ресурсов
-Добавление сообщений в группы новостей, почтовые списки или подобные группы статей
-Доставка блоков данных процессам, обрабатывающим данные
-Расширение баз данных через операцию добавления
Запрос POST очень похож на GET, с той лишь разницей что данные в запросе POST передаются отдельно от самого собственно заголовка запроса. Так приведенный выше пример в варианте POST имеет вид:
Рис. 3 запрос клиента POST
("4") Как мы видим данные о логине и пароле передаются отдельно в теле запроса. Тело запроса должно отделяться от заголовка пустой строкой. Если сервер встречает пустую строку в POST запросе, то все что идет далее он считает телом запроса (передаваемыми данными). Отметим следующее: формат данных в теле POST запроса произволен. Несмотря на то, что чаще всего применяется CGI формат, он не обязателен. Кроме того POST запрос не требует наличия тела запроса, и может передавать данные также и через URL.
Помимо запросов GET и POST существуют и другие, например TRACE, PUT. Но они используются редко, и мы не будем на них останавливаться.
2.2 HTTP ответ
Структура ответа
После получения и интерпретации запроса, сервер посылает ответ в соответствии со следующей формой:
Ответ = Простой-Ответ | Полный-Ответ
Простой-Ответ = [ Содержание-Ответа ]
Полный-Ответ = Строка-Статус
*( Общий-Заголовок | Заголовок-Ответа | Заголовок-Содержания) CRLF
[ Содержание-Ответа ]
Простой-Ответ должен посылаться только в ответ на HTTP/0.9 Простой-Запрос, или в том случае, если сервер поддерживает только ограниченный HTTP/0.9 протокол. Если клиент посылает HTTP/1.0 Полный-Запрос и получает ответ, который не начинается со Строки-Статус, он должен предполагать, что ответ сервера представляет собой Простой-Ответ, и обрабатывать его в соответствии с этим. Следует заметить, что Простой-Ответ состоит только из запрашиваемой информации (без заголовков) и поток данных прекращается в тот момент, когда сервер закрывает сеанс связи.
Рис. 4 Ответ сервера на запрос клиента
Строка Статус
Первая строка Полного-Запроса является Строкой-Статус, состоящей из версии протокола, за которой следует цифровой код статуса и ассоциированное с ним текстовое предложение. Все элементы Строки-Статус разделены пробелами. Не разрешены символы CR и LF, за исключением завершающей последовательности CRLF.
Строка-Статус = Версия-HTTP SP Статус-Код SP Фраза-Об'яснение.
Так как Строка-Статус всегда начинается с версии протокола "HTTP/" 1*ЦИФРА "." 1*ЦИФРА (например HTTP/1.0), существование этого выражения рассматривается как основное для определения того, является ли ответ Простым-Ответом, или Полным-Ответом.
Статус-Код и пояснение к нему
Элемент Статус-Код представляет собой 3-х цифровой целый код, идентифицирующий результат попытки интерпретации и удовлетворения запроса. Фраза-Об'яснение, следующая за ним, предназначена для краткого текстового описания Статус-Кода. Статус-Код нацелен на то, чтобы его использовала машина, а Фраза-Объяснение предназначена для человека. Клиент не обязан исследовать и выводить на экран Фразу-Объяснение.
Первая цифра Статус-Кода предназначена для определения класса ответа. Последние две цифры не выполняют никакой категоризирующей роли. Существует 5 значений для первой цифры:
("5") 1xx: Информационный - Не используется, но зарезервирован для использования в будущем
2xх: Успех - Запрос был полностью получен, понят, и принят к обработке.
3xx: Перенаправление - Клиенту следует предпринять дальнейшие действия для успешного выполнения запроса. Необходимое дополнительное действие иногда может быть выполнено клиентом без взаимодействия с пользователем, но настоятельно рекомендуется, чтобы это имело место только в тех случаях, когда метод, использующийся в запросе безразличен (GET или HEAD).
4xx: Ошибка клиента - Запрос, содержащий неправильные синтаксические конструкции, не может быть успешно выполнен. Класс 4xx предназначен для описания тех случаев, когда ошибка была допущена со стороны клиента. Если клиент еще не завершил запрос, когда он получил ответ с Статус-Кодом - 4xx, он должен немедленно прекратить передачу данных серверу. Данный тип Статус-Кодов применим для любых методов, употребляющихся в запросе.
5xx: Ошибка Сервера - Сервер не смог дать ответ на корректно поставленный запрос. В этих случаях
Поля Заголовок-Ответа
Поля заголовка ответа позволяют серверу передать дополнительную информацию об ответе, которая не может быть внесена в Строку-Статус. Эти поля заголовков не предназначены для передачи информации о содержании ответа, передаваемого в ответ на запрос, но там может быть информация собственно о сервере.
Тело ответа
Как видно из рисунка, сервер посылает клиенту уже сам html-код, который будет обработан браузером для удобного пользования человеком (пользователем). Описывать этот код мы не будем. Описание html-кода можно найти в любом учебнике по web-программированию.
Рис. 5 Тело ответа
2.3 Итог HTTP
Большинство протоколов предусматривают установление TCP-сессии, в ходе которой один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой авторизации. HTTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (не анонимного) доступа в HTTP используются cookies; причём такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.
При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. HTTP перед тем, как передать сами данные, передаёт в заголовке строчку «Content-Type: тип/подтип», позволяющую клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов — в простейшем случае картинки в разных форматах).
Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.
Перечисленные особенности HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это превратило Internet из «академической игрушки» в «коммерческий сервис»: появились компании, основным полем деятельности которых стало предоставление доступа в Internet (компании-провайдеры) и создание сайтов.
3.0 Протокол HTTPS.
Любому пользователю Интернета хорошо известна аббревиатура HTTP. Чаще всего она попадается нам на глаза, в каталогах со ссылками или в адресной строке наших браузеров. Данная аббревиатура обозначает один из основных, используемых в Интернете, протоколов обмена информацией, а именно Hypertext Transfer Protocol, или протокол передачи гипертекста, того самого текста, с помощью которого построена вся информационная инфраструктура Интернета. Благодаря такой популярности и распространенности, аббревиатура HTTP, попадается и узнается сплошь и рядом, но вот весьма похожая на нее, и по виду, и по сути, аббревиатура HTTPS, почему-то гораздо менее известна и узнаваема. Основной причиной к тому, наверно является, уж слишком большая похожесть - разница составляет всего одну латинскую букву. Но, первое впечатление, как всегда, довольно обманчиво. Именно эта латинская буква "s" превращает обычный, не защищенный канал передачи данных в Интернете, в засекреченный или защищенный; и при более пристальном разглядывании URL-ов, посещаемых нами ресурсов, встречается не так уж и редко.
HTTP и HTTPS
Попытки разработать универсальный сетевой протокол, способный обеспечить надлежащий уровень безопасности при работе в Интернет, предпринимались достаточно давно, и достаточно большим количеством различных фирм и организаций. HTTP протокол предлагал достаточно простой, парольный способ идентификации того или иного пользователя. В момент соединения с сервером, пользователь вводил пароль, пароль передавался серверу в открытом, не зашифрованном виде, и далее, проверив соответствие пароля и имени пользователя, сервер открывал или не открывал затребованное соединение. Далее, по мере развития Интернета, было создано несколько различных безопасных протоколов. Официальный протокол, разработку которого спонсировала IETF, назывался Secure HTTP (SHTTP), (http://www. faqs. org/rfcs/rfc2660.html). Помимо него, разрабатывались, и были созданы, еще несколько не официальных проектов, один из которых, под названием SSL (Secure Sockets Layer), созданный Netscape, получил большую популярность и широкое распространение. Правда, не смотря на свою популярность, SSL не является официальным Интернет стандартом, а потому, подробную информацию о нем, можно найти на сайте разработчиков Netscape.
("6") HTTPS — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Эта система была разработана компанией Netscape Communications Corporation, чтобы обеспечить аутентификацию и защищённое соединение. HTTPS широко используется в мире Веб для приложений, в которых важна безопасность соединения, например, в платежных системах.
Протокол SSL (secure socket layer) был разработан фирмой Netscape, как протокол обеспечивающий защиту данных между сервисными протоколами (такими как HTTP, NNTP, FTP и т. д.) и транспортными протоколами (TCP/IP). Часто для него используется аббревиатура HTTPS. Именно эта латинская буква "s" превращает обычный, не защищенный канал передачи данных в Интернете по протоколу HTTP, в засекреченный или защищенный,
SSL в действии
Главным назначением SSL-протокола, является обеспечение приватного и надежного способа обмена информацией между двумя удаленно взаимодействующими приложениями. Протокол реализуется в виде двухслойной (многослойной) среды, специально предназначенной для безопасного переноса секретной информации, через не засекреченные каналы связи. В качестве первого слоя, в такой среде используется некоторый надежный транспортный протокол; TCP к примеру. По слову "транспортный", не трудно догадаться, что TCP берет на себя функции "несущей", и в дальнейшем, становится извозчиком, для всех лежащих выше слоев (протоколов). Вторым по счету слоем, накладываемым на TCP, является SSL Record Protocol. Вместе, эти два слоя, TCP и SSL Record Protocol, формируют своеобразное ядро SSL. В дальнейшем, это ядро становится первичной герметизирующей оболочкой, для всех последующих более сложных протокольных инфраструктур. В качестве одной из таких структур, используется SSL Handshake Protocol - позволяющий серверу и клиенту идентифицировать друг друга и согласовывать криптографические алгоритмы и ключи, перед тем как приложения, работающие на серверной и клиентской стороне, смогут начать передачу или прием информационных байтов в защищенном режиме.
Одним из не мало важных преимуществ SSL, является его полная программно-платформенная независимость. Протокол разработан на принципах переносимости, и идеология его построения, не зависит, от тех приложений, в составе которых он используется. Помимо этого, важно и то, что поверх протокола SSL, могут прозрачно накладываться и другие протоколы; либо для еще большего увеличения степени защиты целевых информационных потоков, либо, для адаптации криптографических способностей SSL под какую-нибудь другую, вполне определенную задачу.
Вы начинаете использовать SSL в тот момент, когда вводите в адресной 
строке своего браузера URL начинающийся с аббревиатуры HTTPS, рис. 6. В результате, вы подключаетесь к порту за номером 443, который для SSL обычно используется по умолчанию; для стандартного HTTP соединения, чаще всего
используется порт 80. В процессе подключения, браузер пользователя (в дальнейшем клиент), посылает серверу приветственное сообщение (hello message). В свою очередь сервер, также должен посылать клиенту свое приветственное сообщение. Приветственные сообщения, являются первичными, инициализирующими сообщениями и содержат информацию, используемую при дальнейшей настройке открываемого секретного канала. В общем случае, приветственное сообщение устанавливает четыре основных параметра: версия протокола, идентификатор сессии, способ шифрования, метод компрессии, а также, два специально сгенерированных случайных числа; и сервер, и клиент, генерируют такие числа независимо друг от друга, а затем, просто обмениваются ими друг с другом.
После получения приветственного сообщения от клиента, сервер отсылает свой сертификат, если таковой у него имеется. Также, при необходимости, сервер может послать и некое ключевое сообщение, например в случае отсутствии сертификата. Если сервер авторизирован (т. е. имеет соответствующий сертификат), он может потребовать и клиентский сертификат, если того потребует выбранный способ шифрования данных. После этого, производится еще ряд промежуточных обменных операций, в процессе которых, производится окончательное уточнение выбранного алгоритма шифрования, ключей и секретов, и далее, сервер посылает клиенту некое финальное сообщение, после чего обе стороны приступают к обмену зашифрованной информации.
На практике, процесс обмена ключами и сертификатами, иногда может занимать относительно много времени. С этой целью, часто предусматривается возможность повторного использования одних и тех же идентификационных данных. Бывают ситуации, когда после установления соединения с SSL-сервером, у пользователя появляется желание открыть еще одно окно браузера, и через него, осуществить еще одно подключение к тому же SSL-серверу. В этом случае, чтобы не повторять весь цикл предварительных обменных операций, браузер может отправить серверу идентификатор сессии предыдущего соединения, и если сервер примет этот идентификатор, весь набор шифровочных и компрессионных параметров, будет взят от предыдущего соединения. При этом по завершению передачи шифрованных данных, установленное SSL-соединение закрывается не сразу, а лишь по истечении некоторого времени.
3.1 Обзор SSL
Протокол SSL предоставляет "безопасный канал", который имеет три основные свойства:
Канал является частным. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа.
Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, в то время как клиентская - аутентифицируется опционно.
Канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC).
Не секрет, что можно без особых технических ухищрений просматривать данные, которыми обмениваются между собой клиенты и серверы. Был даже придуман специальный термин для этого - sniffer. А в связи с увеличением объема использования Интернета в коммерческих целях, неизбежно вставал вопрос о защите передаваемых данных. И пользователи не очень были бы рады, если номер их кредитной карточки, был бы перехвачен, каким-нибудь предприимчивым хакером по дороге к виртуальному магазину. И, в общем, появление такого протокола как SSL было вполне закономерным явлением. С одной стороны остаются все возможности сервисных протоколов (для программ-серверов), плюс к этому все данные передаются в зашифрованном виде. И разкодировать их довольно трудно. Следует отметить, что SSL не только обеспечивает защиту данных в Интернете, но так же производит опознание сервера и клиента (server/client authentication). В данный момент протокол SSL принят W3 консорциумом (W3 Consortium) на рассмотрение, как основной защитный протокол для клиентов и серверов (WWW browsers and servers) в сети Интернет.
На рисунке показаны закодированные данные, передаваемые между сервером и клиентом.
Использование SSL
Чаще всего, этот протокол используется в составе любого Интернет-ресурса, осуществляющего манипуляции с личными или финансовыми данными посещающих его пользователей Интернета. Чаще всего, это банки, Интернет-магазины или любые другие виртуальные места, в которых приходящие по своим делам пользователи, вынуждены передавать свои личные, и зачастую, секретные данные. Этого может потребовать и простая регистрация, и процедура оплаты какого-либо товара, или любая другая процедура, при которой пользователи вынуждены честно выдавать свои паспортные данные, PIN-ы и пароли. Если бы все жители земного шара являлись бы порядочными и честными людьми, необходимость бы в использовании SSL, отпала бы сама собой, за не надобностью, ведь защищать информацию было бы просто не от кого. Но, поскольку в реалии мы имеем несколько другое положение вещей, то приходится думать о том, как защитить передаваемую пользователем информацию от посягательств со стороны третьих лиц. Используя обычный HTTP протокол, мы передаем и получаем информацию в чистом, не зашифрованном виде. Таким образом, передаваемая нами информация, может быть легко перехвачена, и использована совершенно посторонним человеком. Помимо этого, существует и другая, на первый взгляд просто смешная угроза. Представьте, ваш банк расположен по адресу http://. Теперь представьте, что некий злоумышленник, регистрирует другой адрес, скажем http://, и создает на нем сайт, внешне похожий на сайт вашего банка. Эти адреса так похожи, что рано или поздно, вы наверняка ошибетесь, и случайно попадете не в банк, а на сайт злоумышленника. Ну а далее, схема примерно ясна - ваша персональная информация становится известна третьему лицу. Таким образом, появляются два довольно веских довода, первый, передаваемую информацию надо шифровать, и второй, мы должны быть уверены, что передаем информацию именно туда, куда нужно. Именно для решения этих двух вопросов и используется SSL.
«Ложка дегтя»
("7") SSL как таковой, теоретически, может обеспечить практически полную защиту любого Интернет соединения. Но, любая вещь в этом мире не существует в пустоте. Это означает, что для успешного функционирования SSL, кроме него самого, необходимы также и чисто программные средства, претворяющие технологию SSL в жизнь. Программы, так или иначе использующие SSL протокол, как ни странно, является порой самым уязвимым местом этой технологии. Именно из-за ошибок в этих программах, возможна почти полная потеря, всех, достигнутых после использования SSL щитов и заслонов. К таким программным инструментам, прежде всего, относятся активно используемые нами Интернет-браузеры.
Одним из самых показательных критериев уровня защиты, является размер используемых ключей. Чем больше этот размер, тем соответственно надежнее защита. Браузеры в основном используют три размера: 40, 56 и 128 бит, соответственно. Причем, 40-а битный вариант ключа недостаточно надежен. Таким образом, предпочтительнее использовать именно 128-ми битные ключи. Применительно к Internet Explorer-у от Microsoft, это означает загрузку дополнительного пакета (security pack). Так как интернациональные версии этого браузера, всегда снабжаются исключительно 40-а или 56-и битной защитой, а 128-ми битная защита, ставится только на североамериканские версии этого браузера (США, Канада). Для того чтобы установить, какой именно размер ключа используется в вашем браузере, в Netscape Navigator вам достаточно открыть подменю "Options/Security Preferences", а в Internet Explorer, подменю "Help/About".
Рис. 7 просмотр информации о шифре браузера
Но размер ключа, не будет играть решающий роли, если в защите браузера имеется внутренняя брешь. Сообщения об открытии таких брешей, в тех или иных браузерах, появляются с регулярными интервалами. Такая брешь напоминает открытую форточку в протапливаемой комнате - все тепло мгновенно выветривается. По этому поводу, уместно вспомнить случай произошедший с Netscape Navigator, в мае 2000 года. Тогда, один корейский студент обнаружил такую, довольно не приятную особенность, этого браузера. При попытке соединения с сервером, обладающим не годным сертификатом, с дальнейшим отказом от продолжения такого соединения, происходило следующее. Netscape, по ошибке, помещал этот сертификат в список годных, и соответственно, при последующем подключение уже не выдавал пользователю ни каких предупреждающих сообщений, спокойно подключаясь к этому, не вполне надежному, серверу
Но все эти и им подобные прорехи, не идут ни в какое сравнение с той угрозой, которую могут представлять для пользователя вовремя не отозванные сертификаты. Дело в том, что браузеры обычно поставляются с неким, вполне определенным набором действительных сертификатов, но автоматического механизма проверки этой годности по прошествии некоторого времени - не существует. Таким образом, возможно, что действие, того или иного, используемого вашим браузером сертификата, уже, давно кончилось; мог истечь срок годности, мог быть потерян контроль над личным ключом соответствующим этому сертификату и. т.д. В любом из этих случаев, сертификат автоматически отзывается, и помещается в специальный, так называемый revocation list, или список не годных сертификатов, создаваемый и обновляемый тем или иным сертификационным сообществом (CA). Теперь, если не удалить такой сертификат из вашего браузера, он по прежнему будет числиться как годный, со всеми вытекающими отсюда последствиями.
Следует заметить, что идея, заложенная в протоколе SSL безусловно, хороша. Хотя у нее есть и свои плюсы, и свои минусы, но в целом, этот протокол можно назвать одним из наиболее удачных решений проблемы защиты пользовательских данных при их распространении "открытым" каналом. Этот протокол вполне бы мог стать некой сетевой панацеей. Но, к сожалению, практика, показывает что идея это еще не решение. Без соответствующей практической составляющей, идея так и остается идеей, а потому, пользователи безусловно, должны помнить, что символ замка, появляющийся в строке состояния их Интернет-браузеров, еще не гарантия того, что все наши секреты и тайны находятся под действительно надежной защитой
3.2 Обмен данными по протоколу SSL
Преимуществом SSL является то, что он независим от прикладного протокола. Протоколы приложения, такие как HTTP, FTP, TELNET и т. д. могут работать поверх протокола SSL совершенно прозрачно. Протокол SSL может согласовывать алгоритм шифрования и ключ сессии, а также аутентифицировать сервер до того как приложение примет или передаст первый байт данных. Все протокольные прикладные данные передаются зашифрованными с гарантией конфиденциальности.
Наблюдать за диалогом между сервером и клиентом можно с помощью программы «EtherSnoop - Network Sniffer». Ссылка на программу: «http://www. *****/news/soft/index. php? t=%CC%EE%ED%E8%F2%EE%F0%E8%ED%E3%20%F1%E5%F2%E8»Программа работает как обычный пакетный сниффер. Который позволяет фиксировать все исходящие и входящие пакеты, в режиме реального времени. Программа имеет простой и понятный интерфейс с легкой навигацией в виде дерева, возможно просматривать содержимое пакетов в hex и текстовом виде, а также применение фильтров на отображение данных. Все данные могут быть сохранены в файл и загружены в программу позднее для более подробного изучения.
Рис. 8 Интерфейс программы EtherSnoop
Попробуем войти в защищенный канал по адресу https://*****. Как видим, в начале строки у нас вместо привычного «http», стоит «https». Как видно, используется 443 порт для отправки сообщений друг другу.
Рис 9 соединения с сервером
Протокол диалога SSL
Протокол диалога SSL имеет две основные фазы. Первая фаза используется для установления конфиденциального канала коммуникаций. Вторая - служит для аутентификации клиента.
Фаза 1
Первая фаза является фазой инициализации соединения, когда оба партнера посылают сообщения "hello". Клиент инициирует диалог посылкой сообщения CLIENT-HELLO. Сервер получает сообщение CLIENT-HELLO, обрабатывает его и откликается сообщением SERVER-HELLO.
К этому моменту, как клиент, так и сервер имеют достаточно информации, чтобы знать, нужен ли новый мастерный ключ. Когда новый мастерный ключ не нужен, клиент и сервер немедленно переходят в фазу 2.
Когда нужен новый мастерный ключ, сообщение SERVER-HELLO будет содержать достаточно данных, чтобы клиент мог сформировать такой ключ. Сюда входит подписанный сертификат сервера, список базовых шифров (см. ниже), и идентификатор соединения (последний представляет собой случайное число, сформированное сервером и используемое на протяжении сессии). Клиент генерирует мастерный ключ и посылает сообщение CLIENT-MASTER-KEY (или сообщение ERROR, если информация сервера указывает, что клиент и сервер не могут согласовать базовый шифр).
("8") Здесь следует заметить, что каждая оконечная точка SSL использует пару шифров для каждого соединения (т. е. всего 4 шифра). На каждой конечной точке, один шифр используется для исходящих коммуникаций и один - для входящих. Когда клиент или сервер генерирует ключ сессии, они в действительности формируют два ключа, SERVER-READ-KEY (известный также как CLIENT-WRITE-KEY) и SERVER-WRITE-KEY (известный также как CLIENT-READ-KEY). Мастерный ключ используется клиентом и сервером для генерации различных ключей сессий.
Наконец, после того как мастерный ключ определен, сервер посылает клиенту сообщение SERVER-VERIFY. Этот заключительный шаг аутентифицирует сервер, так как только сервер, который имеет соответствующий общедоступный ключ, может знать мастерный ключ.
Фаза 2
Вторая фаза является фазой аутентификации. Сервер уже аутентифицирован клиентом на первой фазе, по этой причине здесь осуществляется аутентификация клиента. При типичном сценарии, серверу необходимо получить что-то от клиента, и он посылает запрос. Клиент пришлет позитивный отклик, если располагает необходимой информацией, или пришлет сообщение об ошибке, если нет. Эта спецификация протокола не определяет семантику сообщения ERROR, посылаемого в ответ на запрос сервера (например, конкретная реализация может игнорировать ошибку, закрыть соединение, и т. д. и, тем не менее, соответствовать данной спецификации). Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация терпит неудачу, сервер посылает сообщение ERROR.
Раз партнер послал сообщение finished он должен продолжить воспринимать сообщения до тех пор, пока не получит сообщение finished от партнера. Как только оба партнера послали и получили сообщения finished, протокол диалога SSL закончил свою работу. С этого момента начинает работать прикладной протокол.
На рисунке представлен SSL диалог.
Рис. 10 Алгоритм работы SSL
Ниже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. В этих примерах представлены два участника диалога: клиент (С) и сервер (S). Если что-то помещено в фигурные скобки, например, "{нечто}key", это означает, что “нечто” зашифровано с помощью ключа "key".
Таблица 1. При отсутствии идентификатора сессии
Client-hello | C ® S: | challenge, cipher_specs |
server-hello | S ® C: | connection-id, server_certificate, cipher_specs |
client-master-key | C ® S: | {master_key}server_public_key |
client-finish | C ® S: | {connection-id}client_write_key |
server-verify | S ® C: | {challenge}server_write_key |
server-finish | S ® C: | {new_session_id}server_write_key |
("9") Теперь рассмотрим практически наш диалог. Мы будем выступать в качестве клиента с ip адресом 10.10.3.166, а Сервер как видно из рисунка имеет адрес 93.186.227.126.
Рис. 11 Диалог клиента с сервером
Первые 6 сообщений диалога, похожи на диалог из таблицы 1 и это значит, что у нас отсутствует идентификатор сессии.
Справа вид сообщения в шестнадцатеричном виде. Сообщения можно изменять и переотправлять.
Цифровые сертификаты
Это подводит нас к обсуждению цифровых сертификатов, играющих важную роль в SSL. Цифровые сертификаты в основном служат двум целям:
установить личность владельца;
сделать доступным первичный ключ владельца.
Цифровой сертификат выпускается проверенной полномочной организацией - источником сертификатов (certificate authority - CA) и выдается только на ограниченное время. После истечения срока действия сертификата его необходимо заменить. Протокол SSL использует цифровые сертификаты для обмена ключами, аутентификации серверов и, при необходимости, аутентификации клиентов.
Рис. 12 предложение на подписку сертификата
Цифровой сертификат содержит следующие фрагменты информации о личности владельца сертификата и источнике сертификатов:
полное (уникальное) имя владельца сертификата;
публичный ключ владельца;
дата выдачи цифрового сертификата;
дата окончания действия сертификата;
полное (уникальное) имя издателя (источника сертификата);
цифровая подпись издателя.
Подключение по SSL всегда инициируется клиентом вызовом URL-адреса, начинающегося с https:// вместо http://.
("10") Как только мы зашли на страницы, нас сервер просил «подписать» сертификат, соглашаясь, мы уже можем спокойно заходить на сервер.
Сертификат примерно выглядит так:
Рис. 13 Сертификат
Просматривая и изучая диалог, можно увидеть, что действительно, сервер отправляет именно этот сертификат, можно посмотреть наше закодированное сообщение в шестнадцатеричном виде и можно увидеть схожесть.
Рис. 14 пересылаемый сертификат на клиента
Более простой и ясный алгоритм такой:
Представьте себе, что есть два человека, которые общаются посредством Интернета и соответственно не видят друг друга. И лишены возможности, узнать, о том кто же его абонент. Их имена - Алиса и Боб. Допустим Алисе надо, узнать действительно она разговаривает с Бобом или нет. В этом случае диалог может выглядеть следующим образом: Алиса отправляет Бобу случайное сообщение. Боб шифрует его с помощью своего приватного ключа и отправляет его Алисе. Алиса дешифрует это сообщение (с помощью публичного ключа Боба). И сравнив это сообщение с посланным, может убедиться в том, что его действительно послал Боб. Но на самом деле со стороны Боба не очень удачная идея шифровать сообщение от Алисы с помощью своего приватного ключа. И возвращать его. Это аналогично подписи документа, о которой Боб мало что знает. С такой позиции Боб должен сам придумать сообщение. И послать его Алисе в двух экземплярах. В первом сообщение передается открытым текстом, а второе сообщение зашифровано с помощью приватного ключа Боба. Такое сообщение называется message digest. А способ шифрования сообщения с помощью своего приватного ключа - цифровой подписью (digital signature).
Теперь закономерно встает вопрос о том, каким образом распространять свои публичные ключи. Для этого (и не только) была придумана специальная форма - сертификат (certificate). Сертификат состоит из следующих частей: Имя человека/организации выпускающего сертификат. Для кого был выпущен данный сертификат (субъект сертификата). Публичный ключ субъекта. Некоторые временные параметры (срок действия сертификата и т. п.). Сертификат подписывается приватным ключом человека (или огрганизации), который выпускает сертификаты. Организации, которые производят подобные операции называются Certificate authority (CA). Если в стандартном Web-клиенте (web-browser), который поддерживает SSL, зайти в раздел security, то там можно увидеть список известных организаций, которые подписывают сертификаты. С технической стороны, создать свою собственную CA достаточно просто. Но против этого могут действовать скорее юридические препятствия.
Теперь рассмотрим, каким образом происходит обмен данными в Интернете. Воспользуемся все теми же действующими лицами.
Алиса: привет.
Боб: привет, я Боб (выдает свой сертификат).
Алиса: а ты точно Боб?
Боб: Алиса я Боб. (Сообщение передается два раза, один раз в открытую, второй раз, зашифрованный с помощью приватного ключа Боба).
Алиса: все нормально, ты действительно Боб. (И присылает Бобу секретное сообщение, зашифрованное с помощью публичного ключа Боба).
Боб: А вот и мое сообщение (посылает сообщение, которое было зашифровано с помощью секретного ключа, например того же шифрованного сообщения Алисы).
Поскольку Боб знает сообщение Алисы, потому что он владеет приватным ключом и Алиса знает, что было в том сообщении. Теперь они могут использовать симметричный шифровальный алгоритм (где в качестве секретного ключа выступает сообщение Алисы) и безбоязненно обмениваться шифрованными сообщениями. А для контроля над пересылкой сообщений (от случайного/преднамеренного изменения) используется специальный алгоритм - Message Authentication Code (MAC). Довольно распространенным является алгоритм MD5. Обычно, и сам MAC-code так же шифруется. В связи с этим достоверность сообщений повышается в несколько раз. И внести изменения в процесс обмена практически невозможно.
4.0 Вывод
Мы описали основы протоколов HTTP и HTTPS. Для доступа к страницам, защищённым протоколом SSL, в URL вместо обычного префикса http, как правило, применяется префикс https (порт 443), указывающий на то, что будет использоваться SSL-соединение.
("11") Протокол SSL обеспечивает целостность и конфиденциальность обмена данными между двумя общающимися приложениями, использующими TCP/IP. Данные, перемещающиеся между клиентом и сервером, шифруются симметричным алгоритмом. Увидели разницу в диалоге этих двух протоколов.
Рис. 15 ответ сервера клиенту. Справа по протоколу HTTP, слева по HTTPS
В правом рисунке показан обычный ответ сервера на запрос клиента «GET».Ответ заключается в выдаче клиенту html кода с использованием JavaScript и PHP.
Левый рисунок показывает уже закодированное сообщение, с использованием ключей, которое расшифровать будет не легко.
Какие преимущества дает использование SSL?
Почему это так важно? Безопасная и эффективная передача данных по открытым коммуникационным каналам - это критический компонент обеспечения функционирования современной ИТ-системы, и протокол SSL позволяет обеспечить эту безопасность. Однако подключение SSL к среде ISC может оказаться сложной и трудоемкой задачей. В чем сложность этой задачи? Вопрос безопасности данных в среде Web-приложений, подобных среде Integrated Solutions Console, может показаться немного размытым для новичков, потому что безопасность ИТ сама по себе - крайне широкая область, охватывающая много различных аспектов в открытых коммуникационных сетях.
5.0 Список используемой литературы:
1. Прикладная криптография. /Б. Шнайер. - М.: Издательство ТРИУМФ,2002.
2. Основы криптографии: Учебное пособие. /, , Кузьмин А. В. - М.: Гелиос, 2001.
3. http://book. *****
4. http://oradb1.jinr. dubna. su/Netscape/MISC/SSL. htm
5. http://kunegin. *****/ref5/ssl/
6. http://delphiworld. *****/base/ssl_protocol. html
7. http://www. /developerworks/ru/library/ac-iscssl1/index. html
8. http://*****/
9. http://www. *****/software/1272/ (программы и описание к
ним)
11. http:///docs/manuals/security/sslin/contents. htm
12. http://. ru/docs/security/s23.html
("12") 13. http://ru. wikipedia. org/
preview_end()
