На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

ОСНОВНЫЕ НОВОВВЕДЕНИЯ S-HTTP

Как уже отмечалось, в протоколе S-HTTP предусмотрено несколько механиз­мов обеспечения безопасности клиентов и серверов HTTP. Все они разработаны для того, чтобы удовлетворить требованиям различных приложений Web. Более того, в S-HTTP клиенту и серверу предоставляются равные возможности (т. е. запросы и ответы обрабатываются одинаковым образом; кроме того, одинаково обрабатываются и параметры обеих сторон). Однако это ничуть не мешает под­держивать модель транзакций HTTP. Протокол позволяет поддерживать различ­ные режимы и методы шифрования, а полная его установка позволяет изменять процесс шифрования в зависимости от запросов клиента.
Можно внедрить в сервер или клиент S-HTTP неограниченное количество стан­дартов шифрования информации (включая PKCS-7 и РЕМ). В этом протоколе предусмотрена поддержка взаимодействия различных реализаций, а также пол­ная совместимость с HTTP. Таким образом, клиенты, работающие с протоко­лом S-HTTP, могут сообщаться с серверами, работающими по протоколу HTTP, и наоборот. Однако в подобных транзакциях не будут использоваться встроен­ные в S-HTTP возможности защиты информации.
В S-HTTP от клиента не требуется наличие сертификата открытого ключа (или самого ключа — в зависимости от настройки сервера). Вместо этого в протоколе используется режим работы с симметричным одноразовым ключом. Этот режим очень важен потому, что с его помощью пользователи могут насладиться всеми преимуществами нового протокола, не обладая при этом сертификатом. Однако это не значит, что в протоколе нет поддержки цифровых сертификатов — просто они не обязательны. Мы подробнее поговорим об этом в следующей главе.
В S-HTTP введены средства защиты сквозных транзакций. Новые средства на­много отличаются от механизмов идентификации HTTP. Для создания безопас­ной транзакции в протоколе HTTP требуется, чтобы сервер особым образом ответил на запрос клиента. В этом случае сервер может «заставить» клиента начать безопасную транзакцию (обычно для этого используется информация, расположенная в анкере HTTP). Серверы могут использовать этот метод для поддержки шифрования форм без использования шифрования и обеспечения безопасности на всем сервере.
Алгоритм шифрования и режимь цифровой подписи s-http
Протокол S-HTTP обладает достаточно гибкими алгоритмами шифрования, ре­жимами и параметрами. Для того чтобы клиент и сервер могли договориться об используемых режимах безопасной транзакции (вроде использования в запросах и ответах цифровых подписей, шифрования или обоих этих методов), в S-HTTP
есть специальная возможность согласования. Кроме того, в новом протоколе есть возможность согласования алгоритмов шифрования (для создания цифровых подписей - RSA или DSA; для шифрования - DES или RC2 и т. д.) и сертифи­катов (вроде запроса на создание подписи при помощи «сертификата Mastercard»). В S-HTTP не предусматривается какой-либо конкретной модели. Наоборот, пред­полагается, что каждая из сторон может обладать целым набором сертификатов.
В защита сообщений обеспечивается тремя методами: цифровая подпись, идентификация сообщения и шифрование передаваемой информации. Все они могут использоваться по отдельности и в различных комбинациях (а могут не использоваться вообще). Кроме того, в S-HTTP предусмотрены механизмы управ­ления несколькими ключами, обмен открытыми ключами и распространение билетов Kerberos. В частности, протокол предоставляет возможность использовать заранее установленный симметричный одноразовый ключ. С его помощью можно пересылать информацию пользователям, не имеющим набора ключей. Вдоба­вок в S-HTTP предусмотрена возможность проверки состояния соединения.
ЦИФРОВЫЕ подписи и S-HTTP
Для поддержки цифровых подписей в S-HTTP используется один из видов стандарта PKCS-7 - SignedData (или SignedAndEnvelopedData).Если сервер запраши­вает цифровую подпись, клиент может поместить соответствующий сертификат в сообщение или ожидать, что сервер сам разыщет его. Обратите внимание: в S-HTTP строго запрещено использование «самодельных» сертификатов (создан­ных и подписанных самим пользователем, а не ведомством сертификатов). Как сервер отнесется к подобному сертификату, зависит от его настройки. Напри­мер, многие сайты, поддерживающие работу с банками, могут потребовать от пользователя приобрести сертификат у компании третьей стороны. Именно та­ким образом эти сайты пытаются защититься от «мнимых» личностей. В любом случае, все подписи сообщений совместимы с PKCS-7.
ОБМЕН КЛЮЧАМИ и ШИФРОВАНИЕ
Как уже говорилось, сервер S-HTTP зашифровывает каждое послание. Если к серверу одновременно присоединено несколько клиентов (что, согласитесь, не такая уж редкость в Web), то ему придется одновременно обрабатывать и зашиф­ровывать десятки сообщений. Как вы усвоили из предыдущих глав, шифрова­ние с открытым ключом занимает гораздо больше времени, чем шифрование с единым ключом. Поэтому для обеспечения нормальной производительности в S-HTTP определены два механизма передачи ключей: обмен ключами во время передачи и использование внешних ключей. В первом случае сервер зашифро­вывает личный ключ при помощи открытого ключа клиента и пересылает его клиенту. Как показано в главе 4, получателем такого сообщения может быть только тот, у кого есть личный ключ. После того как получатель расшифрует ключ, вся дальнейшая информация будет зашифрована при помощи этого клю­ча. Обмен ключами во время передачи схематично показан 15.
Во втором случае (который больше подходит для корпоративных сетей) для по­лучения доступа к S-HTTP-серверу отправитель должен зашифровать сообщение при помощи заранее условленного одноразового ключа. При этом в зависимос­ти от вида передаваемых данных информация о ключе помещается в одной из строк заголовка запроса или заголовка объекта (6). Кроме того, пользо­ватели могут воспользоваться билетами Kerberos. О них будет рассказано в гла­ве 10. показан обмен при помощи внешних ключей.
ЦЕЛОСТНОСТЬ ДАННЫХ и ИДЕНТИФИКАЦИЯ ОТПРАВИТЕЛЯ
Как уже говорилось, в S-HTTP реализована возможность проверки целостности данных и идентификации отправителя сообщения. Для этого в протоколе ис­пользуется метод цифровой подписи (в S-HTTP он называется кодом идентифи­кации сообщения [MAC - Message Authentication Code]). Приложения S-HTTP вычисляют MAC как смешанное с ключом значение: сначала вычисляется сме­шанное значение документа, а затем оно зашифровывается при помощи сим­метричного ключа. Для размещения MAC в файле можно воспользоваться раз­личными методами (вроде Kerberos или ручного внедрения). Для работы с MAC использование шифрования с открытым ключом не требуется.
Механизм MAC также позволяет общающимся сторонам проводить идентифика­цию сообщений без использования цифровых сертификатов. Разработчики S-НТТРбыли уверены, что создание подписей транзакций в будущем будет ши­роко использоваться всеми пользователями сети. Поэтому они и включили в протокол механизм MAC. Однако этот механизм не запрещает использовать для обмена ключей шифрование с открытым ключом. Таким образом, протокол S-HTTP окажется очень полезным там, где нужно обязательно проводить иден­тификацию клиента (например, при управлении доступом).
СОСТОЯНИЕ ТРАНЗАКЦИЙ
В S-HTTP предусмотрен простой механизм проверки состояния передачи (transmission freshness). С его помощью сервер может проверить, кем прислано
сообщение. Таким образом, можно отслеживать ситуации, когда вместо сооб­щения пользователя серверу приходит скопированное хакером сообщение. По­добное явление происходит в том случае, если хакер скопировал пакет, взломал зашифрованное сообщение и послал его от имени клиента. Кроме того, в но­вом стандарте HTTP-заголовок сообщения Date может использоваться в качестве индикатора состояния (однако при этом требуется, чтобы установка S-HTTP
предусматривала возможность работы с различными часовыми поясами, компью­терами с неправильно установленным системным временем и т. д.).
ИНКАПСУЛЯЦИЯ
Сообщение состоит из строки запроса или состояния, за которой следует набор заголовков RFC-822, а за ним - зашифрованное тело сообщения. Телом сообщения может быть другое сообщение S-HTTP, сообщение HTTP или просто какие-нибудь данные. Для совместимости с HTTP запросы и ответы в
S-HTTP отделяются друг от друга при помощи указателя протокола. Другими словами, вместо стандартной строки «НТТР I. I»заголовок MIME содержит строку «Secure-HTTP/l.I». Однако остается вероятность того, что будущие реализации протокола HTTP будут обладать всеми необходимыми средствами обеспечения
безопасности данных и использование S-HTTP станет ненужным. Для этого за­головок S-HTTP инкапсулируется по всем правилам HTTP — если какое-либо из приложений не распознает его, то он попросту будет проигнорирован.
ЗАПРОСА S-HTTP
Запросы S-HTTP построены по той же схеме, что и запросы HTTP (6). Специально для запросов HTTP разработчики нового протокола ввели метод Secure. Все безопасные запросы (использующие протокол S-HTTP версии 1.1) должны содержать в заголовке MIME следующую строку:
Secure * Secure-HTTP/1.1
Безопасный сервер должен быть независимым от регистра. В этой строке «звез­дочка» служит в качестве заменителя символов. Вместо нее клиенты, работаю­щие с сервером-посредником, должны вставить URL запроса; как минимум, они должны обеспечить расположенную в URL секцию хоста и ссылку на порт -все эти действия строго регламентированы в HTTP. Например, полная версия
безопасного запроса для сервера-посредника (для доступа к безопасному Web-
серверу) должна выглядеть следующим образом:
Secure http://www.secure-server.com:80/ Secure-HTTP/1.1
Обратите внимание на то, что, в отличие от SSL, в S-HTTP в качестве стандартно­го порта используется порт с номером 80. Как уже упоминалось (6), этот же порт является стандартным и для HTTP.
СТРОКА ОТВЕТА
Как уже упоминалось, броузер должен тщательно просматривать ответы серве­ра. В главе 6 говорилось о том, что при успешной обработке запроса сервер посылает ответ 200 ОК. В S-HTTP первая строка ответа сервера должна выгля­деть следующим образом:
Secure-HTTP/l. 1 200 OK
В этом протоколе первая строка ответа также является индикатором того, успешно ли прошел запрос. Однако если в качестве ответа сервер будет всегда посылать эту строку, то броузеру не придется анализировать причины ошибки. Тем са­мым сервер лишает хакера возможности получить информацию о причине запре­та доступа к безопасному серверу. Таким образом, безопасный сервер должен всегда посылать код об успешной обработке запроса.
СТРОКИ ЗАГОЛОВКА
В S-HTTP определено несколько новых строк заголовка сообщения. Все они являются необязательными, за исключением строк Content-Type и Content-Privacy-
Domain. Тело сообщения отделяется от строк заголовка при помощи двух пар символов cr1 -г. Все данные и строки заголовка являются нечувствительными к регистру (если не указано обратное). Визуальные разделители служат для разде­ления заголовка и тела сообщения. Однако это правило может быть нарушено в том случае, если некоторое поле потребует использования свободных строк (не­скольких символов CR). Как и в HTTP, для более удобного представления тек­ста можно разбивать длинные строки заголовка на несколько строк.
ДОПУСТИМЫЕ типы СОДЕРЖАНИЯ СООБЩЕНИЯ
Итак, представим, что сервер (или броузер) расшифровал тело сообщения и получил содержание исходного (незашифрованного) сообщения. В обычных условиях содержание сообщения рассматривается как сообщение HTTP 1.0. Если сообщение и в самом деле является сообщением HTTP 1.0, то в нем будет при­сутствовать следующая строка:
Content-Туре: application/http
Пара application/http зарегистрирована IANA как один из типов MIME. Для обеспечения обратной совместимости в S-HTTP используется пара application/ x-http. Однако полученное содержание может использовать другой тип, который должен быть четко- определен строкой заголовка Content-Type. Итак, если тип содержания отличается от или x-http, то броузер (или сервер) должен ис­пользовать поля заголовка для последнего (наиболее глубоко инкапсулированно­го) сообщения HTTP. Обратите внимание: так как HTTP-сообщение (из кото­рого сервер или броузер извлекают заголовки) зашифровано, то в нем можно
спокойно размещать конфиденциальную информацию.
Таким образом, механизм Content-Type полезен для передачи расширенных дан­ных (в особенности заранее подписанных) и не требует при этом изменения
заголовков HTTP.
ЗАГ0Л0В0К ' PREARRANGED Key-Info
В этой строке заголовка содержится информация о ключе, заранее установлен­ном без использования средств шифрования (например, при помощи флоппи-диска). Строка PrearrangedKey-Info обеспечивает возможность обмена ключа во время передачи. Однако с ее помощью можно выбрать и другой механизм, та­кой как список одноразовых (one-time) ключей.
При использовании заранее установленного внешнего ключа не забывайте о том, что в определено три метода обмена ключами: во время передачи,
и вне передачи.
Элементы <inband> и <Ы> указывают, что общающиеся стороны обменялись ключом заранее (при помощи заголовка соответствующего метода).
Обмен ключами вне передачи (указываемый элементом подразумева­ет, что агенты обладают внешним доступом к материалам ключа (например, при помощи базы данных или непосредственного ввода с клавиатуры). Синтаксис этой строки заголовка приведен ниже:
Prearranged-Key-Info: <Hdr-Cipher>','<CoveredDEK>1,
'<CoverKey-ID> <CoverKey-ID> := <метод>','<имя-ключа> <CoveredDEK> : = <шестнадцатиричное-значение> <метод>  := 'inband'   |   ^^'<kv> | 'outband' <kv> := '4'   I '5'
В таблице 7.1 приведены все остальные параметры этой строки.
Имя элемента_Описание_
<Hdr-Cipher> Содержит имя блока шифра, при помощи которого
отправитель зашифровывает одноразовый ключ.
< Covered DEK^ Этот элемент представляет имя защищенного ключа
Data Exchange Key (его также называют ключом транзакции), с помощью которого передающий хост зашифровывает инкапсулированное сообщение. Для каждой транзакции отправитель должен сгенерировать отдельный ключ DEK, Передающий хост должен зашифровать каждую транзакцию при помощи одноразового ключа, а затем преобразовать результат в шестнадцатиричный формат. Во избежание использования одинаковых имен хост и порт должны ._поддерживать различные пространства имен ключей.
Нестандартные параметры строки заголовка Prearranged-Key-Info.
ЗАГОЛОВОК MA С-Info
Как уже отмечалось, модель транзакций s-HTTP поддерживает создание циф­ровых подписей передаваемых данных. Для идентификации сообщений, про­верки их целостности используется новое средство — MAC. Оно вычисляется на основе текста сообщения, текущего времени (этот параметр не обязателен, од­нако с его помощью можно обезопасить себя от повторов атак) и совместно используемого клиентом и сервером пароля или набора кодов (codeset). Исполь­зующий S-HTTP броузер (или сервер) должен вычислить MAC при помощи инкапсулированного содержания сообщения S-HTTP.
Имея алгоритм смешивания Н, использующий S-HTTPхост должен вычислить MAC при помощи описанной ниже формулы. Пункты сообщения разделены при помощи символа «||»; таким образом, при вычислении MAC каждый после­дующий пункт добавляется к предыдущему:
МАС = hex (Н(Message| |<время>| |<совместно используемый ключ>>)
Время должно представляться в виде 32-битного беззнакового значения. Значе­ние 00:00:00 GMT соответствует 1 января 1970 года (эпоха Unix). Формат совместно используемого ключа зависит от самого ключа (которым стороны обмени­ваются заранее).
Формат строки ма с-In] выглядит следующим образом:
Идентификатор (ID) ключа ссылается на определенные в строке Key-Assigi клю­чи, либо на ключи, указанные в том же порядке, что и метод Outband. Исполь­зование в строке Спецификация ключа> значения "null" подразумевает, что от­правитель использует ключ нулевой длины. В этом случае MAC просто пред­ставляет собой смешанное значение текста сообщения и (необязательно) время. Специальное значение "dek"-это ссылка на использование спецификации Data Exchange Key. В этом случае тело сообщения будет зашифровано при помощи стандарта
Примечание. Использование спецификации ПЕК совместно с незашифрованным те­лом сообщения вызовет ошибку.
Обратите внимание: при помощи строки MAC-Info можно воспользоваться усо­вершенствованной версией стандартного режима HTTP-идентификации. Для этого пользователь должен указать свое имя и пароль. Однако пароль остается лич­ным, а целостность сообщения проверяется — т. е. установка S-HTTP проверя­ет целостность сообщения и вход в систему (log-in) без использования шифрова­ния. Кроме того, механизм MAC-Info позволяет проводить быструю проверку сообщений (при этом вы уже не сможете использовать полученное сообщение в качестве улики против его отправителя). В этом случае подразумевается, что обе стороны совместно используют некоторый ключ (которым они могли обме­няться при помощи Key-Assign).

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика